RB
Но база все равно нужна для гарантий доставки
Size: a a a
2020 December 09
RB
Конечно можно и гибридный какой то вариант придумать. А-ля сделать сервис-дискавери в консюмере кафки, чтобы он знал какие signalr клиенты к какому инстансу подключены и рассылал нужным инстансам нотификашки в стиле: отправь Васе Пупкину что его заказ будет выполнен 01.01.2077 в 13:37
Плюс для доступности этой штуки прийдется сгородить консенсус и раскидывать распределённый инмемори стейт
RB
Если хотим чтобы всё летало
RB
Но и в этой схеме есть лаг между событием условного отключения клиента и тем, как стейт окажется согласованным на всех инстансах
RB
То бишь ивеншуал консистенси
RB
В обмен на скорость
RB
Пушо условный Вася может зайти не только с компа, но и с телефона. Вот он к бэку сигналра подключился, а ивент сконсьюмился инстансом, который про это ни сном ни духом, так как стейт не доехал ещё - нотификашка прилетела только в браузер.
RB
Или наоборот, клиент отключился, мы пинаем бэк сигналра - мол отправляй, а он нам в ответ - а некому отправлять
RB
Короч много корнер кейсов
RB
А можно просто выкинуть гарантию доставки
RB
RB
Конечно можно и гибридный какой то вариант придумать. А-ля сделать сервис-дискавери в консюмере кафки, чтобы он знал какие signalr клиенты к какому инстансу подключены и рассылал нужным инстансам нотификашки в стиле: отправь Васе Пупкину что его заказ будет выполнен 01.01.2077 в 13:37
AH
да
SA
Спасибо)
RB
Shukurdin Aidarov
@vanbukin, расскажу потом как сделаем или сделаю (полгода как один бэкендер в команде).
Давай
A
Загугли про Redis backplane для signalr
Главное там всю документацию прочитать
A
Shukurdin Aidarov
Всем привет, я опять со своей болью.
Есть сервис который читает сообщения из кафки и отправляет его клиенту по веб-сокету. Недоставленные сообщения сервис хранит у себя в памяти пока действует ttl. Отправленые же сообщения он удаляет после получения потверждения от клиента (гарантийная доставка).
Дело в том что инстансов этого сервисе очень много и сообщений в кафке много, но одно сообщение предназначено для одного клиента. То есть клиент создает соединение с каким определенным инстансом сервиса, поэтому каждому инстансу приходится читать копию сообщения, чтобы можно было отправить его клиенту. Из-за этого в каждом инстансе становится очень много сообщений, которые доставить невозможно потому что соединение с нужным клиентом только на одном инстансе.
Чтобы сервис не упал из-за нехватки памяти мы сделали ограничение на максимальное количество сообщений в сервисе. Но из-за этого у нас увеличилось время доставки сообщения клиенту (лаг в кафке около 1500 сообщений).
Так вот думаем не хранить сообщения в памяти а хранить в бд - она конечно не реизновая, но в нее гораздо больше влезет. Можем чистить бд раз в день.
Как считаете норм будет или нет?
Есть сервис который читает сообщения из кафки и отправляет его клиенту по веб-сокету. Недоставленные сообщения сервис хранит у себя в памяти пока действует ttl. Отправленые же сообщения он удаляет после получения потверждения от клиента (гарантийная доставка).
Дело в том что инстансов этого сервисе очень много и сообщений в кафке много, но одно сообщение предназначено для одного клиента. То есть клиент создает соединение с каким определенным инстансом сервиса, поэтому каждому инстансу приходится читать копию сообщения, чтобы можно было отправить его клиенту. Из-за этого в каждом инстансе становится очень много сообщений, которые доставить невозможно потому что соединение с нужным клиентом только на одном инстансе.
Чтобы сервис не упал из-за нехватки памяти мы сделали ограничение на максимальное количество сообщений в сервисе. Но из-за этого у нас увеличилось время доставки сообщения клиенту (лаг в кафке около 1500 сообщений).
Так вот думаем не хранить сообщения в памяти а хранить в бд - она конечно не реизновая, но в нее гораздо больше влезет. Можем чистить бд раз в день.
Как считаете норм будет или нет?
Хранить в памяти плохо. Подходов несколько может быть.
1. Пометить сообщение недоставленым и забить. Так делаем мы и гитхаб.
2. Положить сообщение заново в очередь и отложить на сколько то. Плохой вариант если вам вдруг важен порядок. Но если важен порядок, то пока не доставишь, следующее брать нельзя.
1. Пометить сообщение недоставленым и забить. Так делаем мы и гитхаб.
2. Положить сообщение заново в очередь и отложить на сколько то. Плохой вариант если вам вдруг важен порядок. Но если важен порядок, то пока не доставишь, следующее брать нельзя.
IB
Хранить в памяти плохо. Подходов несколько может быть.
1. Пометить сообщение недоставленым и забить. Так делаем мы и гитхаб.
2. Положить сообщение заново в очередь и отложить на сколько то. Плохой вариант если вам вдруг важен порядок. Но если важен порядок, то пока не доставишь, следующее брать нельзя.
1. Пометить сообщение недоставленым и забить. Так делаем мы и гитхаб.
2. Положить сообщение заново в очередь и отложить на сколько то. Плохой вариант если вам вдруг важен порядок. Но если важен порядок, то пока не доставишь, следующее брать нельзя.
а что потом происходит с недоставленными сообщениями?