Кэш сквозной записи Redis

Question

Я размышлял над тем, как надежно реализовать механизм сквозного кэширования для хранения данных в реальном времени.

В основном нам нужно следующее:

Save data to Redis -> Save to database (underlying)  
Read data from Redis <- Read from database in case unavailable in cache  

Ресурсы в Интернете, помогающие в реализации этой стратегии кэширования, кажутся скудными.

Проблема заключается в следующем:

1) Нет возможности встроенной транзакции между Redis и базой данных (в моем случае Mongo).
2) Нет транзакций, означающих запись в базовую базу данныхненадежны.

Самый простой способ увидеть, как это можно реализовать, - это использовать посредника, такого как Kafka, и помещать сообщения в постоянную очередь для последующей обработки.
Поэтому Kafka будет ответственным за надежную обработку.

Другим способом было бы наличие пользовательской реализации в планировщике, который проверяет базу данных Redis на наличие грязных записей.На первый взгляд, кажется, есть некоторые компромиссы в этом подходе, и я бы не хотел идти по этому пути, если это возможно.

Я смотрю на некоторые варианты того, как это может быть реализовано в противном случае.
Или это на самом деле самый жизнеспособный подход.

Answer 1

При рассмотрении я буду использовать MongoDB как единое хранилище данных без Redis вообще.
Преждевременная оптимизация это зло, я думаю.

Во всяком случае, я могу добавить дополнительную архитектуру после тестирования.
Планы по рефакторингу к кешу не должны быть слишком сложными.

Масштабирование является дополнительной проблемой, поэтому я не должен беспокоиться об этом во время разработки прямо сейчас.

Принято @Ipave ответ, пока что с одним хранилищем данных.

Answer 2

Таким образом, лучший подход, чем упомянутый выше, состоит в том, чтобы использовать Кафку и Потребителя, которые будут хранить данные в Монго.Но прочитайте о ней гарантию доставки, поскольку я точно помню, что однажды она гарантирована только в потоках kafka (между двумя темами), в вашем случае ваша база данных должна быть идемпотентной, потому что вы получите хотя бы раз гарантию.И не забудьте включить AOF с Redis, чтобы не потерять данные.И не забывайте, что в этом случае вы получаете конечную согласованность в БД со всеми вытекающими последствиями.