Управляемое чтение: система push-уведомлений для коротких видео – это распределенная система push-уведомлений, которая поддерживает несколько приложений и несколько бизнес-сценариев в Baidu. В настоящее время она поддерживает службы push-уведомлений таких приложений, как Haohao Video, Live Broadcast, Duxiaoshi, Haohao Dazhi и т. д. Поддержка сценариев такие как персонализированная рассылка, оперативная рассылка популярных действий и горячих событий, а также бизнес-реклама в режиме реального времени на основе отношений подписки или подписки. Он направлен на то, чтобы стабильно и эффективно отправлять информацию о вашем любимом контенте в сообщения панели уведомлений пользователей с помощью персонализированной системы рекомендаций, а также методов работы и редактирования, чтобы достичь бизнес-целей повышения активности пользователей и улучшения удержания пользователей.

Полный текст составляет 5886 слов, расчетное время чтения — 15 минут.

задний план:

В эту эру информационного взрыва в Интернете возможность своевременного и точного получения информации является одной из ключевых проблем, которые необходимо решить в современном обществе Технология push изменила традиционный способ получения информации путем «активного извлечения», но стать способом активного поиска пользователями информации.Он больше подходит для удовлетворения потребностей пользователей в персонализированной информации в мобильной сети. Эта статья в основном знакомит с дизайном и реализацией короткой видеосистемы Push и непрерывной оптимизацией системы, чтобы рассказать вам об опыте создания системы Push с объемом данных 100 миллионов.

Глоссарий:
Сообщение push (Push): Нажатие сообщения панели уведомлений, инициированное сервером, содержимое сообщения отображается на интерфейсе экрана блокировки, панели уведомлений, угловом логотипе приложения и т. Д. На устройстве пользователя.

Персонализированный толчок: нажмите, чтобы выбрать материалы, которые интересуют пользователей, с помощью портретов пользователей и моделей рекомендаций.

Операция Толчок: Push-сообщения, отправляемые материалами, редактируются вручную операторами в фоновом режиме Push (например, push-уведомления, такие как популярные действия и горячие события).

Push-уведомления в реальном времени: Push отправляется в режиме реального времени с относительно точными временными требованиями, когда пользователи выполняют интерактивные операции в приложении (такие как подписка, лайк, комментарий и т. д.) или когда в прямом эфире необходимо отправить напоминание о начале трансляции.

1. Понять систему

1.1 Введение в систему

Благодаря постоянному развитию бизнеса Baidu по выпуску короткометражных видео у приложения также есть сотни миллионов активных пользователей ежеквартально. Система Push будет предоставлять n персонализированных push-уведомлений, а также нефиксированное количество популярных действий и push-уведомлений по горячим событиям ежеквартально активным пользователям приложения. дизайн системы.Кроме того, в соответствии с различными Группа пользователей в регионе будет отправлять сотни региональных толчков и большое количество отношений последователей и других толчков в реальном времени каждый день, что также накладывает строгие требования на стабильность системы. важность секса можно себе представить.

1.2 Обзор системы

Система Push обслуживает такие услуги, как видео Haohao, прямая трансляция, Duxiaoshi, крупносимвольная версия Haohao и так далее. Система подпишется и обновит информацию о видеоматериале и информацию о пользовательских атрибутах в режиме реального времени, чтобы обеспечить точность информации при построении тела Push-сообщения, запросит рекомендательный сервис для отзыва персонализированных материалов рано утром, а затем создаст Push в соответствии со временем работы Push и персонализированной Push.Task.После того, как задача создана, операция предварительной обработки задачи будет проводиться за полчаса (чтобы гарантировать, что Push может быть отправлен как можно скорее ), а push-уведомления в реальном времени, такие как сообщения о взаимодействии с пользователем и напоминания о начале прямой трансляции, будут отправлять контент для отправки в режиме реального времени с помощью вызовов API. После завершения предварительной обработки результат записывается в очередь Redis, а служба отправки отправляет информацию на промежуточную станцию ​​облачной рассылки в соответствии с приоритетом задачи. сервис для отправки Push-информации на мобильный телефон пользователя.

Общая архитектура показана на следующем рисунке:

