технологии хранения и обработкибольших объёмов данныхМодели согласованности.Алгоритмы консенсуса

Дмитрий Барашев8 апреля 2016

Computer Science Center

Этот материал распространяется под лицензией

Creative Commons”Attribution - Share Alike” 3.0

http://creativecommons.org/licenses/by-sa/3.0/us/deed.ru

сверстано в онлайн LATEX редакторе

P

a

peeriapapeeria.com

сегодня в программе

Модели согласованности

CAP и КО

Слабая согласованность

Алгоритмы консенсуса

Paxos

3/55

атомарность vs распространение обновления

• Шардирование vs репликация• Требуется атомарно обновить данные в разныхшардах⇒ одна задача

• Требуется определить правила обновленийреплик⇒ другая задача

4/55

атомарное обновление

• То, что стоит за буквами ACI в транзакциях вреляционных БД

• Может быть реализовано в распределённой БДвнешними средствами

• От БД требуется атомарность обновления записив шарде и/или Compare-And-Set

5/55

правила обновления реплик

• Алиса сделала запись в судебном протоколе• В какой момент эту запись увидит Болванщик?• Если Алиса после записи прочитает протокол,увидит ли она свою запись?

• Что произойдёт, если Болванщик и Алиса делаютзаписи одновременно?

• Может ли сделанная запись внезапно временноисчезнуть?

6/55

идеальный мир

• Конкурентных записей не бывает.• Наблюдатели видят обновления сразу после ихподтверждения.

• Уровень изоляции serializable в ACID СУБД

7/55

сегодня в программе

Модели согласованности

CAP и КО

Слабая согласованность

Алгоритмы консенсуса

Paxos

8/55

cap теорема

• В асинхронной системе¹ из этих трех вещейможно выбрать только две:• Consistency (строгая согласованность)• Availability (доступность)• Partition tolerance (устойчивость кразделению)

Теорема, но не догма

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

9/55

cap теорема

• В асинхронной системе¹ из этих трех вещейможно выбрать только две:• Consistency (строгая согласованность)• Availability (доступность)• Partition tolerance (устойчивость кразделению)

Теорема, но не догма

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

9/55

методы кристобаля хунты

– Мы сами знаем, что эта задача неимеет решения. Мы хотим знать, какеё решать.

10/55

согласованность

• Чтение объекта X возвращает одно и то жезначение вне зависимости от реплики; записьобновляет все реплики X до того, как произойдеткакое-то иное действие с X прежде, чем

• Любое чтение всегда возвращает результатпоследней записи

• Логически не всегда требуется даже в ACIDсистемах: уровень изоляции RepeatableRead/Snapshot isolation читает потенциальноустаревшие данные

11/55

согласованность

• Чтение объекта X возвращает одно и то жезначение вне зависимости от реплики; записьобновляет все реплики X до того, как произойдеткакое-то иное действие с X прежде, чем

• Любое чтение всегда возвращает результатпоследней записи

• Логически не всегда требуется даже в ACIDсистемах: уровень изоляции RepeatableRead/Snapshot isolation читает потенциальноустаревшие данные

11/55

доступность

• Любой запрос, полученный работоспособнымузлом, должен получить ответ, содержащийзапрошенные данные

• Может ли запрос выполняться неделю?• Считается ли ответом перенаправление на другойузел?

• Считается ли система из 10 идентичных read-onlyсерверов в одном ЦОД доступной послепопадания в ЦОД ядерной бомбы?

12/55

доступность

• Любой запрос, полученный работоспособнымузлом, должен получить ответ, содержащийзапрошенные данные

• Может ли запрос выполняться неделю?

• Считается ли ответом перенаправление на другойузел?

• Считается ли система из 10 идентичных read-onlyсерверов в одном ЦОД доступной послепопадания в ЦОД ядерной бомбы?

12/55

доступность

• Любой запрос, полученный работоспособнымузлом, должен получить ответ, содержащийзапрошенные данные

• Может ли запрос выполняться неделю?• Считается ли ответом перенаправление на другойузел?

