Разделение уровня согласованности
Что касается разделения уровня согласованности распределенных систем, некоторые статьи делятся наСильная согласованность, последовательная согласованность и слабая согласованность.
Конечная консистенция относится к слабой консистенции, а конечная консистенция делится на:
- причинно-следственная связь,
- последовательность "читай-пишу-пишу",
- Консистенция сеанса,
- Консистенция монотонного чтения,
- Монотонная согласованность записи
Остальные по степени консистенции непосредственно делятся наСильная согласованность, монотонная согласованность, согласованность сеанса, согласованность в конечном счете и слабая согласованность.
Разница между конечной согласованностью и последовательной согласованностью
Разница между окончательной согласованностью и последовательной согласованностью очень велика.
Последовательная согласованность — более сильная модель согласованности, а окончательная согласованность — очень слабая модель согласованности. Можно сказать, что система, удовлетворяющая последовательной непротиворечивости, должна удовлетворять и эвентуальной непротиворечивости, но система, удовлетворяющая эвентуальной непротиворечивости, не обязательно удовлетворяет последовательностной непротиворечивости. Например, Zookeeper обеспечивает последовательную согласованность, Zookeeper также удовлетворяет согласованности в конечном итоге; Cassandra обеспечивает согласованность в конечном счете, но Cassandra не соответствует согласованности в конечном счете.
Анализ уровня согласованности Zookeeper
Сообщение блога«Линеаризуемость — основа управления параллелизмом»Упоминается [в области распределенной, мы скажем, линейной согласованности, например, линейная согласованность Zookeeper, такая как знаменитая теорема CAP, затем распространенная в области C, также относится к линейной согласованности. 】
Автор имеет в виду, что упомянутое в статье [Zookeeper линейно непротиворечиво] служит для иллюстрации того, что линейная непротиворечивость также будет использоваться для описания распределенных систем, поскольку линейная непротиворечивость впервые была предложена в области параллельных вычислений.
На самом деле линейная согласованность одинакова во всех областях. Линейная согласованность впервые была предложена в области параллельных вычислений, а теперь используется в области распределенных вычислений и баз данных, и смысл тот же. Мы можем назвать линейную согласованность сильной согласованностью или атомарной согласованностью. Чтобы быть точным, Zookeeper является линейно непротиворечивым, если есть только запросы на запись, если это последовательная согласованность с точки зрения чтения и записи.
Является ли Zookeeper линейной согласованностью?
Строго говоря [Zookeeper линейно согласован, если есть только запросы на запись; если это последовательная согласованность с точки зрения чтения и записи]
Какой уровень согласованности гарантирует Zookeeper
Как упоминалось выше, Zookeeper линейно непротиворечив, если есть только запросы на запись, если это последовательная согласованность с точки зрения чтения и записи.
Как понять последовательную согласованность Zookeeper, см.nuggets.capable/post/684490…
Монотонный анализ согласованности Zookeeper
В соответствии с протоколом ZAB Zookeeper согласованность, гарантируемая Zookeeper, является монотонной согласованностью (в любое время, когда какой-либо пользователь считывает значение определенных данных после определенного обновления, он не будет читать значения старше этого значения. То есть , порядок полученных данных должен быть монотонно возрастающим.)
причина:
-
Предполагая, что серверов 2n+1, в процессе синхронизации лидер синхронизирует данные с фолловерами.Когда количество фолловеров, завершившихся синхронизацией, больше n+1, процесс синхронизации завершается, и система принимает запрос клиента на подключение . Если клиент подключен к повторителю, который не синхронно завершен, полученные данные не являются последними данными, но монотонность может быть гарантирована.
-
Предполагается, что ведомый получает запрос на запись, а затем пересылает его ведущему для обработки, а ведущий завершает двухэтапный механизм фиксации. Инициировать предложение для всех серверов. Когда предложение будет одобрено более чем половиной (n+1) серверов, весь кластер будет синхронизирован. После синхронизации более чем половины (n+1) серверов запрос на запись будет выполнен. Если клиент подключается к ведомому, который не синхронно завершен, то полученные данные не являются последними данными, но монотонность может быть гарантирована.
Анализируйте Zookeeper с помощью принципа CAP для распределенных систем
(1)С (консистенция):Zookeeper гарантирует последовательную согласованность (соответствует возможной согласованности) и может синхронизироваться с каждым узлом в течение дюжины секунд.
(2)А (наличие):Zookeeper гарантирует доступность, данные всегда доступны без блокировок. И данные, принадлежащие более чем половине узлов, актуальны и доступны в режиме реального времени. Если вы хотите убедиться, что полученные данные должны быть самыми последними, вам нужно вручную вызвать Sync()
(3)P (допуск перегородки):Два момента нужно проанализировать
- Большее количество узлов приведет к увеличению задержки записи данных, поскольку необходимо синхронизировать большее количество узлов.
- Если узлов больше, выбор лидера займет больше времени, что усугубит проблему сети.Эту проблему можно облегчить, введя узлы-наблюдатели (не участвующие в выборах).