System Design World

🔘 Consistent Hashing

Интервьюер: "Зачем?"
Кандидат: "Позволяет меньше перераспределять данные. И точка."
Интервьюер: "Садитесь, зачёт"

» Пример »

🕺 user_id
У нас их 99. В один инстанц БД влезает 33 🤷
Нам нужно сформировать запрос с user_id = 5. Получить информацию об этом пользователе. На какой сервер идти?
Делаем 3 сервера(горизонтальное масштабирование впритык). Записываем на листочке какой сервер какой диапазон значений обслуживает:
Сервер 1: 1 -> 33
Сервер 2: 34 -> 66
Сервер 3: 67 -> 99
Теперь когда придёт запрос с user_id посмотрю на листок и пошлю на Сервер 1.

😮Оказалось, что я - промежуточная программа.
Которая перенаправляет запросы на целевые сервера😊
В соответствие с этой табличкой, которую мне дал программист.

Что далее?
🥴 Всевозможные проблемы с выходом из строя или добавлением серверов.
С различным распределением ключей. И что consistent hashing - это ещё и представление таблички в форме круга. Где каждый сервер обслуживает значения начиная от него и далее против часовой стрелки пока не упрёмся в точку с другим сервером.

В этом смысле:
Сам сервер 1 имеет свою точку - 33. И обслуживает значения от 1 до 33
Сервер 2 - точка 66. Обслуживает от 34 до 66.
Сервер 3 - точка 99. Обслуживает от 67 до 99.
+Есть переход с 99 -> 1.

🪄 Теперь фокус.
Когда сервер 2 выходит из строя я - чудо перенаправляющая программа - вычеркиваю его из этого круга. И понимаю, что конфигурация стала:

Сервер 1: 1 -> 33
Сервер 3: 34 -> 99

💪 Сервер 3 взял на обслуживание ещё и запросы со значениями, которые обслуживал сервер 2.

А где-то под капотом ещё одна чудо программа. Которая перелила данные(с бэкапа, к примеру) с сервера 2 на сервер 3 :)

🥳 Всё просто!
В чём нюанс? 😏

Please open Telegram to view this post

VIEW IN TELEGRAM

www.tg-me.com/us/System Design World/com.system_design_world/297

1.3K viewsВладимир в IT, Jul 4 at 13:07

🔘 Consistent Hashing

Интервьюер: "Зачем?"
Кандидат: "Позволяет меньше перераспределять данные. И точка."
Интервьюер: "Садитесь, зачёт"

» Пример »

🕺 user_id
У нас их 99. В один инстанц БД влезает 33 🤷
Нам нужно сформировать запрос с user_id = 5. Получить информацию об этом пользователе. На какой сервер идти?
Делаем 3 сервера(горизонтальное масштабирование впритык). Записываем на листочке какой сервер какой диапазон значений обслуживает:
Сервер 1: 1 -> 33
Сервер 2: 34 -> 66
Сервер 3: 67 -> 99
Теперь когда придёт запрос с user_id посмотрю на листок и пошлю на Сервер 1.

😮Оказалось, что я - промежуточная программа.
Которая перенаправляет запросы на целевые сервера😊
В соответствие с этой табличкой, которую мне дал программист.

Что далее?
🥴 Всевозможные проблемы с выходом из строя или добавлением серверов.
С различным распределением ключей. И что consistent hashing - это ещё и представление таблички в форме круга. Где каждый сервер обслуживает значения начиная от него и далее против часовой стрелки пока не упрёмся в точку с другим сервером.

В этом смысле:
Сам сервер 1 имеет свою точку - 33. И обслуживает значения от 1 до 33
Сервер 2 - точка 66. Обслуживает от 34 до 66.
Сервер 3 - точка 99. Обслуживает от 67 до 99.
+Есть переход с 99 -> 1.

🪄 Теперь фокус.
Когда сервер 2 выходит из строя я - чудо перенаправляющая программа - вычеркиваю его из этого круга. И понимаю, что конфигурация стала:

Сервер 1: 1 -> 33
Сервер 3: 34 -> 99

💪 Сервер 3 взял на обслуживание ещё и запросы со значениями, которые обслуживал сервер 2.

А где-то под капотом ещё одна чудо программа. Которая перелила данные(с бэкапа, к примеру) с сервера 2 на сервер 3 :)

🥳 Всё просто!
В чём нюанс? 😏