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, который можно передавать между процессами. Потому скорее всего если надо совсем упороться, я бы писал клиент не на джаве или другом высокоуровневом относительно языке или передавал бы джаве как-то хитро разделяемое между процессами соединение, которое вообще живет независимо от того на чем бизнеслогика написана.

@mudasobwa но первый вариант был бы точно на спринге. И только если он не подошел, все махинации не помогли уже можно упарываться.

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

@mudasobwa кафкакластеры нужны когда клиентов полк, тут это все просто лишние точки отказа и потери за счет замедления реконнектов и рестартов. Минимальных потерь в таком случае конкретном можно в двести строк кода достичь.

@mudasobwa ну и что бы совсем упороться, вотчдог научить юзать два процесса. Один живой, второй под парами. Что бы время старта процесса исключить из времени потерь...хотя оно будет минимальное если не джава. Там через стдин или другой рпц, и ожидание завершения все это можно сделать без всяких распределенных блокировок. В итоге время потерь будет только реконнект в случае проблем с сетью и схема простая как полено.

@mudasobwa останется подумать только о смерти сервера, но это тоже решаемо. Суть, просто лить байтовый поток на диск блоками без буферов и все.