Основы дизайна систем: выборы лидера
Вернемся к серверам снова для более сложной темы. Мы уже понимаем принцип доступности и то, как избыточность является одним из способов повышения доступности. Мы также рассмотрели некоторые практические соображения при обработке маршрутизации запросов к кластерам избыточных серверов.
Но иногда при такой настройке, когда несколько серверов делают примерно одно и то же, могут возникнуть ситуации, когда вам нужен только один сервер, чтобы взять на себя инициативу.
Например, вы хотите убедиться, что только один сервер отвечает за обновление некоторого стороннего API, потому что несколько обновлений с разных серверов могут вызвать проблемы или увеличить расходы стороннего производителя.
В этом случае вам нужно выбрать тот первичный сервер, которому вы хотите передать ответственность за это обновление. Этот процесс называется выборами лидера.
Когда несколько серверов находятся в кластере для обеспечения избыточности, они могут быть сконфигурированы между собой так, чтобы иметь одного и только одного лидера. Они также обнаружат отказ этого ведущего сервера и назначат другой на его место.
Принцип очень прост, но дьявол кроется в деталях. Действительно сложная часть - обеспечить "синхронизацию" серверов с точки зрения их данных, состояния и операций.
Всегда существует риск, что определенные простои могут привести, например, к отключению одного или двух серверов от других. В этом случае инженеры в конечном итоге используют некоторые из основных идей, которые используются в блокчейне, для получения согласованных значений для кластера серверов.
Другими словами, используется алгоритм консенсуса, чтобы дать всем серверам «согласованное» значение, на которое все они могут полагаться в своей логике при определении того, какой сервер является лидером.
Выбор лидера обычно реализуется с помощью программного обеспечения, такого как etcd, которое представляет собой хранилище пар «ключ-значение», которое предлагает как высокую доступность, так и высокую согласованность (что является ценным и необычным сочетанием) за счет использования самого выбора лидера и использования алгоритма консенсуса.
Таким образом, инженеры могут полагаться на собственную архитектуру выбора лидера etcd для проведения выборов лидера в своих системах. Для этого в сервисе, таком как etcd, сохраняется пара "ключ-значение", представляющая текущего лидера.
Поскольку etcd является высокодоступным и строго согласованным, ваша система всегда может полагаться на эту пару «ключ-значение», которая содержит последний «источник истины». Сервер в вашем кластере - текущий избранный лидер.
Читайте также:
- Основы дизайна систем: балансировка нагрузки
- Основы дизайна систем: последовательное хеширование
- Основы дизайна систем: базы данных
Комментарии
Отправить комментарий