Консистентное хеширование?

Ролг Хупин
Дата: 11.09.2017 11:57:53
Есть описание
https://4gophers.ru/articles/konsistentnoe-heshirovanie/#.WbKd5sgjEuU

В принципе понятно, но что-то торможу:

Я так понимаю, что ключи распределяются по разным нодам согласно каким-то фукнциям, хэшам, ок.

Если упал узел Н, то далее все новые ключи будут попадать на следующий по кругу узел. Хорошо.

Но что будет с ключами, хранившимися на упавшем узле? Накрылись?
А если упадет еще и еще один узел?
Dima T
Дата: 11.09.2017 12:22:39
Ролг Хупин
Но что будет с ключами, хранившимися на упавшем узле? Накрылись?

Накрылись. Если откуда восстановить? От настроек резервного копирования зависит. Эта тема в статье никак не затрагивается.
Статья про распределение обработки, а не про хранение.
kealon(Ruslan)
Дата: 11.09.2017 12:25:40
Ролг Хупин,

данные сохраняются сразу на нескольких нодах, если одна упадёт - в идеале должно сработать перераспределение
Ролг Хупин
Дата: 11.09.2017 13:50:49
Dima T
Ролг Хупин
Но что будет с ключами, хранившимися на упавшем узле? Накрылись?

Накрылись. Если откуда восстановить? От настроек резервного копирования зависит. Эта тема в статье никак не затрагивается.
Статья про распределение обработки, а не про хранение.


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

Но если юзер будт запрашивать ключи с накрывшегося узла, то по алгоритму его запросы будут перенаправляться на следующий по часовой стрелке узел.
Следовательно, если ключи-значения реплицировались, то он должны находиться на том самом следующем узле, куда будет перенаправляться запрос юзера?

Получается, что сам алгоритм репликации-копирования тоже непростой.
Dima T
Дата: 11.09.2017 14:34:34
Ролг Хупин
в том и вопрос, что писатели умалчивают об этом моменте, задорно рассказывая, что новые будут распередляться по новым узлам.

Но если юзер будт запрашивать ключи с накрывшегося узла, то по алгоритму его запросы будут перенаправляться на следующий по часовой стрелке узел.
Следовательно, если ключи-значения реплицировались, то он должны находиться на том самом следующем узле, куда будет перенаправляться запрос юзера?

Получается, что сам алгоритм репликации-копирования тоже непростой.

Там же не пишут куда конкретно запрос перенаправляется. Скорее всего в NoSQL БД какую-нибудь, а там есть встроенные средства репликации.

В принципе если каждая нода будет постоянно реплицировать свое состояние на следующую, куда произойдет переключение в случае отказа, то переключить можно мгновенно, но после надо репликацию перенастроить.
kealon(Ruslan)
Дата: 11.09.2017 16:16:57
Ролг Хупин
Dima T
пропущено...

Накрылись. Если откуда восстановить? От настроек резервного копирования зависит. Эта тема в статье никак не затрагивается.
Статья про распределение обработки, а не про хранение.


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

Но если юзер будт запрашивать ключи с накрывшегося узла, то по алгоритму его запросы будут перенаправляться на следующий по часовой стрелке узел.
Следовательно, если ключи-значения реплицировались, то он должны находиться на том самом следующем узле, куда будет перенаправляться запрос юзера?

Получается, что сам алгоритм репликации-копирования тоже непростой.

само собой. Ели нужно расковырять как, смотришь исходники, надёжнее источника нет
Ролг Хупин
Дата: 11.09.2017 17:01:24
Вот тут еще нашел старую статью с комментариями
https://habrahabr.ru/post/42972/

Тот же вопрос, пишут
автор
Нет, тут есть один существенный момент. Ну пусть было 100 ключей, по 25 на каждом, пусть хэш каждого ключа соответствует его номеру. Функция распределения ключей: ключ % 4 + 1.

Тогда ключи 0, 4, 8,… лежат на 1-м сервере, 1, 5, 9,… — на 2-м, 2, 6, 10,… — на 3-м и 3, 7, 11,… — на 4-м.

Пусть 4-й сервер выходит из строя, теперь функция распределения ключей: ключ % 3 + 1.

И теперь ключи 3, 7, 11,… — их значения потеряны (т. к. лежали на упавшем сервере), это 25%.

Далее, берем ключ 6 — он лежал на 3-м сервере, теперь он лежит на 1-м, берем ключ 5 — раньше на 1-м, теперь на на 3-м сервере. Ну и т. д. Сколько ключей сохранили своё расположение?
...

Примечание: изменили расположение — изменили расположения с точки зрения клиента, то есть он за ним обратится на другой сервер, где такого ключа нет, сервера об этой перетасовке ничего не знают, поэтому для клиента переместившийся ключ == потеряный ключ.
kealon(Ruslan)
Дата: 11.09.2017 17:35:33
Ролг Хупин,

в этой логике одно неправильно, зачем им стучаться на все сервера? есть мастер же - он и распределяет запросы по рабочим лошадкам
Dima T
Дата: 11.09.2017 17:48:15
kealon(Ruslan)
в этой логике одно неправильно, зачем им стучаться на все сервера?

+1

Клиент понятия не имеет как оно там внутри размазано, обращается в центральную точку входа, а дальше его перенаправляют в нужное место.
Ролг Хупин
Дата: 11.09.2017 17:58:21
Dima T
kealon(Ruslan)
в этой логике одно неправильно, зачем им стучаться на все сервера?

+1

Клиент понятия не имеет как оно там внутри размазано, обращается в центральную точку входа, а дальше его перенаправляют в нужное место.


Так по этим описаниям получается, что центральной точки входа нет, т.е. нет какого-то центрального сервера, а есть множество равноправных серверов, организованных в виде кольца.
Собственно, в качестве одного из примеров использования консистентного хеша приводятся peer-to-peer сети.
Вот это и вызывает какие-то непонятки у меня.