• Считается ли система из 10 идентичных read-onlyсерверов в одном ЦОД доступной послепопадания в ЦОД ядерной бомбы?

12/55

доступность

• Любой запрос, полученный работоспособнымузлом, должен получить ответ, содержащийзапрошенные данные

• Может ли запрос выполняться неделю?• Считается ли ответом перенаправление на другойузел?

• Считается ли система из 10 идентичных read-onlyсерверов в одном ЦОД доступной послепопадания в ЦОД ядерной бомбы?

12/55

устойчивость к разделению

• Потеря сообщений (частичная или полная) междукомпонентами системы не влияет наработоспособность системы.

• Если мы устойчивы к разделению, то узлы внесвязанных сегментах продолжают приниматьзапросы

• Устойчивы ли мы, если продолжаем работатьодним сегментом?

13/55

выбор cp

• Выбираем устойчивость к распаду исогласованность, жертвуем доступностью

• Гарантируем некую сильную модельсогласованности и будем отказывать вобслуживании некоторых запросов в случаераспада

• Например будем обслуживать:• только запросы на чтение (системы ссинхронной репликацией)

• только доступ к данным, целикомнаходящимся внутри одной сетевойкомпоненты (шардированные системы)

14/55

выбор ap

• Выбираем устойчивость к распаду и доступность,жертвуем согласованностью

• Гарантируем что все запросы будут обслужены, нов случае распада произойдет рассогласованность:• пользователи из одной компонентысвязности не увидят изменения, сделанные вдругой компоненте

• разные версии обновлений данных в разныхкомпонентах

• Тем не менее, хочется чтоб в конце концовсистема пришла в согласованное состояние

15/55

выбор ap

• Выбираем устойчивость к распаду и доступность,жертвуем согласованностью

• Гарантируем что все запросы будут обслужены, нов случае распада произойдет рассогласованность:• пользователи из одной компонентысвязности не увидят изменения, сделанные вдругой компоненте

• разные версии обновлений данных в разныхкомпонентах

• Тем не менее, хочется чтоб в конце концовсистема пришла в согласованное состояние

15/55

выбор ca

• Гарантируем согласованность и доступность, приусловии что нет распада сети

• Однозначно работает если системанераспределенная

• Что делать, когда произойдет разделение?

• Полностью прекратить работу• Частично деградировать• Починить сеть

16/55

выбор ca

• Гарантируем согласованность и доступность, приусловии что нет распада сети

• Однозначно работает если системанераспределенная

• Что делать, когда произойдет разделение?• Полностью прекратить работу• Частично деградировать• Починить сеть

16/55

что же выбрать?

• Утверждение CAP: если сеть распалась то вампридется выбрать между согласованностью идоступностью

• Полный долговременный распад сети – вещьредкая.

• Поддержка логической согласованности – вещьнужная

17/55

то есть ca?

• В нормальной ситуации надо бытьсогласованными и доступными

• В редкие моменты распада что-то деградирует• Когда сеть восстановится, надо привести системув согласованное состояние и жить дальше

18/55

но нет

• Вокруг полно систем, заранее жертвующихстрогой согласованностью²

Но почему?!

²Привет, Mongo DB! Привет, Tarantool!

19/55

но нет

• Вокруг полно систем, заранее жертвующихстрогой согласованностью²

Но почему?!²Привет, Mongo DB! Привет, Tarantool!

19/55

время отклика

20/55

время отклика

• Высокая доступность не обсуждается• Нужно дублировать данные и сервисы• Много реплик⇒ расходы на поддержкусогласованности

• Строгая согласованность⇒ повышенное времяотклика

21/55

сделаем выбор пошире: модель pacelc

if has Partition thentrade off Availability and Consistency;

elsetrade off Latency and Consistency;

end

22/55

сегодня в программе

Модели согласованности

CAP и КО

Слабая согласованность

Алгоритмы консенсуса

Paxos

23/55

согласованность в конечном счете

• Eventual consistency• Любое обновление через некоторое времяраспространится и станет доступным для чтенияпри отсутствии последующих обновлений

eventual consistency is so eventual

24/55

