Мысли о дизайне проекта службы подачи

задняя часть

Предыстория проекта

Ради удержания коллеги по продукту разработали в приложении функцию подачи, аналогичную Weibo. С функциональной точки зрения наш сервис фидов больше похож на комбинацию Weibo и WeChat Moments. На Weibo есть не только популярные сцены, но и тень WeChat Moments.

список функций

  • информационная страница фида

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

  • лента новостей

Как и в WeChat Moments, вы можете видеть себя и своих друзей (следование) опубликованная динамика подачи.

  • подача квадратной страницы

Подобно рекомендации или популярной функции Weibo, он может давать персонализированные рекомендации для пользователей.

Основная идея

feed流.png

Проектное мышление

1. Хранение данных

В основном в ленте динамически хранится два вида информации: один представляет собой динамический контент, а другой представляет собой динамический индекс различных измерений.

структура данных фида

В дополнение к основному содержанию информации канала необходимо хранить дополнительную информацию, и эта дополнительная информация может быть расширена. Таким образом, основное определение структуры данных канала выглядит следующим образом. Данные, хранящиеся в базе данных, представляют собой сериализованные данные информации FeedInfo, поэтому последующие расширения могут поддерживаться без изменения полей базы данных.

message FeedItem {
    string feed_id = 1; //动态id
    int64 create_time = 2; //发布时间
    User from_user = 3; //发布者
    int32 feed_type = 4; //对应FeedType
    bytes attachment = 5; //附件信息
   ...
}

message FeedInfo {
    FeedItem feed_item = 1;
    bool deleted = 2; //是否删除
    AuditType audit_type = 3; // 审核类型
    VisibleStatus visible_status = 4; // 动态可见性
    ...
}

Хранение контента

feedId => содержимое фида

Динамический контент можно абстрагировать в хранилище ключей-значений в виде KV.Почти во всех сценариях динамический контент получается на основе динамических идентификаторов, а затем обрабатывается. Поэтому в качестве приоритетного сервиса хранения контента был выбран HBase, а в качестве плана даунгрейда были добавлены Mysql и Redis. Ведь это первое применение HBase к онлайн-сервисам. Судя по окончательным данным о производительности, производительность HBase по-прежнему хорошая.

индексное хранилище данных

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

  • фид информационной страницы

Подобно функции фотоальбома WeChat Moments, необходимо хранить все обновления, опубликованные пользователями, и разделять их на таблицы в соответствии с пользовательским измерением. Основная информация следующая:

Атрибуты Примечание
user_id Идентификатор издателя
feed_id Динамический идентификатор
feed_create_time Время динамического создания
visible_status Динамическая видимость
  • Новостная лента

Как и в WeChat Moments, вам нужно хранить всеСледите за людьмиа такжеСобственныйДинамика таблицы разделена по пользовательскому размеру. Основная информация следующая:

Атрибуты Примечание
user_id ID пользователя
feed_id Динамический идентификатор
from_user_id Идентификатор издателя
feed_create_time Время динамического создания
  • Квадратная лента рекомендаций

Подобно популярной функции рекомендаций Weibo, необходимо хранить каналы, опубликованные всеми пользователями, в соответствии с временной шкалой. Поэтому квадратная подача делится по дате. В месяце 31 день, всего таблиц 31, и фиды на разные даты хранятся в разных таблицах. Основная информация в основном такая же, как и в новостной ленте, но сохраненные данные и измерения данных отличаются.

Атрибуты Примечание
user_id ID пользователя
feed_id Динамический идентификатор
from_user_id Идентификатор издателя
feed_create_time Время динамического создания

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

2. Распространение данных

  • Распространение

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

  • поток данных

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

3. Механизм проверки

Динамика, выпущенная пользователем, должна быть проверена, чтобы избежать передачи пользователю незаконного контента. Механизм аудита, как правило,Испытание перед выпускома такжеПост-обзордва вида.

  • Испытание перед выпуском

Каналы, размещенные пользователями, должны быть проверены, прежде чем они могут быть распространены среди других пользователей. Таким образом, после того как фид записывается на страницу профиля издателя и страницу новостей, его можно перехватить до того, как он будет записан в очередь сообщений для распространения. Только когда канал будет одобрен, он будет записан в очередь сообщений для распространения записи, так что издатель и другие пользователи не будут знать об этом. Однако для издателей может ощущаться задержка взаимодействия.

  • Пост-обзор

Пользователям сначала может быть разрешена подача диффузного воздействия, выполняемая только тогда, когда проверка не проходитудалятьработать.这种情况下用户的体验会更好，不过会增加平台的一些风险。

4. Нравится дизайн

  • Пользовательский параметр, например список

Пользовательские данные будут храниться в базе данных и кэше Redis. Из-за неопределенности пользовательского поведения некоторым пользователям это может часто нравиться. Поэтому zset-структура redis используется для кэширования части лайков пользователя, поле — это feedId, а счет — это тоже feedId, они располагаются в обратном порядке по фиду, и только последние N кусков кормить, как данные сохраняются.

Почему список лайков пользователя не начинается сКак времяСортировать? Поскольку время лайков пользователя неизвестно, весьма вероятно, что пользователю понравился канал, сделанный давным-давно. Это означает, что когда фид-подобные данные не найдены в кеше, невозможно определить, отсутствует ли кеш или он не понравился пользователю, и, наконец, необходимо снова запросить базу данных для подтверждения.

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

  • Измерение фида Like Count

В нашем сценарии важными данными являются такие параметры канала, как количество. В начале проектирования для синхронизации подсчета использовалось количество повторных операций, но возникала проблема отсутствия подсчетов или повторных подсчетов, и не было возможности обеспечить точность данных. Позже, учитывая, что частота лайков будет не очень высокой, настраивается на получение счетчика из базы данных, а затем синхронизируется с кэшем Redis.

  • Разделить как процесс

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

5. стратегия обмена

  • Square Рекомендуемая стратегия гарантированной страницы

Каналы рекомендаций Square, как правило, представляют собой рекомендательный сервис, который возвращает список каналов, которые более интересны пользователям на основе их характеристик. Когда служба рекомендаций недоступна, необходима конечная стратегия, чтобы гарантировать, что пользователи могут нормально получать информацию из каналов и не влиять на работу пользователей. Здесь реализуется стратегия нижней гарантии с использованием структуры zset Redis для поддержки последних N каналов, опубликованных всеми пользователями. Информация из этого списка возвращается непосредственно, когда служба рекомендаций недоступна.

  • Последние N каналов подписчиков

Когда пользователь только что подписался на другого пользователя, фид подписчика должен появиться на странице новостей пользователя. Учитывая характер информации в режиме реального времени, мы выбираем только последние N каналов подписчика для вставки в новости пользователя, а не список всех каналов подписчика. Эта обработка в основном не влияет на работу пользователя, и обработка относительно проста.

Эпилог

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

Категории