тут появляется следующий вопрос. как пинговать

по умолчанию он ждет 300 секунд

\

потом рвет

хм

как то можно его сократить мб?

да думаю можно безусловно

отлично кажется это то что надо!

спасибо

буду гуглить

рад, если поможет)

есть две опции TCP keepalive для сетевого взаимодействия и SOCKET keepalive для взаимодействия через unix-сокет. полагаю, нужно первое

Приветствую. Как правильно заставить работать href с своим http server?

и это пипец как напрягает

да пусть висят. если прям напрягают, снизь idle timeout в редисе для клиентов

он будет убивать неактивные

ну а ваще, тебе сокетов что-ли жалко? :))

idle timeout - это время простоя?

Да, была настройка, точно помню, кури доку :)

да дело в том что у меня задача такая) надо чтобы при отключении ноды, другая нода взяла на себя задачу рассылки

не хочу в подробности но как то так

да дело в том что у меня задача такая) надо чтобы при отключении ноды, другая нода взяла на себя задачу рассылки

Эммм

довольно интересная задача)

вы че в теме задачи?

Ну я делал N воркеров, и они по кругу из очереди брали команды

и я не первый такой?

я нет) я никогда не пользовался им)

просто принцип понимаю

Работало как часы. Нода сдохла -- перестала брать таски из очереди, и всё

звучит логично

да дело в том что у меня задача такая) надо чтобы при отключении ноды, другая нода взяла на себя задачу рассылки

просто при таком раскладе это звучит так, словно вторая нода должна знать о состоянии первой. Это выглядит сомнительно сложно

Ну я делал N воркеров, и они по кругу из очереди брали команды

ну в общем да смысл такой что есть нода и я могу запустить кучу ее инстансов но при этом одна должна быть дережором. и при условии что одна упала и именно упала а не завершилась с событием функцию дережора другая (рандомная) должна перехватить я не думаю что я нашел какое то супер крутое решение мозг уже немного кипит поэтому хочу просто отслеживать коннекты и если "мастер нода" отвалилась назначать мастером следующую по списку

если позволишь критику, мне кажется, что это немного неправильно

я объясню

давай

в этой схеме есть редис и несколько нод приложения, так?

да

Оркестрация сервисов вообще задача не особо тривиальная :)

если ввести определение "мастер-ноды" приложения, то логически из этого следует, что побочные ноды должны каким-то образом получать сигнал о ее падении (на это нужен алгоритм) во-вторых, какая-то из следующих должна взять на себя задачу (вопрос "какая?" - это еще один алгоритм)

Всегда будет единая точка отказа (в моей системе это был балансировочный гейт)

Ну либо несколько гейтов запускать на разных портах, тогда надежность повышается.

проще всего, если при отношении 1:N (1 редис - N клиентов) будут работать одинаково все N нод-приложения, как описал Николай

таким образом исключается иерахрия

и система работает вне зависимости от падения одного узла

N-1 нод остаются в работе

так ну в принципе я пока не нахожу противоречий с моим решением

объясни лучше сразу где я делаю дичь

если так, то замечательно

где - я не знаю) я чисто абстрактно описал свое видение

как если бы это был любой клиент-серверный стек

но технически я понимаю, что нужен балансировщик

автоматически определяющий, в какой нод пушить

из доступных

ладно вы уже загялдываете дальше моей компетенции я не такой прошаренный еще

автоматически определяющий, в какой нод пушить

Не нужен.

Нода сама берет себе таски из очереди.

А пушатся они в очередь в редисе кем угодно и когда угодно.

то есть там что-то вроде шины?

ааа

я понял

Получается максимально развязанная система.

все, спасибо, буду знать

Так редис и есть шина по сути :)

да блин!

ERROR: S client not available

в общем, советую погуглить по архитектуре этой такое явно делается часто, и решение должно быть простое

возможно вот это наведет на мысли

https://github.com/smrchy/rsmq

блин, ребят спасибо вам. реально столько годых советов, реально неожидал

вот так я себе представляю

то есть шина, из которой берут, сколько смогут проглотить, ноды

на картинке показано (как я это понимаю), что nodeA вполне себе справляется сама с очередью и берет из нее со смертью nodeA в дело включается nodeB на деле же я думаю, что все будет работать еще эффективнее, к примеру nodeA, nodeB будут поочередно брать из очереди (пока первая взяла и отправляет, вторая берет следующее)

но требуемое условие отказоустойчивости сохраняется в обоих случаях

блин, ребят спасибо вам. реально столько годых советов, реально неожидал

я сюда редко захожу, но тут часто задают интересные вопросы

я рад что я не подкачал) на самом деле мне тоже понравилась эта задача.

она мне не показалась простой. но она офигенная

:) я думаю, все будет работать как часы сам люблю серверные технологии, хотя ушел из них на пару лет во фронтенд

а еще приятно видеть вдохновленного человека

блин, ребят спасибо вам. реально столько годых советов, реально неожидал

Почитай еще, как сделать блокирующую очередь с нодой и редисом.

https://redis.io/commands/brpoplpush

Почитай еще, как сделать блокирующую очередь с нодой и редисом.

Редис вообще я так понял очень мощная штука) я знал конечно что это не только key value

Я вот эту команду юзал, чтобы атомарно перекладывать таски из списка pending в список processing

Ты же, надеюсь, ioredis юзаешь в качестве клиента?

блин похожу нет( вот это https://github.com/noderedis/node_redis

мне надо срочно перекатиться на ioredis?

блин похожу нет( вот это https://github.com/noderedis/node_redis

Меняй. Там то же самое, только с промисами.

а ну так я промисифицирую

Да. Коллбеки для мазохистов.

и пишу ак удобнее

Ну а смысл, если есть уже либа

ну да согласен выглядит как говно, и колбеки и куча promisify

спасибо за совет

Ох бляяяя, открыл код воркера трёхлетней давности

Ох сука