VG
Всем привет. Кто кафку в кубе держит? Чарт от bitnami в продакшне у кого-то есть? Что можете сказать по поводу него? Ошибки, критические замечания есть?
cp-helm-charts или Confluent Operator
Size: a a a
2020 May 06
S
cp-helm-charts или Confluent Operator
Глянем, спасибо
РХ
тут все ок, когда пользователь неактивен, нотификации копятся, как только пользователь подключается нужно их сначала прочитать, затем подписаться на онлайн. Зоопарк да, но кафка не серебрянная пуля
Я так и хотел изначально сделать, но меня настораживают один момент. Во-первых, допустим, пользователь подключается, сервис идет в бд, забирает все события(момент времени А), отправляет клиенту, а затем подписыватся на очередь в Кафка или Redis или что-то еще(момент времени Б). Проблема в том, что между А и Б существует окно времени. Оно очень маленькое, но в это окно кто-то может заперсистить сообщения в бд, поскольку клиент еще не подписан, и получается оффлайн. В таком случае сообщения не будут доставлены. Это окно можно сильно уменьшить, но совсем избавиться мне не представляется как. Если только не блокировать всю таблицу на запись, что такое себе. Понятно, что вероятность такого события мала, но при возрастающей активности пользователей этого исключить нельзя, а когда это выстрелит, понять что именно произошло будет сложно.
РХ
тут все ок, когда пользователь неактивен, нотификации копятся, как только пользователь подключается нужно их сначала прочитать, затем подписаться на онлайн. Зоопарк да, но кафка не серебрянная пуля
Во-вторых, мне неясно как сервис может определить что пользователь оффлайн, потому что отсутствие конкрентно у этого инстанса сервиса соединения с пользователем не означает, что такого соединения нет у другого инстанса. К примеру, пришло сообщение из Кафки на инстанс А сервиса, он смотрит и видит что у него нет соединения с пользователем для этого сообщения. Значит ли это что клиент оффлайн и тогда нужно заперсистить в бд или может клиент сейчас подключен к инстансу Б сервиса. Можно конечно всем инстансам читать одни и те же сообщения из топика, но страдает масштабирование. Ну или настроить балансировщик так, чтобы соединение приходило на тот инстанс, на который приходит соединение из Кафки.
РХ
Alexandr Smirnov
как начсет того чтобы использовать кафка стримы
и сообщения пользователей хранить в локальном стейте
и сообщения пользователей хранить в локальном стейте
спасибо, не работал с этой технологией, почитаю доки
DT
Я так и хотел изначально сделать, но меня настораживают один момент. Во-первых, допустим, пользователь подключается, сервис идет в бд, забирает все события(момент времени А), отправляет клиенту, а затем подписыватся на очередь в Кафка или Redis или что-то еще(момент времени Б). Проблема в том, что между А и Б существует окно времени. Оно очень маленькое, но в это окно кто-то может заперсистить сообщения в бд, поскольку клиент еще не подписан, и получается оффлайн. В таком случае сообщения не будут доставлены. Это окно можно сильно уменьшить, но совсем избавиться мне не представляется как. Если только не блокировать всю таблицу на запись, что такое себе. Понятно, что вероятность такого события мала, но при возрастающей активности пользователей этого исключить нельзя, а когда это выстрелит, понять что именно произошло будет сложно.
возьми RX, подпишись на новые сообщения, затем прочитай базу, слей всё в один observable и читай уже его. так ты решишь проблему окна
DT
Во-вторых, мне неясно как сервис может определить что пользователь оффлайн, потому что отсутствие конкрентно у этого инстанса сервиса соединения с пользователем не означает, что такого соединения нет у другого инстанса. К примеру, пришло сообщение из Кафки на инстанс А сервиса, он смотрит и видит что у него нет соединения с пользователем для этого сообщения. Значит ли это что клиент оффлайн и тогда нужно заперсистить в бд или может клиент сейчас подключен к инстансу Б сервиса. Можно конечно всем инстансам читать одни и те же сообщения из топика, но страдает масштабирование. Ну или настроить балансировщик так, чтобы соединение приходило на тот инстанс, на который приходит соединение из Кафки.
если я все правильно понял, так у тебя вообще ничего работать не будет
РХ
возьми RX, подпишись на новые сообщения, затем прочитай базу, слей всё в один observable и читай уже его. так ты решишь проблему окна
выглядит здорово
РХ
если я все правильно понял, так у тебя вообще ничего работать не будет
почему?
DT
если у тебя у балансер не на липких сессиях, то пользак 2 может пойти на сервис 1 на нотификациями, а сервис 1 читает партицию, в которй для этого пользователя сообщений нет.
MD
всем привет, хотел узнать, есть ли какая-то возможность обработать ошибку о том, что не удалось подключиться к кафке, когда она пишет
Connection to node could not be established. Broker may not be available.? Судя по сорцам, там нет никаого эксепшна и никак это обработать нельзя, в гугле тоже ничего не нашел, кроме нескольких сообщений о том, что так и задуманоРХ
если у тебя у балансер не на липких сессиях, то пользак 2 может пойти на сервис 1 на нотификациями, а сервис 1 читает партицию, в которй для этого пользователя сообщений нет.
да, все так. у нас сейчас роунд робин, хочется чтобы клиент подключался к любому инстансу и вжух все работало)
AS
да, все так. у нас сейчас роунд робин, хочется чтобы клиент подключался к любому инстансу и вжух все работало)
Кафка стримс)))
AS
Узлы будут делать квери между собой
AS
Подробно описано в книгe kafka streams in action
DT
да, все так. у нас сейчас роунд робин, хочется чтобы клиент подключался к любому инстансу и вжух все работало)
я бы рассматривал кафку как промежуточный буфер и потоково сортировал нотификации, которые бы раскладывал в редис по ключам (user:natofication.type)
AS
В Кассандру тоже можно