Некоторые последующие вопросы о постоянном хешировании

Question

Я прочитал несколько статей, объясняющих теорию последовательного хеширования. Но большинство из них не дает подробностей о том, как обрабатывать добавление/удаление узла. Я понимаю, что если он используется в кэше, таком как memcached, нам может не понадобиться ничего, но если он используется в распределенном хранилище, очень важно переместить некоторые данные для исправления узла. Что именно произошло, когда нам нужно добавить/удалить узел?

Несколько другие вопросы:

1. что лучший способ справиться с серверами различных размеров
2. как добавлять и удалять более одной машины в то время
3. как справиться с репликацией и отказоустойчивость

Надеюсь, что кто-то может указать мне на статью, которая объясняет это.

Answer 1

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

Вы знаете, что Dynamo: Amazon’s Highly Available Key-value Store? Это описано более подробно в разделе 4.

что лучший способ справиться с серверами различных размеров

Там ничего не мешает вам положить различные объемы данных на разных серверах в Dynamo- как или Кассандра-подобная система. Это добавит значительную сложность, особенно в случаях восстановления отказа, но никак не нарушит основы проткола.

Answer 2

К вашему первоначальному вопросу вам просто нужен другой способ совершить раздачу объекта с одного узла на другой. Вероятно, это скорее фактор того, как вы добавляете и удаляете узлы, чем работает согласованное хеширование.

Одним из гипотетических способов приблизиться к этому является рассмотрение промежуточного состояния при перебалансировке, когда у вас есть два последовательных хэша, один для старой топологии и один для новой топологии. Возьмите разницу между ними, и каждый сервер должен быть в состоянии сказать, что ему нужно сделать, чтобы соответствовать новой топологии. Например, каждый сервер запрашивает объекты, которых у него нет, с старых серверов, используя старый согласованный хеш. Как только мы достигли какого-то «сделанного» состояния, мы можем отбросить старые копии (при необходимости).

1. Последовательное хеширование позволяет вам придавать вес серверам, регулируя количество реплик. Это, вероятно, лучшее преимущество последовательного хэширования над HRW.

2. Возможно, это то же самое, что просто добавление одной машины.

3. HRW имеет полезную идею, что согласованное хеширование не имеет, как обычно описано, как получение последующих узлов. То есть вместо того, чтобы давать вам только «узел» для объекта, он может дать вам «упорядоченный список узлов для объекта». Если вы решите, что хотите, скажем, 3 реплики для каждого объекта, вы берете верхнюю тройку из списка, а не только первую.

Вы можете получить тот же эффект последовательного хеширования, хотя это менее интуитивно: просто продолжать идти по «кругу», пока вы не N уникальных узлов.