1.2.1 Введение в каждый модуль архитектуры ядра Push

1. Материальный центр: Храните информацию о видеоматериале, необходимую для Push-уведомлений, включая название, описание, изображение материала и статус Push-сообщения, и подписывайтесь на очередь сообщений об изменении видео на стороне B для получения обновлений в реальном времени.

2. Пользовательский центр: Храните основную информацию о пользователе, необходимую для Push-уведомлений, и некоторые пользовательские атрибуты, уникальные для системы Push (такие как: 1. Расчетное время активности пользователя. 2. Расчетное время первого и последнего персонализированного Push-уведомления пользователя и т. д.), а клиент сообщает о пользователе. информация для обновления в режиме реального времени.

3. Персонализированный отзыв: персонализированный отзыв материалов для сезонных активных пользователей начинается в 1:00 каждый день для отправки персонализированных push-уведомлений в течение дня.

4. API-сервис реального времени: Запись в очередь предварительной обработки в режиме реального времени для операций предварительной обработки и отправки данных, которые используются в таких сценариях, как Push в реальном времени.

5. Служба контроля частоты (ufc): Чтобы не беспокоить пользователей, существует два уровня: дневной уровень и часовой уровень. Настройки управления частотой на уровне дня, и пользователь может установить максимальное количество элементов Push в один день. На почасовом уровне каждый пользователь может получить максимум 1 Push в течение получаса.

6. Предварительная обработка: Разделите задачи, хранящиеся на складе, за полчаса до начала и обработайте создание сообщений и очередь push-уведомлений, чтобы обеспечить своевременную отправку задач Push.

7. Отправить услугу: По времени отправки задачи и приоритету задачи из очереди Push получается задача соответствующего производителя, а задача разрезается по ups и qps производителя и отправляется в Cloud Push.

8. Служба приема: Запись соответствующих журналов в соответствии с приходными квитанциями различных производителей для статистики данных, мониторинга и оповещения в реальном времени.

9. Центр управления (пцк): Система визуальной настройки важных функций Push.

Схема зависимостей каждого модуля архитектуры ядра Push выглядит следующим образом:

1.3 Поток данных системы

1.3.1 Общий поток данных системы

Клиент сообщает информацию о пользователе и некоторые журналы управления поведением пользователей в центр обработки данных, а центр обработки данных создает соответствующую таблицу данных в соответствии с управлением клиента Пользовательский набор, сторона архитектуры вызывает материалы Push в соответствии со стратегической моделью, создает и отправляет задачи и отправляет информацию на промежуточную станцию ​​Push.Затем сообщение о получении отправляется во внутреннюю службу, и архитектура записывает журнал в соответствии с уведомлением о прибытии и передает его в центр обработки данных для завершения вывода соответствующих отчетов. . Как показано ниже:

клиент: завершите привязку Push_token с помощью Push sdk и сообщите основную информацию о пользователе и журналы управления поведением пользователей.

Дата центр: создание таблицы активных пользователей, таблицы поведения пользователей и соответствующих бизнес-отчетов в соответствии с управлением бизнесом.

Стратегия продвижения: ежедневное производство Push-материалов и персонализированных Push-материалов на основе портретов пользователей.

Пуш-архитектура: Выполняйте персонализированный отзыв материалов рано утром, регулярно отправляйте задания и обрабатывайте квитанцию ​​производителя о поступлении.

Средняя платформа Cloud Push: отправьте задачу Push агенту каждого производителя или длинной ссылке и сгенерируйте таблицу основных данных Push.

Агент производителя: Отвечает за отправку задач Push соответствующих производителей на пользовательское оборудование и отправку квитанции о прибытии.

1.3.2 Поток данных уведомления о прибытии push-уведомлений

Существует три типа квитанций о прибытии Push.Квитанция от производителя агента Android, квитанция iOS и квитанция о длинной ссылке принимаются промежуточной службой Push и затем записываются в очередь сообщений.Сервис Push-arrive на стороне архитектуры использует очередь сообщений 1. Статистические расчеты в реальном времени и вычисления Запись данных в Redis для статистических отчетов в реальном времени 1. Запись локальных журналов, выполнение мониторинга в реальном времени и оповещение после сбора, а также загрузка их в центр обработки данных для получения соответствующих статистических данных отчеты, наборы кандидатов для продвижения материалов, а также создание выставок Push-точек. Образцы используются в качестве обучения для модели Push.

