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 останется подумать только о смерти сервера, но это тоже решаемо. Суть, просто лить байтовый поток на диск блоками без буферов и все.
@3draven а зачем диск? Почему нельзя прямо в обработчик лить? Консьюмер-то наш, все под контролем.
В остальном я именно так и сделал.
@mudasobwa диск просто надежнее всего, люблю когда решение максимально простое, там нет никакой логики и обвязки, три строки кода. Просто снижение вероятностей факапа. Как с сети получили, уже все в надежном месте прикопано (без буферизации) на рейде каком, даже если упадем где-то, все ходы записаны сразу же и никакие буфера в обработчиках или FS данные не потеряли ни байта.
@3draven можно случайно разориться, если хранить всё, что вливается по 10К/сек
@mudasobwa если хранить блоками, то пока клиент делает новый блок (файл) в 10мб, обработчики подъедают старые и стирают за собой. На самом деле если в сливаемом потоке данных структура данных позволяет, блоки даже параллельно обрабатывать можно, предусмотрев краевые случаи сразу полком обработчиков.
@mudasobwa да, кстати, я описал тебе блочный дисковый буфер из нашей системы :) У нас тоже коннект один и если замедлить скачивание, удаленная система его сразу закроет. Там сотни мегабайт данных за секунды...не считал в записях. Потому байтовый поток просто сливается на диск сразу без какой либо обработки и так далее. Параллельность обработки блоков нам не нужна, она реализуется по другому у нас...я в таске описал как, где-то валяется. Мы данные льем быстрее намного чем база их есть может.
@3draven и тут тебе в твой низкоуровневый язык прилетает что-то неожиданное, клиент сегфолтится...... И?
@mudasobwa клиент можно сделать просто трубой, которая пропускает поток байт и не имеет никаких мозгов. Он просто дескриптор будет выбивать в пользование и только. Но это просто направление для раскопок. Вотчдог для таких штук написать не сложно...я как-то писал, оно будет неубиваемое даже если захотеть это сделать :) При этом клиент в 20 строк кода упадет намного менее вероятно чем трехэтажное здание за ним, а значит и коннект всегда жив. Но это так, размышления.
@3draven да, можно, это разумно все, но как по мне — все еще из пушки по воробьям. Там вовлечена сеть и сторонний сервис, так что обрывы будут. Полностью их избежать нельзя, а рестарт за 10 мс я на коленке в воскресенье написал неубиваемый, тут где-то рядом ссылка даже есть.
@3draven заворачиватель потока в кафку не может навернуться?