технологии хранения и обработкибольших объёмов данныхМодели согласованности.Алгоритмы консенсуса
Дмитрий Барашев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