Представьте себе приложение, подобное Instagram, с бесконечной подачей.Фид заполняется на основе множества факторов, таких как друзья, подписанные аккаунты и т. Д.
Далее, давайте предположим, что есть таблица с именем Posts, которая содержит все сообщения , которыев настоящее время в Instagram.
И есть конечная точка GET /user/feed?page=1, которая возвращает разбитый на страницы массив постов, которые вошедший в систему пользователь увидит в своей ленте при открытии приложения.
Инаконец, в бэкэнде этого маршрута есть сложный алгоритм (X), который ранжирует тысячи сообщений, чтобы в итоге получить 100-500 массивов PostIds, которые увидит пользователь.Все круто, верно?
Поскольку конечная точка, GET /user/feed?page=1, разбита на страницы:
Один из способов перебора - это перерасчет массива соответствующих сообщений итонко пропустите сообщения page * POSTS_PER_PAGE и вернитесь.Это уродливое решение, работающее по принципу albiet.
Другой способ - создать хранилище Redis перед основной базой данных MySQL, которая кэширует канал (массив сообщений) длякаждый пользователь около 30 минут?(Я выбрал 30 минут, предполагая, что пользователь использует приложение прямо сейчас, и мы должны очень быстро возвращать результаты, пока он / она прокручивает. Как только они выходят из приложения и возвращаются после, скажем, 2 hours, он только делаетимеет смысл пересчитать PostIds и заново заполнить кеш. Если вы считаете, 30 minutes слишком резкий, предложите другой предел.)
Достаточно ли подходит второй метод или я его пропускаю?что-то?Любая обратная связь будет оценена.