Как показано ниже:

2. Итерация и оптимизация системы

2.1 Регулярно оценивайте время отправки первого и последнего сообщения персонализированного Push-уведомления.

2.1.1 Предыстория

В исходной логике время первого персонализированного пуша всех пользователей каждый день — 6:30, а время последнего персонализированного пуша — 21:45. Каждый пользователь просыпается и засыпает в разное время и имеет разную чувствительность к полученным Push-уведомлениям. Выбор времени отправки в соответствии с привычками пользователя может повысить количество кликов по Push-уведомлениям.

2.1.2 Дизайн услуг

В соответствии с привычками использования пользователя оценивается время отправки первой и последней статей разных пользователей каждый день, чтобы пользователь мог своевременно отправлять интересующий его контент, когда он хочет посмотреть на мобильный телефон. Очевидно, сложность сервиса в том, как оценить, когда пользователь свободен для проверки мобильного телефона.Общая логика такова.Первой оценкой времени отправки является подсчет первых активных дней пользователя в [5:30 , 6:00] период в течение 7 дней.Если он больше 1, время первой персонализированной отправки пользователя корректируется с 6:30 до 5:30, если оно не находится в указанном выше интервале, первые активные дни пользователя в период [5:30, 6:30] в течение 7 дней. Если оно больше 1, время первой персонализированной отправки пользователя будет скорректировано с 6:30 до 6:00, оставшееся время отправки пользователей будет все еще будет 6:30; :15, 22:45] Первые активные дни в периоде, если он больше 1, время первой персонализированной отправки пользователя будет скорректировано с 21:45 до 22:15; 22:15 23 :59] первые активные дни в периоде, если оно больше 1, первое персонализированное время отправки пользователя будет скорректировано с 21:45 до 22:45; оставшееся время отправки пользователей по-прежнему будет 21:45; как показано ниже:

2.2 Оптимизация службы группировки пользователей системы Push

2.2.1 Предыстория

Различные наборы пользователей, требуемые этой службой для создания Push-уведомлений, включают полных пользователей, персонализированных пользователей, заинтересованных пользователей, региональных пользователей и т. д., которые в совокупности называются пользовательскими пакетами.Вывод пользовательских пакетов зависит от различных восходящих потоков, включая пользовательские центры, политики, и группы данных.Подождите, с итерацией бизнеса возникают следующие проблемы:

1) Отсутствует унифицированное управление, большая часть которого — это развернутые на физических машинах тайм-скрипты, у которых есть одноточечные проблемы, а мониторинг и оповещение о выводе данных разбросаны.

2) Хранение пользовательских пакетов зависит от физической машины и кластера hadoop.В процессе отправки весь пользовательский пакет должен быть загружен в память через файлы ftp и afs.Полная одиночная задача занимает около 30 секунд, что влияет на своевременность.

3) Каждый тип пользовательского пакета хранится отдельно, и происходит трата ресурсов хранения.

4) При работе с пакетом пользователей с множественным выбором загрузка повторяющихся идентификаторов пользователей тратит впустую ресурсы памяти, а процесс дедупликации влияет на своевременность.

5) Когда модуль отзыва в реальном времени перезапускается, загрузка соответствующего пользовательского пакета и обработка логики занимает много времени, что влияет на эффективность работы в сети и доступность службы.Перезапуск одной машины занимает 20 минут.

2.2.3 Дизайн услуг

2.2.3.1 Сравнение старой и новой архитектур

оригинальная архитектура

новая архитектура

1) Чтобы различать пакеты пользователей на основе кластеров ftp и afs физической машины в текущей архитектуре, группы пользователей используются для представления наборов пользователей, которые соответствуют одному измерению.

2) Регистрация и управление группами пользователей настраиваются единообразно через платформу amis, и каждая группа пользователей имеет уникальный идентификатор.

