Автор этой статьи: Umeng + технический эксперт Лю Чжанцзюнь
Предисловие: Push-приложение часто используется в сценариях повседневной работы, таких как: своевременная рассылка новостей, точная отправка купонов на жизненные услуги, статус продукта электронной коммерции или рекламные предложения и т. д. Обычно разработчики реализуют требования путем самостоятельного встроенные каналы push-сообщений или использование сторонней платформы для push-уведомлений, но стоимость разработки и трудозатрат самостоятельно созданных push-сообщений очень высока, и многие разработчики приложений выбирают сторонние push-сообщения. Сегодня я буду продвигать U-Push с сообщением Umeng + и подробно объяснять, как обеспечить стабильность обслуживания и многофункциональные услуги охвата в контексте крупного бизнеса.
1. Предыстория бизнеса
Youmeng + отправка сообщений U-Push имеет средний ежедневный объем доставки сообщений в десятки миллиардов, из которых среднее ежедневное количество задач проверки составляет сотни тысяч, а пиковая стоимость оборудования для проверки в минуту может достигать 700 миллионов +, Эта статья поделится долгосрочное производство команды технической архитектуры Umeng +.Решение архитектуры скрининга ускорилось на практике.
Как обеспечить объем эмиссии в десятки миллиардов?
Скрининг Umeng + U-Push — это основная функция продукта Push, в котором скрининг в реальном времени является одной из основных возможностей, предоставляемых платным пользователям Pro с высокими требованиями к push-уведомлениям, что позволяет пользователям отмечать, просматривать, распространять и достигать в реальном времени. время. Идентификация устройства Umeng+U-Push основана на device_token. Чтобы обеспечить максимально возможный доступ, мы сохранили все device_tokens, которые могут быть доступны клиентам в ближайшем будущем. Взяв за пример 1 миллиард реальных устройств, каждое устройство установлено с 10 интегрированными Umeng Приложение +SDK может генерировать 10 device_tokens, что связано с дрейфом device_token, вызванным изменениями в аппаратной среде, и может генерировать больше device_tokens.
(Рисунок 1.1.1 Схема потока данных услуги Umeng+U-Push)
Рисунок 1.1.2 Список функций Umeng+U-Push
2. Обзор архитектуры скрининга U-Push
2.1 Две основные линии восходящей и нисходящей линии связи
Сервис U-Push состоит из двух ключевых звеньев: нисходящий канал обеспечивает доставку клиентских сообщений, а восходящий канал обеспечивает сбор данных терминала и синхронизацию данных с клиентским сервером. Нисходящий канал в основном делится на центры планирования задач и проверки.Основными услугами восходящего канала являются различные каналы сбора данных (для совместимости с историческими вопросами) и центр оборудования.Восходящий канал соединяется с нисходящим через центр оборудования.
Рисунок 2.1.1 Бизнес-сценарий скрининга Umeng + U-Push
В сервисе U-Push определяются различные типы задач в соответствии с различными бизнес-сценариями.Помимо одноадресной рассылки и прямой доставки по списку, служба фильтрации должна обрабатывать многоадресную рассылку, широковещательную рассылку, пользовательскую широковещательную рассылку и широковещательную рассылку файлов. Исполняемая доставка, в нисходящем канале (как показано на рисунке 2.1.2) наивысшим приоритетом является процесс принятия задачи и отправки задачи (красная ссылка), то есть, что бы ни случилось, должна быть обеспечена корректная доставка сообщений клиентов, что is U - Нижний уровень стабильности сервиса Push. С учетом аварийного восстановления служба проверки отделена от основного звена в архитектуре.
Рисунок 2.1.2 Экранирование и изоляция основного канала
2.2 Цели и дизайн архитектуры данных
Когда дело доходит до скрининга, его суть заключается в достижении быстрого позиционирования данных путем создания разумной системы индексации меток. Целью проверки является основная библиотека устройств U-Push, но чтобы запрос проверки не влиял на стабильность основной библиотеки, набор для проверки должен храниться избыточно в отдельных библиотеках.В отличие от общих сценариев OLAP и OLTP, сценарии применения досмотра U-Push более требовательны.
1. Отличная возможность параллелизма онлайн-задач
Суть скрининга по-прежнему заключается в онлайн-сценарии с определенными возможностями параллелизма. Параллелизм в основном приходится на ввод-вывод системы. Благодаря разумному использованию промежуточного программного обеспечения, строгому планированию обслуживания и дифференцированному дизайну целевых сценариев время выполнения одного экранирование может быть уменьшено, а параллелизм может быть улучшен.
2. Возможность анализа и передачи больших объемов данных в режиме реального времени.
Скрининг предоставляет множество измерений анализа (рис. 2.2.2), поддерживая гибкую синтаксическую композицию. Служба скрининга должна не только отвечать запросам и анализу массивных данных в режиме реального времени, но также поддерживать недорогую передачу наборов результатов, которые могут превышать 100 миллионов одновременно.
Рисунок 2.2.2 Типы полей, поддерживаемые фильтрацией
3. Контролируемая стоимость
Все проблемы связаны с затратами.С точки зрения отрасли, стоимость архитектуры услуг после того, как все люди переходят в облако, привлекла больше внимания, особенно в случае Umeng + огромный объем бизнеса, проблема стоимости более важна.
4. Создайте условия для параллельной отправки нисходящих задач
Кластер отправляющего уровня Umeng+U-Push используется для большого количества отправляющих узлов.Идеальный дизайн заключается в том, чтобы завершить нарезку, распределение и планирование данных на этапе проверки задач и отправить их непосредственно вниз по течению для достижения максимальной эффективности.
В непрерывной технической итерации U-Push тесно сотрудничает с профессиональными командами в различных областях и в полной мере использует характеристики различных компонентов.Путем интеграции Tair, AnalyticDB для MySQL (ADS), OSS, MaxCompute (ODPS), Lindorm, HBase, SchedulerX и др. Выпускается набор сбалансированных решений, учитывающих стабильность, производительность и стоимость.
Скрининг разделен на две части: офлайн и в реальном времени.В офлайн режиме снимок основной библиотеки устройств создается через ODPS и импортируется в ADS. Библиотека ADS или RDB обновляется в режиме реального времени посредством события обновления информации об устройстве в службе восходящего канала потребления данных в режиме реального времени. При выполнении фильтрации загрузите или создайте дамп нескольких небольших файлов в OSS для получения больших наборов результатов и передайте их в нисходящий поток передающей ссылки для параллельной отправки.
Рисунок 2.2.4 Фильтрация потока сервисных данных
Вышеупомянутые бизнес-ссылки и структуры данных представляют текущий общий дизайн скрининга, но необходимы более подробные проекты, чтобы справиться со сложными настроениями клиентов и меняющимися бизнес-сценариями.
3. Детали дизайна
3.1 Сценарий проекта библиотеки скрининга
Как видно из приведенного выше обзора, основным противоречием в архитектуре экранирования является противоречие между чтением массивных данных в нисходящем канале сообщения и высокочастотной записью обновлений атрибутов устройства в восходящем канале, разрешение этого противоречия требует много усилий. ресурсы для обеспечения согласованности данных.Производительность и производительность почти невозможны при текущих затратах на ресурсы в традиционном проектном мышлении. Три основных сокровища больших данных — это разделение горячих и холодных баз данных и подтаблиц.Посредством бизнес-анализа и исследований U-Push делит бизнес на несколько сценариев, направляет клиентов к различным сценариям в зависимости от бизнес-требований и возможностей обслуживания клиентов в разных жизненных циклах и максимально оптимизирует клиентский опыт.
Рисунок 3.1.1 Сценарий проекта библиотеки скрининга
Многоадресная и широковещательная проверка Мы в основном строим ADS. ADS обеспечивает методы обновления в режиме реального времени и в автономном режиме. С точки зрения формы продукта, только возможности проверки в реальном времени открыты для профессиональных клиентов, предоставляют дифференцированные услуги и повышают стабильность.
Автономная часть: возможность проверки T+1 для всех клиентов гарантируется автономной основной библиотекой. В реальном бизнесе автономная основная библиотека имеет только запросы на чтение в качестве итогового результата во всех экстремальных сценариях.Автономная основная библиотека разбита по device_token, который можно полностью разбить, но производительность агрегированных запросов немного хуже. Чтобы улучшить качество обслуживания некоторых клиентов, особенно новых клиентов, мы разработали автономную базу данных для новых клиентов и преобразовали их в разделы клиентов, чтобы повысить эффективность запросов агрегации одного клиента. Однако из-за разницы в масштабах между клиентами автономная база данных новых клиентов может легко привести к перекосу раздела.В производстве этой таблице нужно постоянно уделять внимание, и ее нужно вовремя очищать и переносить.В противном случае, строка может обрываться при запуске ads_loader.
Рисунок 3.1.2 Статус раздела автономной главной библиотеки
Рисунок 3.1.3 Наклон перегородки с клиентом в качестве перегородки
Часть, работающая в режиме реального времени: в центре внимания всей системы находится обеспечение скрининга в режиме реального времени.Скрининг в реальном времени подразделяется на VIP-библиотеку реального времени, библиотеку тестового оборудования (для облегчения получения результатов тестирования в режиме реального времени во время доступа клиента). , и новая клиентская библиотека в режиме реального времени (дополнительное общее оборудование для клиентов). Сумма очень мала, U-Push предоставит бесплатную услугу скрининга в реальном времени в течение определенного периода времени). Подобно автономному секционированию, схема секционирования также разделяет крупномасштабные данные сценариев и данные в сценариях меньшего масштаба на таблицы.Специальные библиотеки тестового оборудования могут генерировать большое количество грязных данных и изолировать их как единое целое.
Рисунок 3.1.2 Миграция клиентского сценария
В начале доступа новых клиентов, в зависимости от масштаба клиента, они будут представлены в определенных сценариях на разных узлах жизненного цикла и попытаются улучшить качество обслуживания клиентов на основе обеспечения емкости рынка.
3.2 Использование OSS для передачи и разделения файлов
Благодаря различению автономного режима и режима реального времени в приведенном выше дизайне снижается возможное влияние высокочастотной записи на библиотеку устройства. Тем не менее, невозможно избежать проблемы передачи больших объемов данных.Чтобы избежать этой проблемы, U-Push использует идею дифференцированного дизайна, различает размер набора результатов, напрямую выгружает большой набор результатов в OSS через ADS и выполняет удаленную операцию на основе на параллелизме различных клиентов.Разделить, после того как OSS завершит операции загрузки и разделения, он возвращает набор путей к файлам, и только набор путей к файлам сохраняется для последующих ссылок, пока он не войдет на уровень отправки для параллельной отправки. Небольшой набор результатов загружается в память через select для интеграции передачи сообщений, а последующая ссылка напрямую отправляет идентификатор устройства. Использование OSS в качестве промежуточного хранилища значительно снижает избыточные потери ввода-вывода.
В ADS 3.0 общая структура изменена для вывода дампа в OSS через внешнюю таблицу, что отличается от версии 2.0, которая может создавать дамп одного файла.3.0 будет генерировать серию небольших файлов после дампа, что напрямую делает исходное решение невыполнимым. коммуникации, ADS специально доработала функцию дампа одиночного файла в версии 3.0, спасибо ученикам ADS.
Рис. 3.2.1 Риск узкого места производительности в фильтрующем запросе
3.3 Кэширование запросов и предварительная фильтрация
Когда дело доходит до сценариев запросов, обязательно должно быть место для кэширования.В отличие от общей идеи дизайна, U-Push напрямую отказывается от кэша запросов в пользу возможностей фильтрации в реальном времени, поскольку обновления устройства в любое время неизбежны при таком сценарии. величина устройства. Библиотека скрининга в реальном времени U-Push представляет собой сценарий высокочастотной записи и низкочастотного чтения, но требования к однократному чтению относительно строгие.Прежде всего, для офлайн-клиентов, у которых нет функция включена, т.к. библиотека устройства в виде снапшотов, требуется многократное чтение в течение дня. Полученные результаты должны быть одинаковыми. В это время очень важно установить кеш. Например, привычка новостей , погоды и инструментов, отправляющих несколько трансляций в день, нет необходимости каждый раз регенерировать файл набора фильтров.
Рисунок 3.3.1 Логическая схема кэширования запросов
Разработка функции предварительной проверки — это небольшой эпизод.Как упоминалось ранее, U-Push отказался от кэширования запросов в реальном времени, из-за чего клиент повторно создает файл каждый раз при отправке сообщения.С точки зрения обеспечения данные в режиме реального времени, это безупречно.«Реальные» клиенты очень напряжены. Например, заказчики новостей крайне обеспокоены своевременностью доставки сообщений.Через консоль разработчика можно проверить время проверки каждой задачи.Иногда разница в 2 с похожих сообщений также будет приводить к "жалобам клиентов" от клиентов в Группа ДИНГ. Запрос клиента понятен, но он также отнимает много сил у команды. Общаясь с отдельными клиентами, U-Push разработал функцию предварительной проверки, которая планирует и выполняет логику проверки для создания набора идентификаторов устройств заранее, прежде чем клиенты обычно отправляют сообщения. время сжимается и сообщение получается скорость отправки.
Рисунок 3.3.1 Дорожка сообщений Umeng+U-Push
3.4 Оптимизация скрининга псевдонимов
Запросы на скрининг можно разделить на два сценария:
Сценарии сопоставления идентификаторов, зависящие от функции псевдонима, идентификатор устройства NvN и сопоставление псевдонимов.
Сценарий выбора и условный запрос многоадресной рассылки тегов и функции трансляции iOS реализованы на базе ADS.
Введение функции псевдонима: псевдоним позволяет разработчикам привязывать псевдонимы к устройствам.Псевдоним состоит из двух атрибутов, alias_type и псевдоним.Например, разработчики могут идентифицировать устройство A и добавить alias_type=номер_телефона, alias=13900000000 к устройству A, чтобы добавить мобильный телефон к устройству А. свойства номера. При отправке сообщения вы можете обойти device_token и напрямую указать псевдоним на сервере для получения доступа.Псевдоним является типичным сценарием сопоставления идентификаторов NVN.У устройства может быть только один псевдоним под одним и тем же alias_type одновременно. Это также соответствует общим бизнес-сценариям. Например, в приведенном выше примере устройство обычно имеет только один номер мобильного телефона. После установки нового номера мобильного телефона исходный псевдоним будет перезаписан. Если вам необходимо выполнить функцию двойного режима ожидания с двумя картами, вам необходимо установить два alias_types, а именно: alias_type=номер_телефона_основной, alias_type=номер_телефона_вторичный. Общий сценарий использования псевдонима заключается в том, что разработчики загружают пакет файлов через пользовательский файл, а содержимое файла представляет собой набор нескольких псевдонимов устройств с определенным типом alias_type (миллионы миллионов). После того как служба фильтрации просканирует файл, она последовательно находит device_token сопоставления значения псевдонима.
3.4.1 Ранний дизайн псевдонима
Когда дело доходит до сопоставления, опроса и запросов с высокой пропускной способностью, Redis является первым выбором, как и ранний U-Push.
Рисунок 3.5.1 Ранний дизайн структуры данных псевдонима
Псевдоним использует структуры Redis Set и Hash для реализации функции проверки и сопоставления. Зачем использовать хэш для контраста? Как упоминалось ранее, одно устройство сохраняет только последний псевдоним под одним alias_type. Это также необходимо для защиты пользователей.Если устройство существует под несколькими псевдонимами одновременно, когда разработчик выполняет выбор круга, устройство может быть выбрано несколько раз, что приведет к нескольким недействительным касаниям.
Этот дизайн является мягким и действительно может соответствовать сценариям проверки большинства клиентов, но с увеличением объема бизнеса постепенно выявляются некоторые проблемы.
Опрос становится узким местом при массовом запросе устройств и не может быть преодолен.
Выделена проблема сложной сохраняемости данных в Redis, а анализ данных еще более сложен.
Псевдоним не может удовлетворить потребности канала возврата данных.
3.4.2 Исследование решения Alias
Подбиблиотека действительно хорошая идея, но она по-прежнему не может решить проблемы с производительностью и устойчивостью, а с учетом внимания отрасли к большим данным возврат данных стал требованием большего числа разработчиков. Открытие канала возврата данных для эффективного хранения, доступа, управления и использования данных клиентов стало важным направлением в отрасли. Чтобы решить эту проблему, U-Push формулирует меры, комбинируя офлайн и режим реального времени.
Подбиблиотека, добавьте клиентскую библиотеку уровня KA и сожмите горизонтальное пространство расширения.
Многоуровневое постоянное многоуровневое хранилище на базе Lindorm.
Удержание в автономном режиме, результаты проверки нисходящего канала сохраняются через систему журналов, с одной стороны, улучшаются статистические требования, а с другой стороны, заказчик возвращается заказчику через квитанцию.
3.4.3 Иерархический дизайн на основе широкой таблицы Lindorm
Используйте широкую таблицу вместо дизайна Redis Set для прямого запроса, используйте общую таблицу на основе комбинированного первичного ключа идентификатора устройства для обратного запроса и попытайтесь сократить потери ввода-вывода, изменив одиночный опрос на несколько мгет во время запроса, чтобы найти производительность ответа и стабильное обслуживание В качестве промежуточного значения дисковое хранилище Lindorm может удовлетворить потребности бизнеса и синхронизировать данные lindorm T+1 с ODPS через конфигурацию экспортера.
Рисунок 3.5.2 Многоуровневый дизайн на основе часов Lindorm
3.4.4 Попытки и мысли о переносе данных
Миграция данных является проблемой во многих бизнес-архитектурах, поэтому обеспечение стабильной, плавной и безопасной миграции требует больших затрат. U-Push исследовал и обдумал различные схемы переноса данных Alias.
Общая миграция дампа Tair, решение дампа теоретически осуществимо, но имеет более высокие бизнес-риски и от него отказались по соображениям стабильности.
Инкрементное обновление запроса на запись, которое переносится ключ за ключом через запрос на запись клиента, будет иметь длительное время в градациях серого, и невозможно выполнить тщательную очистку, что лучше, чем стабильность.
Сканирование основной библиотеки оборудования и переход клиентов на оттенки серого в пакетном режиме. В функции U-Push предусмотрена функция alias_type под ключом приложения. Клиенты могут запрашивать список alias_type под ключом приложения в консоли разработчика. Чтобы реализовать эту функцию, для appkey и alias_type создается заданный индекс. Этот индекс становится ключ к миграции данных. Получите appkey и device_token, просканировав библиотеку устройств, используйте alias_type для обратного поиска в библиотеке, чтобы найти псевдоним, а затем используйте appkey+alias_type+alias для поиска в библиотеке, чтобы запросить список device_token для завершения миграции.
Третий метод может реализовать идеальную миграцию существующих данных, что почти не влияет на онлайн-сервисы, но все равно требуется 10 дней для расчета с 1wTPS под десятками миллиардов устройств, К счастью, это решение позволяет добиться оттенков серого и отката.
5. Заключение
Служба проверки U-Push - это только одна из многих услуг U-Push. Благодаря огромному объему бизнеса Umeng + было выпущено большое количество изысканных дизайнов для удовлетворения потребностей различных отраслей. В этой статье перечислены только верхние части айсберг Количество отправленных десятков миллиардов сообщений неотделимо от сотрудничества других групп технической архитектуры в итерации сервисов проверки.
В настоящее время U-Push основан на канале Push, интегрированном WeChat, SMS и частных SMS для обновления до многоканальной службы охвата, обеспечивающей доступ ко многим известным приложениям, таким как сегодняшние заголовки, свежие новости, помощь в выполнении домашних заданий. , легкий автомобиль и т. д. В будущем он будет продолжать получать доступ к большему количеству каналов для сценариев работы, таких как мини-программы Alipay и учетные записи Toutiao, и продолжать предоставлять клиентам стабильные, высокопроизводительные и недорогие гарантии доступности.