Я много читал о различных стратегиях, чтобы гарантировать согласованность между узлами в распределенных системах, но у меня есть небольшая проблема, когда мы выясняем, когда использовать какой алгоритм.
С какой системой я бы использовал нечто вроде векторных часов? Какая система идеально подходит для использования чего-то вроде Paxos? Являются ли эти два взаимоисключающих?
Существует распределенная система из двух узлов, которые хранят данные. Данные реплицируются на оба узла, так что если один node умирает, данные не теряются (долговечность) и продолжают обслуживаться (доступность). А также вы надеетесь, что ваша система 2- node будет обрабатывать в два раза больше запросов в секунду (масштабируемость).
Предположим, что запись в один ключ может прийти к любому node. Ваш клиент пишет "1" в качестве значения для некоторого ключа, затем он решает написать "2" . Первая запись идет в node # 1. Он выдает запрос на репликацию на node # 2. Тем не менее, ваш запрос на сохранение "2" приходит к node # 2 (мы можем хранить на любом node, помните) раньше, чем запрос репликации. Он сохраняет "2" , выдает запрос репликации с "2" на node # 1, получает от него запрос на репликацию с "1" , меняет "2" на "1" , а node # 1 меняет свой "1" - "2" . Теперь у вас есть несогласованность в ваших данных между узлами хранения. Кроме того, если node # 1 умирает, все, что у вас есть, это node # 2, которое имеет значение "1" , в то время как вы очень хорошо помните, что вы отправили "2" после "1" , и система хранения подтвердила, что он спас ее. На самом деле, многие вещи могут пойти "не так", в зависимости от того, что вы ожидаете от своей системы хранения (читайте ваши записи? Monotonic reads? И т.д.), Поэтому вам нужен способ действительно узнать, какое истинное, хорошее, фактическое значение для ключа является или даже препятствует системе "развращать" данные таким образом. Для этого система хранения должна знать, что произошло до того, что либо между ее узлами, либо даже может включать в себя ваши клиенты видение порядка событий. Векторные часы и векторы версий - это некоторые из методов используется на практике для достижения этого или требует, чтобы произошло 2 события одновременно, и вам нужен другой способ решить их результаты.
Вы решаете проблему по-другому, чтобы избежать всех этих сложностей: все записи для определенного ключа перейдут к одному node (называемому "лидером" ), и он будет реплицировать эти записи на другой node. Действительно, это выглядит как более простая схема: в течение одного node (и, вероятно, одного процесса) у вас есть быстрые и проверенные методы управления concurrency, легко упорядочивать события, можно применять репликацию в том же порядке; также всегда есть авторитетный источник правильных данных. Единственная проблема заключается в том, что вашим двум узлам хранения необходимо согласиться с тем, что node является лидером для определенного ключа. И если у вас было 3 узла, и один из них умер, другим 2 нужно было бы решить 1), что оба они думают, что старый лидер умер, 2) кто из них является новым лидером. Для этого существуют консенсусные протоколы (Paxos, двухфазный commit, Raft, Zab, 3-фазная фиксация и т.д.).
Почему бы не всегда выбирать единый лидер (и, следовательно, консенсусный протокол) по схеме без лидера (и, следовательно, механизм упорядочения, такой как векторы версий)? Согласование лидерства требует времени (подумайте до нескольких секунд или десятков секунд), в течение которого ваша система недоступна или частично доступна в каком-то специальном режиме. Leaderless также может работать лучше в некоторых других условиях (например, лидер становится медленным из-за проблем с программным обеспечением или сетевых проблем: при использовании без лидера другие узлы могут выполнять свои обязанности). Консенсус становится сложнее по мере увеличения количества участников, поэтому лидеры могут потенциально лучше масштабироваться.
Наконец, позвольте проскользнуть через ваши вопросы буквально:
С какой системой я бы использовал нечто вроде векторных часов?
Возможно, вы захотите использовать вектор версии для автономного распределенного хранилища. Вы можете использовать векторные часы для одного и того же (хотя хуже подходит, в статье также предлагается использовать его для согласованных снимков для реализации причинный порядок в общих распределенных системах и т.д.).
Какая система идеально подходит для использования чего-то вроде Paxos?
Одноранговое или многопользовательское распределенное хранилище. База данных редко обновляемых данных (think configs), информация об участии в кластере - если эта информация имеет решающее значение, в противном случае шкала сплетен лучше. Распределенные блокировки.
Являются ли эти два взаимоисключающих?
Нет. Оба могут использоваться для решения одних и тех же задач (например, распределенного хранилища). Их можно объединить (paxos для участия в кластере, а затем использовать эти знания, чтобы определить, какие узлы образуют кворум в последовательной (через векторы) системы).