3) Группы пользователей представлены и сохранены в виде растровых изображений.Каждый бит в растровом изображении представляет пользователя, и каждая группа пользователей может быть представлена ​​растровым изображением.

4) Замените исходный адрес пакета пользователя в службе Push на метку группы пользователей.Поддерживаются логические операции между несколькими группами пользователей, которые представлены логическими выражениями.

5) Во время процесса отправки служба группы пользователей сначала опрашивается с помощью логического выражения тега группы пользователей, чтобы получить растровое изображение конечного отправляемого пользователя; затем идентификатор пользователя получается пакетами из службы группы пользователей с помощью растровое изображение, потоковое и отправленное.

2.2.3.2 Схема управления группами пользователей

Конфигурация группы пользователей:

1) Уровень конфигурации осуществляет унифицированное управление группами пользователей через платформу amis, которая хранится в mysql в виде задач и поддерживает такие конфигурации, как метки групп пользователей, выходные адреса пользовательских пакетов, частота обновлений и количество повторных попыток;

2) уровень планирования выполняет вытесняющее планирование времени для каждой задачи и отправляет вытесненные задачи на уровень обслуживания для выполнения;

3) Сервисный слой получает задачу и запускает процесс сборки библиотеки:

1. Вытащите удаленный файл в соответствии с адресом пользовательского пакета.Если это удастся, продолжите вниз.Если это не удастся, измените статус задачи и повторите попытку таблицы записи выполнения;

2. Загрузите идентификатор пользователя в файл, вычислите соответствующее значение crc64/fnv64 и сохраните сопоставление результатов в Redis (k: crc64/fnv64, v: идентификатор пользователя);

3. Вычислите растровое изображение текущей группы пользователей (алгоритм RaoringBitmap) и сохраните результат в redis (k: метка группы пользователей, v: растровое изображение группы пользователей).

2.2.3.3 Схема взаимодействия онлайн-сервиса

Процесс взаимодействия с онлайн-сервисом:

1) Задача Push указывает набор отправляющих пользователей через тег группы пользователей (задачи amis/timed записываются в mysql), а несколько тегов представлены логическими выражениями;

2) После того, как уровень сервиса Push получает задачу отправки, он использует выражение тега для запроса онлайн-сервиса группы пользователей;

3) онлайн-сервис группы пользователей считывает битовую карту всех тегов группы пользователей из redis в соответствии с логическим выражением, выполняет логические операции, получает битовую карту конечной отправляющей группы пользователей и возвращает ее на уровень сервиса push;

4) Уровень услуги Push проходит по битовой карте, получает значение crc64/fnv64 побитно и запрашивает услуги группы пользователей в пакетах;

5) Служба группы пользователей сопоставляет crc64/fnv64 обратно с соответствующим идентификатором пользователя из Redis и возвращает его на уровень службы Push.

2.3 Оптимизация службы управления частотой системы push (ufc)

2.3.1 Служба управления частотой в основном выполняет следующие функции:

1) Базовые функции ограничивают то, что пользователь не может получить два Push-сообщения в течение 30 минут, а общее количество Push-сообщений за один день не может превышать максимальное количество сообщений.

2. В сочетании с данными белого списка, предоставленными политикой, контролем частоты временного сегмента, идентификатором пользователя + данными политики веса push-типа, получают данные о переработке и выполняют персонализированный контроль частоты.

3. Постоянная функция белого списка PushType и идентификатора пользователя, для этого типа PushType идентификатор пользователя не выполняет управление частотой

2.3.2 Предыстория

1. В настоящее время UFC выделяет фиксированные данные управления частотой физического хранилища в виде мода через значение хэша (идентификатор пользователя), фиксированное количество выделенных серверов и IP-адрес сервера, который нелегко расширить, и это повлияет на данные управления частотой пользователя на следующий день после расширения Онлайн около 1 часа.

2) Конфигурация push-типа и белый список идентификаторов пользователей, которые часто меняются, представлены в виде файлов конфигурации, и требуется много времени, чтобы каждое изменение вступило в силу.

3. Службы развернуты на физических машинах смешанным образом, конкурируя за ресурсы с другими службами, которые будут влиять или будут затронуты другими службами, а службы нестабильны.

