Народ, и мне посоветуйте плз %) 1) есть sql база 2) есть

Question

Народ, и мне посоветуйте плз %) 1) есть sql база 2) есть

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

3) есть куча мелких сервисов (бекенды сайтов, еще какие-то мелкие штуки), которые обращаются к этому общему беку (grpc, go-micro -> эти мелкосервисы можно плодить и взаимозаменять как угодно)

----

Проблема: "толстый бек" может быть только один, т.к. в случае поднятия >1 возникнет инконсистентность кеша
Хочется поиметь возможность эти "толстые беки" плодить -- но не могу решить, как лучше :(

а) какой-нибудь брокер сообщений, куда они будут плеваться изменениями своего кеша, а остальные инстансы - слушать и реагировать. Хз, как-то переусложнённо =/

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

в) ???

#backend #go #programming #russian

0

07.02.2019

3 ответов

11 просмотров

Пользователь 6124b

я за Б - что-то с репликацией из коробки, типа редисов или тарантулов

0

07.02.2019

Wingman Автор вопроса

Ну то есть, вариант б =)

0

07.02.2019

Roman Covanyan · Accepted Answer

если нужно ACID в кэше, рискну предложить архитектуру - одна пишущая, много читающих нод, фоновая репликация. если идет запись в мастер, он сам и все читающие блокируются до момента очередной синхронизации, но до окончания их блокировки - изменение в мастере не применяется. каждый разблокируется при получении сообщения синхронизации (либо если упал), а мастер применяет изменения последним. пишущего можно перевыбирать, например, по raft алгоритму, или по анализу степени загруженности ноды. но проблемы синхронизации так или иначе будут все равно. raft еще помогает хранить журналы для упавшей ноды и восстанавливать ноду после ее возвращения в кластер. посмотри реализацию etcd, там интересно сделано.

170 похожих чатов

Народ, и мне посоветуйте плз %) 1) есть sql база 2) есть

3 ответов

Похожие вопросы