|
Top-level
 @mudasobwa Джава это готовые решения. Очень надо большое обоснование что бы пилить свое решение. Что уж тут, таков путь :) Конкретно под летящие события огромным потоком с обработкой если я верно помню делали Spark. Но я его только видел, не копал, так что пошел бы изучать подробнее. Ну или бы завернул бы весь поток в кафку с одного коннекта...что более знакомо и уже к ней всех цеплял и медленно и печально что то считал. От подробностей задачки и бизнес требований зависело бы. 5 comments
 @3draven спарк тоже не очень понятно, как поможет переконнектиться, если упадет то, что прицеплено в вебсокету @mudasobwa Тут надо понять почему вдруг вебсокет один всего от клиента. Он сам по себе сеть и может навернуться в любой момент. Так что как ни вертись на своем кластере, а не вывертишь надежного решения с всего одним коннектом без контроля того как работает клиент. Если же контроль клиента есть, есть и ретрай. Собственно кафка-коннект в спринге так и пашет, надежности не достичь без контроля как сервера (кафки) так и клиента (спринга) и их соглашений о работе. @3draven вебсокет один, потому что второй будет стоить еще 15К в месяц, провайдер данных фактически монополист. Клиент упал, по какой-то причине. Кто его перезапустит? Причем тут вообще кафка? @mudasobwa обычно кубер перезапускает, да это не та задача о которой я подумал. До дела бы дошло я бы еще сто раз потестил и подумал, но скорее всего это был бы редис в кубере, распределеная блокировка спринговая, он их умеет (и поверх постгри вроде) и несколько подов, что ее ждут наготове что бы не ждать перезапусков. Я такое не делал, просто первое, что подумалось. |
Gregory's Server
@3draven заворачиватель потока в кафку не может навернуться?