не пойман не вор как говорится

Не совсем по js вопрос, но почему 1 <<1024 выдаёт такое большое число

Должно выдавать 2048

Не совсем по js вопрос, но почему 1 <<1024 выдаёт такое большое число

1 ? при 1<<11 - 2048

Должно выдавать 2048

1024 << 1

Должно выдавать 2048

ну это 2 в 1024 получается

1024 << 1

Точно. В коде именно (1<<1024)-1 Так понимаю, что это 1024 битовый ключ инициализируется

все логично, должно быть большое

Точно. В коде именно (1<<1024)-1 Так понимаю, что это 1024 битовый ключ инициализируется

Ага. А это сильно больше 2048

А еще платная: https://alvarotrigo.com/fullPage/pricing/

Я юзал. Была бес

Ага. А это сильно больше 2048

Спасибо)

https://alvarotrigo.com/fullPage/

спасибо, то что надо

ребята кто с редисом на ты?

ребята кто с редисом на ты?

Задавай вопрос сразу.

Задавай вопрос сразу.

при выключении приложения "на горячую" коннект к редису не отваливается. так как нет события закртия подключения. есть какой то способ вычищать на лету список коннектов?

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

я не знаком с редисом, но точно ли проблема в этом?

я просто почитал доку их, в частности последнюю секцию, он должен сам чиститься https://redis.io/topics/clients

ну согласись, глупо, если не так

тут не совсем проблема а скорее задача. надо чтобы при отключении на горячую приложение понимало СОГЛАШУСЬ что глупо ребят. но к сожалению это так потому что я открываю два инстанса одного приложения при открытии нового у меня выводится новое подключени при закрытии пропадает но если я закрою терминал тогда остается

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

я уже проклял этот редис

https://redis.io/commands/client-list

вот клиент листом я и достаю данные

я возможно что-то банальное кидаю)

не пропадает если закрыть терминал

но, проглядев глазами, вижу, что там нет ничего про статус "мертвое соединение"

скорее всего концепции мертвых соединений нет

вопрос тогда в таймайте перед разрывом с закрывшемся клиенте

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

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

\

потом рвет

хм

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

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

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

спасибо

буду гуглить

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

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

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

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

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

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

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

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

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

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

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

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

Эммм

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

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

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

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

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

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

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

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

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

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

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

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

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

я объясню

давай

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

да

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

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

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

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

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

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

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

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

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

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

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

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

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

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