Может ли Sloppy Quorum гарантировать высокую согласованность чтения?
В книге «Проектирование приложений с интенсивным использованием данных. Большие идеи, лежащие в основе надежных, масштабируемых и поддерживаемых систем» мы можем прочитать о Sloppy Quorum:
Однако это означает, что даже если w + r > n, вы не можете быть уверены, что прочтете последнее значение ключа, поскольку последнее значение могло быть временно записано в некоторые узлы за пределами n.
Но я не могу понять смысл этого.
Давайте рассмотрим пример клиентов, записывающих разные значения для ключа «K1».
Предположим, у нас есть:
- Количество реплик: N=3
- Количество подтверждений, прежде чем запись считается успешной: W=2.
- Количество ответов, прежде чем чтение будет считаться успешным: R=2.
- Доступные узлы: A, B, C, D и E.
У нас есть W+R>N.
Предположим, у нас уже есть первое значение для «K1» в A, B и C: (K1,V1)
Затем предположим, что узлы A и B выходят из строя, тогда клиент записывает (K1,V2) в конфигурацию Sloppy Quorum.
Насколько я понимаю, мы будем использовать узлы C, D и E для записи и репликации (K1, V2), чтобы избежать блокировки операции записи, как в конфигурации строгого кворума, и нам нужно подтверждение двух из этих узлов. Допустим, мы получили подтверждения от C и D, значит, запись прошла успешно.
Теперь другой клиент хочет прочитать значение K1, ему нужно два ответа, и у нас есть три возможности:
- C и D отвечают первыми: мы обязательно получим (K1, V2), потому что это узлы, подтвердившие запись (K1, V2).
- C и E отвечают первыми: мы можем получить либо два (K1, V2), либо один (K1, V2) от C и один (K1, V1) от E, если репликация на E еще не завершилась. В последнем случае все еще возможно разрешить конфликт, используя алгоритмы управления версиями, такие как Vector Clock. Таким образом, пока наша система способна разрешать конфликты, мы обязательно получим (K1, V2) (кроме того, такой конфликт также может произойти в конфигурации Strict Quorum, поэтому в нашем случае это не связано с конфигурацией Sloppy Quorum)
- D и E отвечают первыми: то же, что и выше (т. е. случай C и E)
Исходя из этого, я бы сказал, что наша система Sloppy Quorum может гарантировать строгую согласованность чтения (при условии, что она обрабатывает конфликты, что, опять же, также следует обрабатывать в конфигурациях Strict Quorum), поскольку возвращаемое значение будет (K1,V2) , что, похоже, не объясняется в книге.
Есть ли что-то неправильное в этом рассуждении?
Спасибо за совет, я видел много подобных вопросов в SO, так что думаю, все будет в порядке. Я просто оставлю все как есть для людей, которые ищут здесь ответ.
Ответы 2
После некоторых исследований и анализа, думаю, мне удалось понять, что имел в виду автор.
Аргументация вопроса правильная, но неполная:
Предположим, что после того, как второй клиент получит значение (K1,V2), узлы A и B восстановлены.
Обычно, поскольку мы находимся в конфигурации неряшливого кворума, происходит фаза подсказки передачи обслуживания, когда узлы D и E отправляют последние данные обратно в A и B, когда они восстанавливаются. В книге мы можем прочитать:
Как только прерывание сети устранено, Any пишет, что один узел временно принятые от имени другого узла, отправляются на соответствующие «домашние» узлы. Это называется намеком на передачу обслуживания.
Проблема с нашей конфигурацией Sloppy Quorum заключается в том, что если другой клиент хочет прочитать значение K1 сразу после восстановления узлов A и B, но до начала Hinted Handoff, возможно, что этот клиент получит два ответа от A и B с старое значение (K1,V1), и клиент примет это значение, поскольку R=2. Таким образом, в этом случае клиент не получит самое последнее значение, как описано в книге.
Клиенты могут безопасно получить последнее значение (K1, V2) только после завершения Hinted Handoff, как объяснил автор:
Таким образом, неряшливый кворум на самом деле вообще не является кворумом в традиционный смысл. Это всего лишь гарантия долговечности, а именно то, что данные хранятся где-то на w узлах. Нет никакой гарантии, что чтение из r узлов будет видеть его до тех пор, пока не завершится указанная передача обслуживания.
Итак, ответ на вопрос «Может ли Sloppy Quorum гарантировать высокую согласованность чтения?» будет: Нет.
Sloppy Quorum не определен явно в разделе «Проектирование приложений с интенсивным использованием данных», но подсказку вы найдете в этом предложении:
Запись и чтение по-прежнему требуют успешных ответов w и r, но они могут включать узлы, которые не входят в число назначенных n домашних узлов для значения [p. 183, выделено нами]
Иллюстрация, строка 1
По сути, пространство ключей разделено, то есть ключи реплицируются не на все узлы, а на подмножество узлов.
Иллюстрация, ряд 2
Если некоторые узлы кворума для ключа недоступны, значение ключа будет записано в другие узлы с подсказкой передачи обслуживания.
Иллюстрация, строка 3
Когда узлы станут доступны, условие корректности w + r > n будет (временно) нарушено.
Иллюстрация, строка 4
Со временем значение ключа будет обновлено.
Редактировать
Я только что понял, что пропустил ваш ответ, когда писал и отправлял свой. Приносим извинения за дублирование.
Спасибо, с иллюстрацией стало намного понятнее! Однако, насколько я понимаю, «w + r > n» никогда не будет нарушено, и это не обязательно противоречит первому предложению, которое вы упомянули: «они могут включать узлы, которые не входят в число назначенных n домашних узлов». В строке 2 мы видим, что узлы D и E, не входящие в число n домашних узлов (т. е. A, B, C), обрабатывают запрос на запись. И у меня в строке 3 "w+r > n" не нарушено, у нас всё равно N=3, разница со строкой 2 только в том, что каждый запрос на чтение или запись теперь будет снова перенаправляться на A, B и C, а не D и E больше.
Поскольку это концептуальный вопрос, а не вопрос о каком-то конкретном отображаемом коде, который необходимо исправить, к сожалению, это, вероятно, неправильный стек для вопросов такого типа. Если вам повезет, мод переместит его, если вам не повезло, то нет, и вопрос получит отрицательные голоса и нанесет вред вашему аккаунту :(