В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

pro.elixir

1070 membersпожаловаться на группу
2020 August 29

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
В идеале должен быть сервис, который держит дуплекс tcp соединение с нодой и получает от неё диффы по статусам KV. В случае разрыва коннекта все ключи, переданные через это соединение идёт в мусорку.

В случае, если другое соединение пытается совершить операции с ключом, «забитым» другим соединением - в самом простом случае - TCP коннект просто рвёт сам сервис, а потом применяет все правила.


Соответственно в BEAM один генсервер может все это дело трекать. Если нода крешнется - все ее ключи исчезнут. Если сервис порвёт соединение - то сам генсервер у себя удаляет все процессы, переконнекчивается и начинает все заново
Да, и это называется Horde.Registry
источник
20:42пожаловаться#1

ŹR

Źmićer Rubinštejn in pro.elixir
Lama Lover
Да, и это называется Horde.Registry
Только horde registry умрет, когда ляжет нода
источник
20:42пожаловаться#2

ŹR

Źmićer Rubinštejn in pro.elixir
Например сегфолт в нифке развалит всю систему
источник
20:43пожаловаться#3

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
Только horde registry умрет, когда ляжет нода
Ну да, это нормально, что источник данных может умирать
источник
20:43пожаловаться#4

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
В идеале должен быть сервис, который держит дуплекс tcp соединение с нодой и получает от неё диффы по статусам KV. В случае разрыва коннекта все ключи, переданные через это соединение идёт в мусорку.

В случае, если другое соединение пытается совершить операции с ключом, «забитым» другим соединением - в самом простом случае - TCP коннект просто рвёт сам сервис, а потом применяет все правила.


Соответственно в BEAM один генсервер может все это дело трекать. Если нода крешнется - все ее ключи исчезнут. Если сервис порвёт соединение - то сам генсервер у себя удаляет все процессы, переконнекчивается и начинает все заново
Ты описал Eventually Consistent систему на каких-то delta_crdt, как я понял
источник
20:44пожаловаться#5

ŹR

Źmićer Rubinštejn in pro.elixir
Хз. Вроде как eventually consistent допускает два процесса. Такая система как я описал - не допускает
источник
20:46пожаловаться#6

ŹR

Źmićer Rubinštejn in pro.elixir
Или допускает
источник
20:46пожаловаться#7

ŹR

Źmićer Rubinštejn in pro.elixir
Хз. Чет не соображу
источник
20:46пожаловаться#8

B

Bogdan in pro.elixir
Źmićer Rubinštejn
В идеале должен быть сервис, который держит дуплекс tcp соединение с нодой и получает от неё диффы по статусам KV. В случае разрыва коннекта все ключи, переданные через это соединение идёт в мусорку.

В случае, если другое соединение пытается совершить операции с ключом, «забитым» другим соединением - в самом простом случае - TCP коннект просто рвёт сам сервис, а потом применяет все правила.


Соответственно в BEAM один генсервер может все это дело трекать. Если нода крешнется - все ее ключи исчезнут. Если сервис порвёт соединение - то сам генсервер у себя удаляет все процессы, переконнекчивается и начинает все заново
Опять отказоустойчивость теряется из за сервиса который контролирует все соединения, ибо этот сервис может быть раскатан только на одной ноде.
источник
20:47пожаловаться#9

ŹR

Źmićer Rubinštejn in pro.elixir
По другому никак
источник
20:47пожаловаться#10

B

Bogdan in pro.elixir
который принимает соединения
источник
20:47пожаловаться#11

B

Bogdan in pro.elixir
базу данных можно на 3-4 нодах поднять.
источник
20:48пожаловаться#12

ŹR

Źmićer Rubinštejn in pro.elixir
CAP теорема и вот это все
источник
20:48пожаловаться#13

ŹR

Źmićer Rubinštejn in pro.elixir
Описанная система - CP, соответственно не A
источник
20:49пожаловаться#14

LL

Lama Lover in pro.elixir
Нет, есть конечно очень ахуенный способ сделать всё что вы хотите без выбора лидера или базы
При инициализации системы берёте и каждой ноде задаёте id и количество соседей
Потом когда в систему приходит username, вы определяете на какой ноде его запустить путём id = hash(username) % cluster_size
источник
20:51пожаловаться#15

ŹR

Źmićer Rubinštejn in pro.elixir
И если нода падает, тогда...
источник
20:52пожаловаться#16

ŹR

Źmićer Rubinštejn in pro.elixir
Все пользователи с неё идут гулять
источник
20:52пожаловаться#17

LL

Lama Lover in pro.elixir
Źmićer Rubinštejn
И если нода падает, тогда...
Тогда нода рестартится
источник
20:53пожаловаться#18

LL

Lama Lover in pro.elixir
<%= erlang_logo %>
источник
20:53пожаловаться#19

B

Bogdan in pro.elixir
Без постоянного пинга ноды с каким-то единным центром не получится решить эту проблему. Это либо TCP либо БД.
источник
21:01пожаловаться#20