согласованность в конечном счете

• Eventual consistency• Любое обновление через некоторое времяраспространится и станет доступным для чтенияпри отсутствии последующих обновлений

eventual consistency is so eventual

24/55

некоторые полутона

• «Что запишешь то прочтешь» (Read Your Own Writes)• клиент может читать свои собственные обновлениянемедленно, вне зависимости от того, на каком узле онисделаны

• Сессионная согласованность• что запишешь то прочтешь, но в рамках одной сессии

• Причинная согласованность• если процесс P1 прочитал объект X и записал объект Y топроцесс P2, увидевший новое значение Y, увидит то жесамое значение X, что и P1

• Монотонное чтение• номер версии объекта, читаемого процессом, неуменьшается

25/55

модель принятия обновлений от клиента

• Послать запись всем узлам сразу• узлы могут рассинхронизироваться

• Послать запись выделенному мастеру• запись нужно распространить на другие узлы

• Послать запись случайному узлу• Послать запись узлу, выбранному алгоритмомшардирования (хеш-функцией)• Процесс записи становится непрозрачным,клиент слишком много знает

26/55

модель распространения обновлений

• Синхронные и асинхронные• Асинхронное распространение

• обновление принимается узлом, записывается локальнои подтверждается

• фоновый процесс рассылает обновления другим узлам• разумеется не гарантирует строгую согласованность

• Синхронное распространение• запись подтверждается только если ее приняли иподтвердилиW узлов

• клиент может ждать• при некоторых условиях может обеспечить строгуюсогласованность

27/55

немного синхронной математики

• Пусть N узлов хранят реплику объекта, записьидет на W узлов, чтение с R узлов

• Если W+ R > N то множества узлов записи ичтения пересекаются и можно обеспечитьстрогую согласованность• если есть два MySQL сервера с синхроннойрепликацией то N = 2,W = 2,R = 1

• Если W+ R <= N то множества могут непересечься• два MySQL сервера с асинхроннойрепликацией: N = 2,W = 1,R = 1

28/55

вариации

• Системы, ориентированные на согласованность,будут устанавливать W = N,R = 1• и будут отказывать в записи если какой-то изW узлов упадет

• Системы, ориентированные на доступность, будутустанавливать W = 1 и разные варианты R• интересный вариант W = 1,R = N,W+ R > N:чтение всегда может выбрать последнююверсию, но узел с ней может упасть

29/55

вариации

• Системы, допускающие запись в разные узлы,скорее всего захотят W >= N+1

2

• иначе могут получиться разные версииобъекта

• Если W+ R <= N то нет особого смысла иметьR > 1• согласованности нет все равно, зачем жечитать несколько реплик

30/55

привязка сессии к серверу

• Поддержка RYOW и сессионной согласованности• Пока сессия жива, запросы прилетают к одному итому же серверу

• Сложнее делать балансировку нагрузки иустойчивость к сбоям

31/55

версионирование данных

• Если допускается слабая согласованность то могутпоявиться разные версии данных

• Нужна модель поведения, которая позволитобработать эти разные версии и сойтись к единой

32/55

оптимистичные блокировки

• Каждый элемент данных имеет свою временнуюметку

• Метки читаются вместе с данными• При записи транзакция должна убедиться, чтометки имеющихся у нее данных совпадают сактуальными на момент записи

• Если это не так, транзакция не принимается• Если метки совпали то производится запись иметки записанных элементов обновляются• сильно помогает атомарная операцияCompare-And-Swap (CAS)

• Много приложений: ETag и If-Match заголовки вHTTP, редактирование страниц в Wikipedia, etc.

33/55

сегодня в программе

Модели согласованности

CAP и КО

Слабая согласованность

Алгоритмы консенсуса

Paxos

34/55

реализация eventual consistency

• WAL³ – стандартный способ распространенияобновлений

• Каждая реплика имеет свою копию журналаопераций• в журнал записываются изменения состояниясистемы

• В случае сбоя реплика читает журнал, применяетоперации⇒ восстанавливается

• Если у реплик одинаковое начальное состояние иодинаковый журнал то они будут согласованы

