Я столкнулся с концепцией "Сильная конечная последовательность". Предполагается ли он быть более сильным, чем "Возможная последовательность", но слабее, чем "Сильная согласованность"? Может ли кто-нибудь объяснить различия между этими тремя понятиями с применимыми примерами?
http://en.wikipedia.org/wiki/Eventual_consistency#Strong_Eventual_Consistency http://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
Большое спасибо.
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: В приведенном ниже тексте вы должны дать общее представление о различиях между возможной последовательностью, сильной конечной последовательностью и сильной последовательностью. Но они в некотором роде чрезмерное упрощение. Так что возьмите их с солью;)
Прежде всего: когда мы говорим о согласованности, мы ссылаемся на сценарий, когда разные сущности (узлы) имеют свою собственную копию некоторого объекта данных. Теперь возникают конфликты, потому что каждый node может обновить свою собственную копию (например, потому что есть клиенты, каждый из которых подключен к некоторым node, прося их сделать это), поэтому, если я прочитаю данные с разных узлов, я увижу разные значения. Именно здесь вступают в игру Eventual Consistency (EC), Strong Eventual Consistency (SEC) и Strong Consistency (SC).
Конечная согласованность Конфликты могут возникать, но узлы обмениваются друг с другом своими изменениями для разрешения этих конфликтов, поэтому со временем они согласны с окончательной ценностью. Таким образом, если к данным в течение определенного периода не будет применено больше изменений, то все узлы согласятся в значении данных (то есть в конечном итоге они согласятся), поэтому читатели данных в конечном итоге будут видеть одно и то же значение.
Пример: два узла A и B (nA и nB) имеют каждую копию строки, которая обновляется операциями read() и write(string). Скажем, у каждого есть свой клиент (cliA и cliB). Скажем, что изначально оба узла сохраняют одно и то же значение "Joe", но в какой-то момент nA обновляет его до "Frank" (вызывает write("Frank")). Тогда nA сообщит nB, что значение было обновлено; поскольку оба значения различаются, конфликт возник, но он может быть разрешен с использованием некоторой политики (например, last-write-wins), поэтому nB, наконец, обновляет свою запись также до "Фрэнка". Прежде чем конфликт будет разрешен, cliA и cliB будут видеть разные версии данных (результат read() op будет отличаться), но в итоге оба снова будут видеть одно и то же значение.
Имейте в виду, что если оба узла одновременно обновляют свое значение, разрешение конфликтов все же возможно, но более сложно. Здесь SEC сияет.
Сильная конечная последовательность Это частный случай EC, который действителен только для определенных типов данных.
Предположим, что общий объект данных является счетчиком, а обновления выполняются с помощью операций add(int value) и substract(int value). В этом случае порядок, в котором мы применяем обновления, не имеет значения! Поэтому, если оба nA и nB начинаются со значения счетчика 0, и если тогда nA запускает add(10), а nB запускает substract(5) (одновременно), им нужно только отправлять операцию обновления друг другу, не заботясь о разрешении конфликтов, в конечном итоге что они достигнут того же значения (помните, что в отличие от предыдущего примера для EC может потребоваться некоторое разрешение конфликта)!
К сожалению, SEC применим только к определенным типам данных и операциям, которые обладают определенными свойствами (коммутативность и другие). Такие типы данных обозначаются как Тип реплицируемых конфликтов (CRDT).
Сильная консистенция
Совсем не отличается от двух других. Здесь необходимо, чтобы при выполнении операций обновления все узлы согласовывали новое значение, прежде чем сделать новое значение видимым для клиентов. Таким образом, обновления видны всем клиентам одновременно ", поэтому они будут читать одинаковое значение в любое время. Теперь это вводит требование для некоторой блокировки в операциях обновления. Как в EC, так и SEC операция обновления завершилась, как только локальная копия была обновлена (тогда операция транслировалась на другие узлы). Здесь обновление клиента не возвращается, пока все узлы не согласовали значение данных, и, хотя это делается, все обращения к любой копии этих данных" заблокированы" (так что другие клиенты читают блокировку). В нашем примере для EC, если cliA работает write("Frank"), cliA будет заблокирован до тех пор, пока обновление не будет согласовано как nA, так и nB, а затем оно станет видимым одновременно для cliA и cliB, то есть операция read() должен возвращать то же значение с тех пор.