Из этого блога ,
С традиционным «хэшированием по модулю» вы просто рассматриваете хэш запроса как очень большое число. Если вы возьмете это число по модулю количества доступных серверов, вы получите индекс используемого сервера. Это просто и работает хорошо, пока список серверов стабилен. Но когда серверы добавляются или удаляются, возникает проблема: большинство запросов будут хэшироваться на другой сервер, чем они делали раньше. Если у вас девять серверов и вы добавляете десятый, только одна десятая часть запросов (к счастью) будет хэшироваться на тот же сервер, что и раньше. Последовательное хеширование может обеспечить равномерное распределение.
Тогда есть последовательное хеширование. Согласованное хеширование использует более сложную схему, где каждому серверу назначается несколько значений хеш-функции на основе его имени или идентификатора, и каждый запрос назначается серверу с «ближайшим» значением хеш-функции. Преимущество этой дополнительной сложности заключается в том, что при добавлении или удалении сервера большинство запросов будут сопоставляться с тем же сервером, что и раньше. Таким образом, если у вас есть девять серверов и добавлена десятая, около 1/10 запросов будут иметь хэши, которые находятся рядом с хэшем вновь добавленного сервера, а остальные 9/10 будут иметь тот же ближайший сервер, что и раньше. Намного лучше! Столь последовательное хеширование позволяет нам добавлять и удалять серверы, не нарушая полностью набор кэшированных элементов, который хранится на каждом сервере.
Аналогично, алгоритм циклического перебора применяется к сценарию, в котором список серверов стабилен. и LB трафик наугад. Согласованное хеширование используется для сценария, в котором внутренние серверы должны масштабироваться или масштабироваться, и большинство запросов будут сопоставляться с тем же сервером, что и раньше. Последовательное хеширование может обеспечить равномерное распределение.
Надеюсь, это имеет смысл.