³Write Ahead Log, журнал

35/55

реплицируемый журнал

• Новые значения дописываются в конец журнала• Могут ли компоненты распределённой системыдоговариться о новом значении?

• Цель: достигать консенсунс по каждомузаписываемому значению

36/55

задача консенсуса

• Консенсус – процесс принятия единого решениягруппой участников

• Подтверждать или нет транзакцию• Синхронизация часов• Выбор узла-координатора какого-то болеевысокоуровневого протокола

• Решение перейти к какой-то следующей фазеалгоритма

37/55

действующие лица

Клиент посылает системе запросы и ждёт ответы. Например,просит записать новое значение в строку таблицы

Инициаторproposer

принимает запрос клиента и делает системе предло-жение с полученным значением

Выборщикacceptor/voter

отдает или не отдает свой голос за утверждениепредложения

Кворумquorum

группа выборщиков, необходимая для утвержденияпредложения

Исполнительlearner

узнаёт об утверждении предложенного значения ипредпринимает по этому поводу действия, напри-мер, записывает значение в строку и/или посылаетответ клиенту

Процесс программный код, участник системы, выполняющийодну или несколько ролей

38/55

желательные свойства алгоритма консенсуса

• Могут быть утверждены только внесённыепредложения

• В очередной раунд голосования может бытьутверждено только одно предложение

• Если исполнитель узнал об утверждениипредложения, значит оно действительно былоутверждено

• Если предложение утверждено, то исполнителирано или поздно об этом узнают

• Если какое-то предложение внесено, то какое-топредложение будет утверждено

39/55

что может быть проще?

1 List log = new ArrayList();2 List<Learner> learners = new ArrayList<>();3

4 synchronized void propose(Object value) {5 log.add(value);6 for (Learner l : learners) {7 l.notify(value);8 }9 }

40/55

проблемы

В распределённых системах только двепо-настоящему сложных проблемы:

2. Отсутствие дубликатов сообщений1. Гарантированный порядок доставки сообщений2. Отсутствие дубликатов сообщений

41/55

проблемы

• Процессы могут падать• Хуже того, они могут восстанавливаться и сноваприсоединяться к системе

• Сообщения посылаются асинхронно, доставляютсяПочтой России могут быть переставлены местами,доставлены со значительным опозданием или недоставлены вовсе

но зато:

• Процессы соблюдают протокол; если сообщениядоставляются, то неповреждёнными; любой процессможет послать сообщение любому

42/55

история

“Раскопки на острове Паксос показали, чтоместный парламент работал в условияхчастичной доступности депутатов иотсутствия единого секретаря. Депутатынадолго уезжали и забывали свои сообщения,но тем не менее поддерживали свои записи озаконодательных актах в согласованномсостоянии.

– из статьи Лесли Лэмпорта ”43/55

предположения

• Выборщики могут выбывать из строя• Выборщики с надежным долговременнымхранилищем могут присоединяться снова

• Выборщики не устраивают диверсий• Выборщики могут посылать друг другу сообщения• Сообщения доставляются асинхронно, занеопределённое время, могут быть перепутаны,потеряны или дублированы

• Если сообщение доставлено, то оно доставленонеповреждённым

44/55

идея 1: простейший случай

• Всё работает без сбоев и один инициатор делаетодно предложение

• Выборщики (хотя бы один), очевидно, должны егоутвердить

Что делать если инициаторов более одного?

45/55

идея 1: простейший случай

• Всё работает без сбоев и один инициатор делаетодно предложение

• Выборщики (хотя бы один), очевидно, должны егоутвердить

Что делать если инициаторов более одного?

45/55

идея 2: кворум

• Предложений > 1. Утвердить надо одно. Нужнаполитика определения победителя.

• Самое простое: утверждается предложение, закоторое проголосовал кворум – больше половинывыборщиков• в этом случае у предложения точно большеголосов чем у конкурентов

• Но сообщения доставляются не мгновенно

46/55

что-то пошло не так

P1 P2 A1 A2 A3

Propose V1Accept

Propose V2AcceptPropose V2

