#database #data-structures #feed
#База данных #структуры данных #лента
Вопрос:
Ради этого вопроса и чтобы лучше проиллюстрировать мою проблему, давайте попробуем отладить, как instagram мог бы обслуживать свою бесконечно прокручиваемую ленту. (Также обратите внимание, что этот вопрос касается того, как они обслуживают ленту, а не о том, как они ранжируют сообщения в ленте.)
Вот что у меня есть:
-
Пользователь открывает приложение на t1. Он отправляет запрос на получение ленты для этого пользователя.
-
Сервер находит все сообщения между t1 (текущее время) и t0 (время последней активности пользователя). Допустим, их окажется 1000.
-
Затем сервер отфильтровывает сообщения из этих 1000, которые будут иметь отношение к данному конкретному пользователю. Допустим, в итоге получается 250 сообщений.
-
Затем сервер использует черный ящик для ранжирования (оценки) этих сообщений на основе некоторых пользовательских данных.
-
После этого он сохраняет эти 250 идентификаторов сообщений в REDIS.
-
Из 250 идентификаторов он разбивает на страницы и находит первые 30 идентификаторов. Затем он запрашивает всю информацию для этих 30 сообщений и отправляет результат обратно вызывающему абоненту.
Все круто? Хорошо.
Теперь пользователь прокручивает страницу вниз, и вскоре она исчерпала 15 сообщений. Поскольку Instagram — это круто, он замечает, что пользователь уже исчерпал 15 сообщений, и автоматически выбирает следующие 30 сообщений, при этом пользователь не видит индикатор выполнения «ЗАГРУЗКА».
Где-то в будущем, вот что происходит на сервере: у него заканчиваются кэшированные 250 идентификаторов, хранящихся в REDIS.
КЛЮЧ ВРЕМЕНИ:
t0: последнее действие пользователя перед открытием приложения сегодня. (Может быть, за два дня до этого, может быть, за 5 часов. Мы не знаем.)
t1: сегодня пользователь впервые открыл приложение.
t2: пользователь прокрутил первые 30 сообщений и попросил добавить больше сообщений. Или пользователю понравился пост. Может быть любой вид деятельности. Мы не знаем.
Если он получает запрос сейчас, он должен показывать старое содержимое. Старше, чем t0 . Это потому, что при прокрутке вниз вы фактически возвращаетесь в прошлое. Поскольку последнее действие пользователя было t0 (когда он в последний раз открывал приложение, а не сейчас), нам нужно найти сообщения старше t0. Однако мы больше не храним t0, поскольку последнее действие пользователя, возможно, изменилось на t6.
Как мне это решить?
Кроме того, если пользователь прокручивает назад и запрашивает новые сообщения: нам все равно нужно вычислять новые сообщения после t1 (это когда пользователь открыл приложение прямо сейчас) до прямо сейчас и добавлять их в кэш REDIS ВВЕРХУ.
Как мне отслеживать эти t0, t1 и т.д.? Каков самый быстрый способ сделать это?