Just out of curiosity, how do you architect a sticky singleton across cluster in your language of choice?

E. g. the only one simultaneous connection to the external source is allowed, but to handle data we need several nodes. How do we ensure there is the only one connection (downtime is not allowed.)

Thanks in advance. Most wanted solutions: java, go, node.

@3draven был бы очень признателен за ссылку / объяснение, как это принято делать на джаве

@mudasobwa Слишком краткое описание. Непонятно, что значит "простои не допускаются". Простои кого именно? Источника данных? Кластера обработки? Или каждой ноде в кластре нельзя ждать освобождения источника?

Но в целом я бы просто посмотрел на Spark или Hadoop, либо на Zookeeper (или аналоги) и не проектировал их работу сам. Решать задачи выбора лидера дело непростое и делать это в сотый раз думаю смысла нет, уже делали. Ну или если надо "почти сам" akka.

@3draven источник шлет нам стопиццот сообщений в секунду через вебсокет; хочется пропустить в случае факапа как можно меньше сообщений.

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

Спасибо!

Узнать бы еще , как там гошники это решают :)

@mudasobwa Джава это готовые решения. Очень надо большое обоснование что бы пилить свое решение. Что уж тут, таков путь :)

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

@3draven заворачиватель потока в кафку не может навернуться?

@mudasobwa Тут надо понять почему вдруг вебсокет один всего от клиента. Он сам по себе сеть и может навернуться в любой момент. Так что как ни вертись на своем кластере, а не вывертишь надежного решения с всего одним коннектом без контроля того как работает клиент. Если же контроль клиента есть, есть и ретрай. Собственно кафка-коннект в спринге так и пашет, надежности не достичь без контроля как сервера (кафки) так и клиента (спринга) и их соглашений о работе.

@3draven вебсокет один, потому что второй будет стоить еще 15К в месяц, провайдер данных фактически монополист.

Клиент упал, по какой-то причине. Кто его перезапустит? Причем тут вообще кафка?

@mudasobwa обычно кубер перезапускает, да это не та задача о которой я подумал. До дела бы дошло я бы еще сто раз потестил и подумал, но скорее всего это был бы редис в кубере, распределеная блокировка спринговая, он их умеет (и поверх постгри вроде) и несколько подов, что ее ждут наготове что бы не ждать перезапусков. Я такое не делал, просто первое, что подумалось.

@mudasobwa но, честно сказать, я бы еще посмотрел вот на что. Коннект это объект в ОС linux, который можно передавать между процессами. Потому скорее всего если надо совсем упороться, я бы писал клиент не на джаве или другом высокоуровневом относительно языке или передавал бы джаве как-то хитро разделяемое между процессами соединение, которое вообще живет независимо от того на чем бизнеслогика написана.