Какая модель согласованности у меня есть?

Question

Я реализовал реплицированное хранилище ключей / значений поверх Redis. У меня есть пассивная репликация, в которой все запросы на запись и чтение перенаправляются лидеру, который всегда возвращает последнее значение, записанное для ключа. Система использует кворум. Так что это работает, даже если есть узлы, которые не работают или с сетевым разделом. В этом случае значения в этих узлах не согласованы. Но это не мешает системе возвращать последнее наиболее обновленное значение. Есть ли у меня модель возможной согласованности или строгая? Спасибо

Answer 1

Вы упомянули, что это система, основанная на кворуме, с одним узлом в качестве лидера. Запросы на чтение и запись всегда направляются лидеру.

Для простоты предположим, что в системе 5 узлов, и один из них является лидером. Другие 4 узла являются вторичными.

Обычно системы, основанные на кворуме, работают по согласованным протоколам. Таким образом, из 5 узлов, если 3 узла имеют самое последнее значение, достаточно всегда возвращать последнее значение.

Вот как должны работать записи

1. Лидер сначала обновляет ключ / значение в своей базе данных
2. Пересылает запрос оставшимся 4 узлам, которые являются вторичными
3. Лидер ожидает, по крайней мере, 2 из вторичных узлов, чтобы подтвердить, что, они обновили последний ключ / значение в своей базе данных. Это означает, что из 5 узлов по крайней мере 3 узла имеют последнее обновленное значение.
4. Если лидер не получает ответ по крайней мере от 2 вторичных узлов в течение указанного периода времени (время ожидания запроса истекло), тогда Лидер возвращает ошибку клиенту, и клиент должен повторить попытку.

Таким образом, запросы на запись выполняются только в том случае, если 3 из 5 узлов имеют последнее значение. В любой момент 2 из узлов могут иметь или не иметь последнее значение и могут догнать их позже.

Для операций чтения лидер (имеющий последний ключ / значение) всегда возвращает ответ.

Что происходит, когда машина-лидер не может обслуживать запросы из-за какой-то проблемы? (Например, ошибка сети)

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

Ваша система строго согласована.