Архитектор сайта/приложения, основанного на голосовании

Question

Я работаю над веб-сайтом. Я хотел получить отзывы о дизайне. Функция сайта похожа на Reddit, ProductHunt и т. Д. (Т. Е. На основе голосования). Вот обзор 1. Бэкэнд-сервис получает сообщения из Интернета и хранит в БД. 2. Сообщения отображаются на веб-сайте (вверху, новинке). 3. В верхнем разделе показан веб-сайт, основанный на рейтинге (голосов, временных факторах). 4. На свитке, пользователь видеть больше сообщений

Дизайн:

Таблицы базы данных: Сообщения, пользователи, голос

Backend обслуживание: бэкенда службы получает сообщения из сети периодически и хранит в БД (сообщения Таблица).

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

Вопрос: Должен ли я использовать кеш Redis вместо запроса базы данных для получения ранжированных сообщений по каждому запросу? Если да, то что нужно хранить в кеше и какова должна быть логика обновления кеша?

Если я в конечном итоге использую кеш, кеш должен содержать две записи. 1. Ранжированные должности 1. Новые должности. Для ранжированных должностей необходимо периодически обновлять кеш обновления службы? и для новых сообщений следует ли я аннулировать кеш всякий раз, когда новая почта выводится из Интернета?

Также как иметь дело с бесконечным прокруткой, если я иду с кеш-маршрутом? Пример: пользователь видит сообщения, основанные на ранжировании. Пользователь прокручивает новые сообщения через 15 минут. к тому времени рейтинг мог бы измениться.

Буду признателен за любые отзывы/помощь!

Answer 1

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

• Для ранжированных сообщений вы можете использовать Sorted Sets. Это позволит вам получить оценку за каждый пост, который будет числом голосов, и он будет сортировать ваши сообщения на основе этой оценки. У вас есть команда для увеличения оценки существующего сообщения - ZINCRBY.Вы можете обновлять кеш в то же время при обновлении базы данных
• Для новых сообщений вы можете использовать lists, так как вы можете легко добавлять элементы перед списком, когда создается новое сообщение, используя LPUSH, а также сохраняйте это фиксированная длина с использованием LTRIM
• Для бесконечной прокрутки есть больше решений, все с их ценой: вы можете использовать команду ZRANGEBYSCORE с параметром Limit, чтобы получить пункты , поэтому, если что-то меняется, отобразите его
• Также, когда вам понадобится сделать 2 или более команды в атомном режиме, например, если вы хотите, чтобы новые сообщения создавались для поддержания всегда l atest 50 вам нужно назвать LPUSH и LTRIM одной командой, вы можете сделать это с помощью LUA Scripting