последовательное хеширование против хеширования рандеву ( HRW) - каковы компромиссы?

В Сети доступно много информации о последовательном хешировании и реализациях на нескольких языках. Запись Википедии для этой темы ссылается на другой алгоритм с теми же целями:

Рандеву Хеширования

этот алгоритм кажется проще и не требует добавления реплик/виртуалов вокруг кольца для решения проблем с неравномерной загрузкой. Как упоминается в статье, он, похоже, работает в O (n), что было бы проблемой для больших n, но ссылается на документ, в котором говорится, что он может быть структурирован для запуска в O(log n).

мой вопрос для людей с опытом в этой области: почему бы выбрать последовательное хеширование над HRW или наоборот? Есть случаи использования, когда одно из этих решений лучше?

большое спасибо.

14
consistent-hashing load-balancing

2 ответов

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

с HRW если каким-то образом вы в конечном итоге с горячими точками (т. е. вызваны плохими вариантами алгоритма хэширования), вы не можете много сделать с этим, кроме удаления точки доступа и добавления нового, который должен сбалансировать запросы.

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

16

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

1) согласованное хеширование требует постоянной хэш-карты узлов и vnodes (или, по крайней мере,разумный реализации, вы можно построить все объекты по каждому запросу.... но ты действительно не хочешь!). HWR не делает (это состояние-меньше). Ничего не нужно изменять, когда машины присоединяются или покидают кластер - нет параллелизма, о котором нужно беспокоиться (за исключением того, что ваши клиенты имеют хорошее представление о состоянии кластера, которое одинаково в обоих случаях)

2) HRW легче объяснить и понять (и код короче). Например, это полный алгоритм HRW, реализованный в Riverbed Stingray TrafficScript. (Обратите внимание, что есть лучшие хэш-алгоритмы для выбора, чем MD5 - это перебор для этой работы)

$nodes = pool.listActiveNodes("stingray_test");

# Get the key
$key = http.getFormParam("param");

$biggest_hash = "";
$node_selected = "";

foreach ($node in $nodes) {
   $hash_comparator = string.hashMD5($node . '-' . $key);

   # If the combined hash is the biggest we've seen, we have a candidate
   if ( $hash_comparator > $biggest_hash ) {
      $biggest_hash = $hash_comparator;
      $node_selected = $node;
   }
}

connection.setPersistenceNode( $node_selected );
​

3) HRW обеспечивает равномерное распределение, когда вы теряете или получаете узлы (при условии, что вы выбрали разумную хэш-функцию). Последовательное хеширование не гарантирует этого, но с достаточным количеством vnodes это, вероятно, не будет проблемой

4) согласованная маршрутизация может быть быстрее - в нормальной работе это должен быть журнал заказов (N), где N-количество узлов * реплика фактором для vnodes. Однако, если у вас нет много узлов (я этого не делал), то HRW, вероятно, будет достаточно быстро для вас.

4.1) Как вы упомянули Википедия упоминает, что есть способ сделать HWR в log(N) time. Я не знаю как это сделать! Я доволен своим O (N) временем на 5 узлах.....

в конце концов, простота и безгосударственный характер HRW сделали выбор за меня....

8