2.3.3 Дизайн услуг

Динамическое расширение, последовательный алгоритм хеширования

1. Сначала найдите хеш-значение сервера (узла) и настройте его на окружность (континуум) от 0 до 232.

2. Затем используйте тот же метод, чтобы найти хэш-значение ключа, в котором хранятся данные, и сопоставьте его с тем же кругом.

3. Затем начните искать по часовой стрелке от места сопоставления данных и сохраните данные на первом найденном сервере. Если сервер все еще не найден после 232, он будет сохранен на первом сервере.

Сжатие ресурсов с использованием протокола protobuf для сжатия данных

Буфер протокола Google (сокращенно Protobuf) — это смешанный стандарт данных Google. В настоящее время используется более 48 162 определений форматов сообщений и более 12 183 файлов .proto. Они используются в системах RPC и системах постоянного хранения данных. Protocol Buffers — это легкий и эффективный формат хранения структурированных данных, который можно использовать для сериализации или сериализации структурированных данных. Это хорошее хранилище данных или формат обмена данными RPC. Независимый от языка, платформы и расширяемый сериализованный формат структурированных данных, который можно использовать в протоколах связи, хранении данных и других областях. Protobuf состоит из таких вещей, как JSON и XML, но он меньше, быстрее и проще. Вы можете определить свою собственную структуру данных, а затем использовать код, сгенерированный генератором кода, для чтения и записи этой структуры данных. Вы даже можете обновлять структуры данных без повторного развертывания программы. Используйте Protobuf для описания вашей структуры данных один раз, а затем легко читайте и записывайте свои структурированные данные на различных языках или из множества различных потоков данных.

описание одним предложением: protobuf — это двоичный протокол. Разрабатывая схему для json для обеспечения более высокой скорости синтаксического анализа, он в основном отбрасывает такие значения, как {, ", ключ и т. д., и использует тег|значение для хранения значения. Эффективность передачи чрезвычайно высок, а объем передачи мал.Использование в tcp/rpc очень популярно.

Сравнение продолжительности сериализации:

сравнение байтов:

Сравнение бизнес-протоколов Push:

В заключение: Marshal of proto в 2 раза быстрее, чем Marshal of json Размер сжатых данных proto составляет 1/4 от размера json, и чем больше данных, тем очевиднее преимущество. После сжатия окончательных данных управления частотой сохраняется 75% ресурсов Redis.

3. Резюме

Пуш-сообщение (Push) — важное средство работы мобильного приложения с низкой стоимостью и высокой эффективностью. С быстрым развитием мобильного Интернета разработка мобильных приложений становится все более и более зрелой, а частота обновления приложений также увеличивается.В то же время сообщения, отправляемые каждым приложением, также различаются.Может ли он своевременно и точно рассылать содержание сообщений, которые интересуют пользователей?Улучшение скорости потребления push-информации является основной ценностью системы Push.

«Отец Apple» Стив Джобс однажды сказал: «На самом деле очень сложно разрабатывать продукты в соответствии с потребностями публики. Потому что во многих случаях люди не знают, чего хотят, поэтому нужно показать ему». Это предложение также подходит для push.Для пользователей, которые знают, какой контент сообщения им нужен, push-контент может быть в соответствии с их предпочтениями (персонализированный push). Для пользователей, которые не знают, какой контент сообщения им нужен, операторы приложений должны учитывать осуществимость сообщения при отправке сообщения. Необходимо тщательно продумать не только выбор содержимого, но и время, объект и метод отправки (операция push).

Рекомендуемое чтение:

｜Архитектура и практика системы анализа данных Baidu Aifanfan

｜Отслеживание аномалий и управление ими в интерфейсе страницы хостинга

｜Реализация крупномасштабного приложения для управления услугами на основе etcd

---------- END ----------

Байду Гик говорит

Официальный технический общедоступный аккаунт Baidu доступен онлайн!

Технические галантереи · Отраслевая информация · Интернет-салон · Отраслевая конференция

Информация о найме · Внутренняя информация · Технические книги · Периферийные устройства Baidu

Приглашаем студентов обратить внимание