Ради этого вопроса и чтобы лучше проиллюстрировать мою проблему, давайте попробуем отладить, как instagram может обслуживать бесконечно прокручиваемый фид .(Также обратите внимание, что этот вопрос о том, как они подают фид, а , а не о том, как они ранжируют посты в фиде.)
Вот что я получил:
Пользователь открывает приложение в t1 .Он отправляет запрос на получение канала для этого пользователя.
Сервер находит все сообщения между t1 (текущее время) и t0 (время последней активности пользователя).Допустим, они оказываются 1000 .
Затем сервер отфильтровывает сообщения из этих 1000 , которые будутиметь отношение к этому конкретному пользователю.Допустим, в итоге получается 250 сообщений.
Затем сервер использует черный ящик для ранжирования (оценки) этих сообщений на основе некоторых huerisitcs..
После этого он сохраняет 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, и т. Д.?Какой самый быстрый способ сделать это?