Архитектура для кеша Redis & Mongo для сохранения

Question

Настройка:
Представьте себе услугу «Twitter», где пользователь отправляет сообщение, которое затем считывается многими (сотнями, тысячами или более) пользователями.

Мой вопрос касается наилучшего способа архивирования кэша & базы данных для оптимизации для быстрого доступа & многие читают, но при этом сохраняют исторические данные, чтобы пользователи могли (если захотят) видеть старые сообщения. Предположение здесь состоит в том, что 90% пользователей будут интересоваться только новыми вещами, и что старые материалы получат доступ к ним изредка. Другое предположение здесь состоит в том, что мы хотим оптимизировать 90%, и это нормально, если более старые 10% занимают немного больше времени для извлечения.

Имея это в виду, мои исследования, похоже, указывают на использование кеша на 90%, а затем также сохраняют сообщения в другой долговременной постоянной системе. Поэтому до сих пор моя идея - использовать Redis для кеша. Преимущества в том, что Redis работает очень быстро, а также встроен в паб/sub, который идеально подходит для публикации сообщений многим людям. И затем я рассматривал возможность использования MongoDB в качестве более постоянного хранилища данных для хранения тех же сообщений, которые будут доступны по мере истечения срока действия Redis.

Вопросы:
1. Поддерживает ли эта архитектура воду? Есть лучший способ сделать это?
2. Что касается механизма хранения сообщений как в Redis & MongoDB, я думал о том, что приложение делает 2 записи: 1-й - напишите Redis, он сразу же доступен для подписчиков. 2-й - после успешного хранения в Redis, немедленно напишите MongoDB. Это лучший способ сделать это? Должен ли я вместо этого использовать Redis, нажимая истекшие сообщения в MongoDB? Я подумал об этом, но я не мог найти много информации о том, как напрямую обращаться к MongoDB от Redis.

Answer 1

На самом деле разумно ассоциировать Redis и MongoDB: они хорошие игроки команды. Вы найдете более подробную информацию здесь:

MongoDB with redis

Одна критическая точка является уровень отказоустойчивости вам нужно. Как Redis, так и MongoDB могут быть настроены на достижение приемлемого уровня отказоустойчивости, и эти соображения должны обсуждаться во время разработки. Кроме того, это может привести к ограничению возможностей развертывания: если вам нужна репликация master/slave как для Redis, так и для MongoDB, вам нужно как минимум 4 окна (Redis и MongoDB не должны быть развернуты на одном компьютере).

Теперь может быть немного проще сохранить Redis для очередей, pub/sub и т. Д. И сохранить данные пользователя только в MongoDB. Обоснование заключается в том, что вам не нужно разрабатывать аналогичные пути доступа к данным (сложная часть этой работы) для двух магазинов с различными парадигмами. Кроме того, MongoDB имеет встроенную горизонтальную масштабируемость (наборы реплик, автоматическое отрисовку и т. Д.), В то время как Redis имеет только масштабируемость по-своему.

Что касается второго вопроса, письмо в оба магазина было бы самым простым способом сделать это. Нет встроенной функции для репликации активности Redis в MongoDB. Проектирование демона, слушая очередь Redis (где активность будет опубликована), и писать в MongoDB не так сложно.