Подписка на RSS

Распределенная согласованность — Часть 2 — Некоторые формы конечной согласованности

Еще в этой серии:

В части 1 мы рассмотрели классы поведения C и A. Для класса A нам нужны более слабые ограничения согласованности. Это не означает, что система должна быть полностью некорректной, но означает, что нам нужно в некоторой мере ослабить согласованность модели.

Amazon популяризировал концепцию «Конченой согласованности». Вот их определение: система хранения гарантирует, что если не было новых обновлений объекта, в конечном счете все точки доступа будут возвращать последнее обновленное знчение.

Это не ново, но здорово, когда концепция сформулирована/популяризирована. Несколько примеров систем с конечной согласованностью:

  1. DNS
  2. Асинхронная мастер/слэйв репликация в реляционных СУБД (и в MongoDB тоже).
  3. Memcached перед MySQL, чтение из кэша

Многие (но не все) традиционные примеры, которые приходят в голову, обладают конечной согласованностью чтения, но в них единственный писатель (единственный сервер данных, пишущих клиентов может быть несколько). Все еще более интересно и сложно в ситуации с несколькими писателями. Amazon Dynamo — пример системы с конечной согласованностью множества писателей. Возможно, все что было до — это конечная согласованность с единственным писателем.

Другая традиционная технология, которую следует упомянуть, — это очередь сообщений. Она обладает свойствами, напоминающими конечную согласованность.

Формы согласованности

Давайте рассмотрим конкретный пример. Рассмотрим систему, использующую MongoDB в следующей конфигурации:

Для примера сущности «мастер», «слэйв» и «слэйв» могут быть инстансами MongoDB или другой базы данных с асинхронной репликацией. Клиенты случайным образом читают из любого слэйва, а записывают всегда в мастер. Показаны два слэйва и два клиента, но предположим, что все это масштабируется.

Этот тип системы мы называем «конечная согласованность с одним писателем». Какие ее свойства?

  1. Клиент может прочитать устаревшие данные.
  2. Клиент может увидеть операции записи вне очереди

Предположим, что мы храним некоторую сущность x в хранилище данных. Предположим, что сущности обладают некоторым первоначальным значением — нулём. Клиентами были произведены следующие операции записи в x:

W(x=3), W(x=7), W(x=5)

Так как система конечно согласована, то если записи в x остановились в какой-то момент, мы знаем, что в конце концов прочитаем из x 5 — это R(x==5). Однако в короткой перспективе клиент может увидеть, например:

R(x==7), R(x==0), R(x==5), R(x==3)

(Заметьте, что для такого поведения необходимо от 2 и более узлов.)

Так как это наша слабейшая форма согласованности — конечная согласованность с беспорядочными(ошибочными) чтениями в короткой перспективе.

Мы можем сделать согласованность строже. Рассмотрим конфигурацию MongoDB наSourceForge (большая диаграма здесь). Эта конфигурация представляет из себя конечную согласованность, но мы не увидим результатов записей в неправильном порядке. Эта система обладает монотонной согласованностью чтения.

Единственное возможное свойство конечной согласованности — это согласованность чтения своих же собственных записей. Это означает, что процессу гарантировано во время чтения увидеть записи, которые он сделал. Это очень полезное свойство, облегчающее программирование. Заметьте, что вышеприведенные примеры не обеспечивают согласованность чтения своих же записей. Также относительно этой модели стоит рассмотреть определение слова «своих же». В web приложениях это может быть пользователь. Если балансировщик нагрузки системы посылает запросы к разным серверам с приложением, согласованность чтениях своих же записей для конкретного сервера с приложением может не удовлетворять потребности реального мира в согласованности.

Пункты проверки конкретного случая

Таким образом, когда вы используете конечную согласованность архитектуры, не помешает задуматься над следующими вопросами:

  • Терпимо ли в моем случае при чтении получать устаревшие данные?
  • Терпимо ли при чтении получать значения не по порядлку? Если нет, то обеспечивает ли моя конфигурация согласованность монотонного чтения?
  • Терпимо ли не иметь возможности прочитать свои же записи? Если нет, то обеспечивает ли моя конфигурация согласованность чтения своих же записей?

Автор статьи: Блог MongoDB
Дата: 5 апреля 2010
Оригинал статьи

Один отзыв на «Распределенная согласованность — Часть 2 — Некоторые формы конечной согласованности»

  1. Спасибо! Полезная и интересная статья!

Leave a Reply

Your email address will not be published. Required fields are marked *