ו Не хочется навсегда зависнуть без кворума

47/55

идея 3: выбор другого предложения

• Будем генерировать возрастающие номерапредложений

• Пока значение не утверждено, разрешимвыборщику принимать новые предложения

• Но когда значение утверждено, разрешим емупринимать только новые предложения сутвержденным значением

Откуда выборщик знает что предложение утверждено?

48/55

идея 3: выбор другого предложения

• Будем генерировать возрастающие номерапредложений

• Пока значение не утверждено, разрешимвыборщику принимать новые предложения

• Но когда значение утверждено, разрешим емупринимать только новые предложения сутвержденным значением

Откуда выборщик знает что предложение утверждено?

48/55

идея 4: инициатор делает правильныепредложения

• Об утверждении может узнать инициатор• Инициатор связывается с кворумом• Если уже было утверждено значение, то это тожесделал кворум

• У двух кворумов есть общий выборщик⇒ онможет рассказать инициатору всю правду обутверждении

Но как его, общего, найти?

49/55

идея 4: инициатор делает правильныепредложения

• Об утверждении может узнать инициатор• Инициатор связывается с кворумом• Если уже было утверждено значение, то это тожесделал кворум

• У двух кворумов есть общий выборщик⇒ онможет рассказать инициатору всю правду обутверждении

Но как его, общего, найти?

49/55

идея 5: инициатор всех обзванивает

• Просто спросить у всех выборщиков из кворума,какое последнее значение каждый из нихутвердил

• Если никто ничего не утверждал значит можнодавать своё значение

• Если кто-то участвовал в утверждении, то он обэтом скажет и сообщит значение и номерпредложения

• Надо выбрать предложение с наибольшимномером

• На это нужно некоторое время

Что если в это время кто-то из кворума получитзапоздалое предложение с меньшим номером?

50/55

идея 5: инициатор всех обзванивает

• Просто спросить у всех выборщиков из кворума,какое последнее значение каждый из нихутвердил

• Если никто ничего не утверждал значит можнодавать своё значение

• Если кто-то участвовал в утверждении, то он обэтом скажет и сообщит значение и номерпредложения

• Надо выбрать предложение с наибольшимномером

• На это нужно некоторое время

Что если в это время кто-то из кворума получитзапоздалое предложение с меньшим номером? 50/55

идея 6: выборщик дает обещание

• Получив предложение с номером n выборщикдает обещание игнорировать предложения сномером m < n

51/55

алгоритм

• Фаза 1 (подготовка): Инициатор рассылаетпредложения кворуму и собирает с выборщиковобещания и утвержденные значения

• Фаза 2 (утверждение): Инициатор выбираетзначение и просит выборщиков его утвердить

52/55

фаза 1

• Инициатор выбирает номер предложения ирассылает кворуму запрос подготовки с этимномером

• Если выборщик получил запрос подготовки сномером n• n больше номера всех предложений в ранеепринятых запросов подготовки? Если нет, тоигнорируй это предложение (или ответьNACK), если да, то обещай игнорировать всебудущие с номером < n

• у тебя есть утвержденное предложение?верни инициатору его номер и его значение

53/55

фаза 2

• Инициатор получил ответы от всего кворума. Еслиникто не вернул ранее утвержденное значение,инициатор волен предложить своё. Еслиутверждённые значения есть, инициатор долженпредложить значение с максимальным номеромпредложения. Запрос утверждения сноварассылается всему кворуму.

• Если выборщик получил запрос утверждения сномером n то он его утверждает, если только неуспел уже поучаствовать в Фазе 1 дляпредложения с номером > n

54/55

критика

• Paxos считается сложным для понимания• хотя Leslie Lamport замечает что в описаниинет ни одной формулы сложнее чем n > m

• Ванильный Paxos рассчитан на утверждениеодного значения; в реальности журнал состоит измногих значений и Paxos не специфицирует как сними обращаться• нет уверенности что Multi-Paxos работает• попытки оптимизаций и модификаций дляпоследовательности значений приводят кпоявлению доморощенных недоказанныхпротоколов

55/55