Comments 18
Т.е. добавлять kafka это не "затягивать новую технологию, усложнять инфраструктуру", а redis - усложнять?
У нас нет четкого представления о том, как инвалидировать кеш на основе TTL (time to live), поскольку бизнес правила не позволяют жить невалидному кешу хоть какое-то время.
Применение Kafka и Event-Driven Architecture вопрос/проблему с инвалидацией разве решают как-то?
Скорее речь о том, что с помощью этого подхода мы совсем отказываемся от состояния невалидного кеша, ну или продолжительность этого состояния ничтожно мала.
Честно - непонятно. Вот у нас какой-то сервис, который должен в реальном времени возвращать данные о свободных остатках товаров на складах. Допустим бизнес требует, чтобы в каждый момент времени пользователь получал актуальные на сейчас данные. То есть мы даже TTL в одну микросекунду не хотим ставить, потому что за эту микросекунду кто-то товар зарезервирует или наоборот отменит резерв.
Чем нам в этой ситуации Kafka поможет?
В целом, паттерн из статьи не позиционируется как серебряная пуля для любых задач, связанных с синхронизацией и доступом к актуальным данным.Конечно есть задачи с более жесткими требованиями, и они требуют совершенно других подходов.
Поддерживаю предыдущего оратора.
Не понятны требования к Кешу и почему он при таких ограничениях должен быть распределенным.
Кафка это хорошо, но не дает гарантию ‘синхронности данных’: процесс А послал обновление данных, процесс Б прочитал его из Кафка. У процесса С на машине была проблема с производительностью, а потом сетевое соединение отвалилось, а потом она перезапустилась…
В итоге пользователь на машине С получил обновленную версию Кеша через 30 секунд.
Вы похоже стараетесь найти решение задачи о византийских генералах, которая не имеет решения. Вы не можете обеспечить согласованность данных в распределенной системе. Единственно решение raft - подобные протоколы, которые лишь гарантируют что данные будут согласованы в какой-то момент времени.
Например передача большого количества текста по сети, между кешом и репликой, это может накладывать серьезный отпечаток на производительности.
Если мы говорим о синхронности в любой момент времени, то конечно тут возникает куча проблем. Но возможны задачи которые не имеют жесткий требований к синхронизации данных, даже задержка в 30 секунд и более для нас не критична (например это может быть какое-то длинное описание товара).
Но замечание справедливое, отмечу этот момент в тексте.
Тогда кто вам мешает инвалид позвать кеш по времени?
Тогда непонятно по какому времени. Если мы возьмем условно минуту, то каждую минуту с каждой реплики мы будем ходить в хранилище за миллионами или даже десятками миллионов записей, хотя возможно этого не надо было делать, мы создаем рабочую нагрузку на ровном месте. Вполне допустимо инвалидировать по времени, если например мы давно не получали сообщения о синхронизации, получится совмещенный вариант.
Вы не будете «ходить в хранилище за миллионами записей». Только когда кеш невалидный будете перечитывать записи. Не думаю что у вас каждое 30 секунд миллионы записей запрашиваются.
Давайте ближе к теме: сколько серверов, сколько данных сколько запросов в секунду. Ну и неплохо было бы про задачу написать. А-то осуждаем сферического коня в вакууме
Мне для самообразования. Вот вы указали, что централизованный кеш не подошел из-за того, что это сетевой запрос.
Но в тоже время вы заюзали "централизованную" кафку. Разве общение с ней, не есть сетевые запросы или ... ?
Да, это сетевые запросы, но они никак не влияют на производительность сервиса, так суть данного паттерна - не гонять супер много данных через кафку, а условно "посигналить" всем остальным что нужно обновить кеш. Для этого достаточно просто пустого сообщения, в самом простом случае, ну или передать просто пару ключей в случаях сложнее. Так же go позволяет писать конкурентный код, это так-же можно использовать в случае записи больших сообщений параллельно каких-то сетевых операций сервиса. Так же есть возможность асинхронной записи, но это уже риск потерять сообщения.
Инвалидация кэша на воркерах по таймауту скорее всего решит все ваши проблемы без кафки и смс. Не знаю сколько у вас инстансов в онлайне, но вряд ли сотни и тысячи. Так что доп нагрузку на бд (или что вы там кэширует) от этих запросов даже не заметите
не знаете, как запускать приложения в виртуалке - не усложняйте себе жизнь, возьмите кубернетес..
Выглядит так, что проще все таки было бы redis завести =))
Синхронизация кеша в распределенных Go (и не только) приложениях с помощью Kafka