Gregory's Server@3draven был бы очень признателен за ссылку / объяснение, как это принято делать на джаве
|
16 comments
 @s1dul @mudasobwa @3draven мне кажется что на akka концептуально легче всего будет такое сделать, она вроде из коробки сама умеет в кластер и разные ноды. Правда akka на java очень коряво пишется, лучше на scala. На go вообще быстро в голову ничего не приходит.  Пф, в кластер и разные ноды умеет даже наколеночный похапе, если руки не из жопы. Я не собираюсь писать на джаве (хотя все для JRE я пишу на скале, конечно, от джавы меня тошнит). Меня интересовало архитектурное решение, и акка, к сожалению, решает кластерный синглтон очень плохо. @mudasobwa @kurator88 @3draven как делал бы я: Если время не приемлемое, завести несколько инстансов и к ним всем примонтировать один разделенный том. Дальше инстанс начинает пытаться открыть на эксклюзивную запись заранее определенный лок-файл. Кто смог захватить, тот устанавливает соединение и начинает работать. Остальные продолжают бесконечно ждать и часто-часто пытаться захватить лок. @s1dul у меня BEAM, я могу без локфайла напрямую спросить, жив ли процесс, у соседней ноды. Но часто-часто долбиться куда-либо — это за гранью, я лично разворачиваю PR не глядя, если там есть вызов sleep, хочется все-таки один раз получить входящее сообщение «теперь ты главный». @s1dul я понимаю, что если выключится электричество во всех датацентрах, или норвежские строители опять переебут атлантический кабель экскаватором, как в 1997, все будет плохо. Но мне надо хотя бы побороть простые рестарты контейнера, или внезапный отказ всего приложения на ноде с соединением. Про синглтон в акка я читал, там все плохо.  @mudasobwa Слишком краткое описание. Непонятно, что значит "простои не допускаются". Простои кого именно? Источника данных? Кластера обработки? Или каждой ноде в кластре нельзя ждать освобождения источника? Но в целом я бы просто посмотрел на Spark или Hadoop, либо на Zookeeper (или аналоги) и не проектировал их работу сам. Решать задачи выбора лидера дело непростое и делать это в сотый раз думаю смысла нет, уже делали. Ну или если надо "почти сам" akka. @3draven источник шлет нам стопиццот сообщений в секунду через вебсокет; хочется пропустить в случае факапа как можно меньше сообщений. Я не понимаю, если честно, зачем тут лидер, нам надо просто, чтобы подключен был всегда только один процесс, но я уже понял в соседней ветке, что теория (и джава-путь) предлагает построить вокруг стоэтажное сооружение с консенсусом. Спасибо! Узнать бы еще , как там гошники это решают :) @mudasobwa Джава это готовые решения. Очень надо большое обоснование что бы пилить свое решение. Что уж тут, таков путь :) Конкретно под летящие события огромным потоком с обработкой если я верно помню делали Spark. Но я его только видел, не копал, так что пошел бы изучать подробнее. Ну или бы завернул бы весь поток в кафку с одного коннекта...что более знакомо и уже к ней всех цеплял и медленно и печально что то считал. От подробностей задачки и бизнес требований зависело бы. @3draven спарк тоже не очень понятно, как поможет переконнектиться, если упадет то, что прицеплено в вебсокету @mudasobwa Тут надо понять почему вдруг вебсокет один всего от клиента. Он сам по себе сеть и может навернуться в любой момент. Так что как ни вертись на своем кластере, а не вывертишь надежного решения с всего одним коннектом без контроля того как работает клиент. Если же контроль клиента есть, есть и ретрай. Собственно кафка-коннект в спринге так и пашет, надежности не достичь без контроля как сервера (кафки) так и клиента (спринга) и их соглашений о работе. @3draven вебсокет один, потому что второй будет стоить еще 15К в месяц, провайдер данных фактически монополист. Клиент упал, по какой-то причине. Кто его перезапустит? Причем тут вообще кафка? @mudasobwa обычно кубер перезапускает, да это не та задача о которой я подумал. До дела бы дошло я бы еще сто раз потестил и подумал, но скорее всего это был бы редис в кубере, распределеная блокировка спринговая, он их умеет (и поверх постгри вроде) и несколько подов, что ее ждут наготове что бы не ждать перезапусков. Я такое не делал, просто первое, что подумалось. |
@mudasobwa @3draven мне кажется, либо я не понимаю условий, либо задача шатает cap теорему.
Но даже если просто порассуждать, если соединений строго не больше одного, без даунтайма не обойтись. Но даунтайм можно сделать очень коротким.
Можно почитать про синглтон в акка. Там сложность вопроса координации раскрывается. Но соединение само по себе может оторваться и обеспечить даунтайм