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