65

Click here to load reader

Базы данных. Distributed Commit

Embed Size (px)

DESCRIPTION

Обсуждаем здесь: http://incubos.org/posts/2013/09/23/db-commit/

Citation preview

Page 1: Базы данных. Distributed Commit

Distributed CommitКурс «Базы данных»

Цесько Вадим Александровичhttp://incubos.org

@incubos

Computer Science Center

23 сентября 2013 г.

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 1 / 65

Page 2: Базы данных. Distributed Commit

Содержание

1 Distributed Commit

2 Happens-before

3 Raft

4 Заключение

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 2 / 65

Page 3: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

Two-Phase Commit Protocol

Distributed atomic commitment protocolcommit или abort (rollback)Переживает (некоторые) временные сбоиПолагается на логгирование для восстановленияВосстановление — бОльшая часть логикипротокола

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 3 / 65

Page 4: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

Фазы

Commit-request (voting)Координатор пытается подготовить участниковтранзакцииКаждый участник отвечает Yes или No

CommitКоординатор принимает решение на основе ответовВсе сказали Yes ⇒ commit, No ⇒ abortКоординатор отправляет решение участникамУчастники применяют решение

ПредусловиеЕсли нет сбоев

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 4 / 65

Page 5: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

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

Выделенный координаторStable storage1 + write-ahead log (WAL)Узлы не умирают навсегдаДанные в WAL не теряются и не портятсяЛюбые два узлы могут общаться

ВниманиеЕсли полностью уничтожить узел, можно потерятьданные

1http://en.wikipedia.org/wiki/Stable_storageЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 5 / 65

Page 6: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

Диаграмма

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 6 / 65

Page 7: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

Оптимизации

Presumed abort/commit: работает привосстановлении, экономим на логгировании,используем статистику и ожиданияTree two-phase commit protocol(Nested/Recursive 2PC): агрегация в узлах дерева,экономнее используем сетьDynamic two-phase commit: идём по дереву водну сторону, динамический выбор координатора,быстрее освобождаем ресурсы

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 7 / 65

Page 8: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

Ограничения

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

Участник отправил координатору YesКоординатор упалУчастник ожидает commit или rollback

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 8 / 65

Page 9: Базы данных. Distributed Commit

Distributed Commit Two-Phase Commit Protocol

Поведение при сбоях

Пример ситуации:Реплика выполнила commit и упала вместе скоординаторомСистема не может восстановить результаттранзакции:

Только умершие 2 ноды знают точный результатPessimistic abort невозможен — упавшая репликамогла сделать commitPessimistic commit невозможен — изначальноерешение могло быть abort

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 9 / 65

Page 10: Базы данных. Distributed Commit

Distributed Commit Three-Phase Commit Protocol

Three-Phase Commit Protocol

Назначение как у 2PCНеблокирующийся — ограничение сверху наcommit/abortЛучше ведёт себя при сбоях2

2PC фаза Commit разбивается на 2 фазы —получаем 3PC

2http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 10 / 65

Page 11: Базы данных. Distributed Commit

Distributed Commit Three-Phase Commit Protocol

Диаграмма

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 11 / 65

Page 12: Базы данных. Distributed Commit

Distributed Commit Three-Phase Commit Protocol

Анализ

Вторая фаза доносит решение до всех участников⇒ состояние можно восстановить при сбоерепликиPhase 3 = 2PC CommitПри сбое координатора состояниевосстанавливается с помощью реплик:

Phase 1 (кто-то не получил Can commit?) ⇒спокойно делаем abortPhase 2 (кто-то получил preCommit) ⇒ доводимтранзакцию до commit

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 12 / 65

Page 13: Базы данных. Distributed Commit

Happens-before Lamport timestamps

Lamport timestamps

ЦельОпределить порядок событий в распределённойсистемеa

aLamport, L. Time, Clocks, and the Ordering of Events in aDistributed System. 1978

Правила:Каждый процесс имеет счётчикИнкремент перед каждым событиемЗначение счётчика вместе с каждым сообщениемПри получении сообщенияCself = max(Cself ,Csender)

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 13 / 65

Page 14: Базы данных. Distributed Commit

Happens-before Lamport timestamps

Формализация

C (x) — время события x∀a∀b(a 6= b ⇒ C (a) 6= C (b))Для различия событий в разных процессах частодобавляют PIDОтношение happens-before: →Clock consistency: a→ b ⇒ C (a) < C (b)Strong clock consistency: C (a) < C (b)⇒ a→ b —только через Vector ClocksНо верно, что C (a) ≥ C (b)⇒ a 6→ b

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 14 / 65

Page 15: Базы данных. Distributed Commit

Happens-before Lamport timestamps

Анализ

Невозможно точно синхронизировать время3

Если процессы не общаются, то между ихсобытиями нет отношения порядкаОбеспечивается лишь частичный порядок

3Хотя см. http://research.google.com/archive/spanner.htmlЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 15 / 65

Page 16: Базы данных. Distributed Commit

Happens-before Vector clocks

Vector clocks

ЦельВвести частичный порядок событий враспределённой системеОбнаружить нарушения причинно-следственныхсвязей

ОпределениеВекторные часы в системе с N процессами — этомассив N логических часов по одному на процесс

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 16 / 65

Page 17: Базы данных. Distributed Commit

Happens-before Vector clocks

Правила обновления массива часов

Изначально все часы выставлены в 0При каждом событии процесс инкрементируетсвои логические часы на 1Перед отправкой сообщения процесс:

Инкрементирует свои логические часыОтправляет весь вектор вместе с сообщением

При получении сообщения процесс:Инкрементирует свои логические часыОбновляет свой вектор, беря покомпонентныймаксимум с присланным вектором

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 17 / 65

Page 18: Базы данных. Distributed Commit

Happens-before Vector clocks

Пример

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 18 / 65

Page 19: Базы данных. Distributed Commit

Happens-before Vector clocks

Формализация

VC (x) — векторные часы события xVC (x)z — компонента векторных часов процесса zVC (x) < VC (y)⇔ ∀z [VC (x)z ≤VC (y)z ] ∧ ∃z ′[VC (x)z ′ < VC (y)z ′]x → y ⇔ VC (x) < VC (y)VC (x) < VC (y)⇒ C (x) < C (y)Отношение happens-before антисимметрично итранзитивно

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 19 / 65

Page 20: Базы данных. Distributed Commit

Raft Введение

МотивацияThere are significant gaps between the description of thePaxos algorithm and the needs of a real-world system...and the final system will be based on an unprovenprotocol4.

RaftПротокол консенсуса для реплицированныхавтоматовБолее простой, понятный и реализуемый чемPaxosДемонстрирует логику рассуждений

4Chandra T. D., Griesemer R., Redstone J. Paxos made live: an engineeringperspective. 2007Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 20 / 65

Page 21: Базы данных. Distributed Commit

Raft Введение

Ссылки

Replicated State Machines5

Ongaro D., Ousterhout J. In Search of anUnderstandable Consensus Algorithm. 2013.Diego Ongaro. Raft lecture6 (Raft user study)Diego Ongaro. Paxos lecture7 (Raft user study)Множество реализаций8

5http://en.wikipedia.org/wiki/State_machine_replication6http://www.youtube.com/watch?v=YbZ3zDzDnrw7http://www.youtube.com/watch?v=JEpsBg0AO6o8https://ramcloud.stanford.edu/wiki/display/logcabin/LogCabin

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 21 / 65

Page 22: Базы данных. Distributed Commit

Raft Введение

Replicated State Machines

Работают на множестве узловВычисляют идентичные копии одного и того жесостоянияУстойчивы к падению узловРеплицированный лог (последовательностькоманд)Решаемые задачи: выбор лидера, хранилищеконфигураций и др.Примеры: Chubby (GFS), ZooKeeper in HDFS, ...

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 22 / 65

Page 23: Базы данных. Distributed Commit

Raft Введение

Особенности Raft

Strong LeaderКлиенты общаются только с лидеромДанные только от лидера к репликам

Leader ElectionCлучайные таймеры

Membership changesJoint consensus

Формальна описана и доказана безопасностьПроизводительность на уровне аналогов

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 23 / 65

Page 24: Базы данных. Distributed Commit

Raft Введение

Алгоритм работы лидера

1 Получить команду от клиента2 Добавить в локальный лог3 Доставить команду другим узлам4 При успехе применить команду к своему автомату5 Вернуть ответ автомата клиенту

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 24 / 65

Page 25: Базы данных. Distributed Commit

Raft Введение

Свойства протокола

Безопасность: никогда не вернёт некорректныйрезультат

non-Byzantine fault tolerance9

Учитывает ненадёжную сетьДоступность

Пока работают и могут общаться большинство узловУзлы останавливаются и снова подключаются

Независимость от абсолютного времениКоманда выполняется при ответе отбольшинства — устойчивость к медленным узлам

9http://en.wikipedia.org/wiki/Byzantine_fault_toleranceЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 25 / 65

Page 26: Базы данных. Distributed Commit

Raft Введение

Подсистемы

Выбор лидераРепликация логаБезопасность/корректность

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 26 / 65

Page 27: Базы данных. Distributed Commit

Raft Кластер

Кластер

Несколько узлов (3, 5, ...)Узёл в одном из трёх состояний: leader, follower,candidateВ нормальном режиме: 1 лидер и n − 1последователейПоследователи пассивны: отвечают на RPC отлидера и кандидатов

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 27 / 65

Page 28: Базы данных. Distributed Commit

Raft Кластер

Состояния узла

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 28 / 65

Page 29: Базы данных. Distributed Commit

Raft Кластер

Семестры

Время разбивается на семестры (terms)неопределённой длины10

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

ИнвариантВ каждом семестре не больше одного лидера

10Аналог логических часовЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 29 / 65

Page 30: Базы данных. Distributed Commit

Raft Кластер

Семестры: Пример

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 30 / 65

Page 31: Базы данных. Distributed Commit

Raft Кластер

Обнаружение устаревшей информации

Каждый узел хранит текущий семестрТекущий семестр каждый раз передаётся взапросахЕсли текущий семестр меньше пришедшего,выбираем пришедшийЕсли кандидат или лидер — step downЕсли пришедший семестр меньше текущего, тоотвергаем запрос

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 31 / 65

Page 32: Базы данных. Distributed Commit

Raft Кластер

RPC

RequestVote — кандидат просит отдать ему голосAppendEntries — лидер реплицирует команды +heartbeat

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 32 / 65

Page 33: Базы данных. Distributed Commit

Raft Выбор лидера

Условия запуска

Follower не получает heartbeat в течение electiontimeoutFollower увеличивает текущий семестрПереходит в состояние кандидатаПараллельно отправляет всем RequestVoteПерезапросы до получения ответа или окончаниявыборов

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 33 / 65

Page 34: Базы данных. Distributed Commit

Raft Выбор лидера

Условия останова

Follower выиграл выборы (набрал большинствоголосов)

Каждый узел голосует единожды за семестр (FIFO)Новый лидер начинает рассылать всем heartbeats

Другой узел стал лидеромКандидат получил AppendEntries с семестром ≥текущегоКандидат переходит в состояние follower (step down)

Наступил таймаут, а победителя всё нетНикто не набрал большинства голосовКандидат переходит в состояние follower (step down)Random election timeout

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 34 / 65

Page 35: Базы данных. Distributed Commit

Raft Репликация лога

Формат лога

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 35 / 65

Page 36: Базы данных. Distributed Commit

Raft Репликация лога

Committed Entry

Гарантируется, что будет выполнена всемиавтоматамиВ простейшем случае — если подтвержденазапись большинством (см. записи 1-7)Лидер пересылает индекс последнего коммита вAppendEntries — followers коммитят

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 36 / 65

Page 37: Базы данных. Distributed Commit

Raft Репликация лога

Log Matching Property

Если у двух записей в разных логах совпадают индекси семестр, то:

Они содержат одинаковую командуЛидер создаёт не больше одной записи с одниминдексом и семестромЗаписи в логе не перемещаются

Логи идентичны во всех предшествующих записяхЛидер с AppendEntries пересылает индекс и семестрпредыдущей записиFollower отвергает запрос, если не совпадаетШаг индукции

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 37 / 65

Page 38: Базы данных. Distributed Commit

Raft Репликация лога

Но может быть так

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 38 / 65

Page 39: Базы данных. Distributed Commit

Raft Репликация лога

Пояснения

a-b — не хватает записейc-d — лишние записиe-f — оба случая

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 39 / 65

Page 40: Базы данных. Distributed Commit

Raft Репликация лога

Разрешение конфликтов

Замена конфликтов на followers записями логалидераЛидер помнит nextIndex для каждого follower —изначально следующий за последним в логеИспользуется RPC AppendEntries ConsistencyCheck

Если ошибка, то nextIndex - 1 и retryЕсли совпадение, то удаляется хвост и добавляютсязаписи лога лидера

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

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 40 / 65

Page 41: Базы данных. Distributed Commit

Raft Корректность

Проблема

Лидер закоммитил несколько записейПоследователь был недоступенЛидер ушёл с радаровПоследователь стал новым лидеромПоследователь перезаписал всем логиВ результате разные автоматы выполнили разныйнабор команд

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 41 / 65

Page 42: Базы данных. Distributed Commit

Raft Корректность

РешениеРасширим протокол:

Ограничение на узлы, которые могут статьлидеромОграничение на записи, которые считаютсязакоммичеными

Обеспечиваем:Лидер любого семестра содержит все записи,закоммиченые в предыдущих семестрахЗаписи направлены только от лидера кпоследователямЛидеры никогда не перезатирают записи в своёмлоге

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 42 / 65

Page 43: Базы данных. Distributed Commit

Raft Корректность

Ограничение на выбор лидера

Всё так же нужно собрать голоса большинстваНо можно стать лидером, только если наш лог неменее свежий, чем у каждого голосующегоRequestVote RPC содержит информацию опоследней записи в логеЛог новее, если семестр старше или индексбольше (лог длиннее)

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 43 / 65

Page 44: Базы данных. Distributed Commit

Raft Корректность

Коммиты

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 44 / 65

Page 45: Базы данных. Distributed Commit

Raft Корректность

Случай 1

Наиболее популярныйЛидер реплицирует запись из текущего семестраЗапись закоммичена, как только подтвердитбольшинствоЛидером могут стать только те, у кого есть этазапись

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 45 / 65

Page 46: Базы данных. Distributed Commit

Raft Корректность

Коммиты

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 46 / 65

Page 47: Базы данных. Distributed Commit

Raft Корректность

Случай 2

Лидер коммитит запись из предыдущего семестраЛидер семестра 2 создал запись по индексу 2,отреплицировал на S1 и S2 и упалS5 стал лидером в семестре 3 (собрал голоса у S3и S4)Записал запись в свой лог по индексу 2 и упалS1 стал лидером в семестре 4 (голоса от S2 и S3)Отреплицировал запись по индексу 2 на S3Незакоммичена несмотря на большинствоS5 может стать лидером (его лог новее чем S2, S3и S4) и распространить своё значение поиндексу 2

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 47 / 65

Page 48: Базы данных. Distributed Commit

Raft Корректность

Ограничение на коммиты

Пока новый лидер не закоммитит запись изтекущего семестра, он считает предыдущиезаписи незакоммиченымиСм. случай 3 — после этого S5 не может статьлидеромСм. доказательство корректности11

11Safety proof and formal specification for Raft: http://raftuserstudy.s3-website-us-west-1.amazonaws.com/proof.pdfЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 48 / 65

Page 49: Базы данных. Distributed Commit

Raft Timing and availability

Timing and availability

Timing requirementbroadcastTime � electionTimeout � MTBF

Типичные значения:broadcastTime: 0.5-20 mselectionTimeout: 10-500 msMTBF : � month

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 49 / 65

Page 50: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Изменение конфигурации кластера

Предполагали, что состав узлов статиченНо иногда нужно заменять сервера или изменятьуровень репликацииВ идеале — без downtimeИ автоматически — исключить человеческийфактор

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 50 / 65

Page 51: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Ситуация

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 51 / 65

Page 52: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Проблема

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

Решения:2PC: сначала выключаем старую конфигурацию,возможен downtimeRaft: промежуточная конфигурация (jointconsensus)

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 52 / 65

Page 53: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Идея

Комбинация двух конфигураций:Записи реплицируются серверам в обеихконфигурацияхСервер из любой конфигурации может статьлидеромНужно собрать большинство в каждойконфигурации по-отдельностиПри этом без downtime

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 53 / 65

Page 54: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Joint Consensus

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 54 / 65

Page 55: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Алгоритм

Запрос лидеру на смену конфигурации с Cold наCnew

Сохраняет в лог Cold ,new и реплицируетКаждый сервер сохраняет Cold ,new в лог и сразуначинает использоватьЛидер упал — новый лидер из Cold ,new или Cold , ноне Cnew

Успешно закоммитили — лидером может статьтолько Cold ,new

Лидер сохраняет в лог Cnew и реплицирует и т. д.Cold и Cnew не могут одновременнопринимать решения

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 55 / 65

Page 56: Базы данных. Distributed Commit

Raft Изменение конфигурации кластера

Особенности

Если лидер входит в Cold , но не в Cnew , то долженвыйти из кластера (реплицирует, но не входит вбольшинство)Новые сервера могут быть пустыми — вначаледобавляем как неголосующих, но реплицируем наних логиУдаление серверов, которые не в курсе, что ихудаляют, может снизить производительностькластера — инициируют безнадёжные выборы

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 56 / 65

Page 57: Базы данных. Distributed Commit

Raft Оптимизации

Log Compaction

Подходы:Очистка логов — перемещаем «живые» записи вголову и очищаем мёртвый хвост

Инкрементально и эффективноОпределение живых записей может быть сложным

Слепки — состояние системы периодическисохраняется на stable storage, а лог сбрасывается

Менее эффективно (неинкрементально)Просто

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 57 / 65

Page 58: Базы данных. Distributed Commit

Raft Оптимизации

Snapshotting

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 58 / 65

Page 59: Базы данных. Distributed Commit

Raft Оптимизации

Snapshotting: Нюансы

Нужно решить, когда создавать слепки —например, при достижении логом определённогоразмераCopy-on-write для асинхронной записи слепков +functional data structures/fork()

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 59 / 65

Page 60: Базы данных. Distributed Commit

Raft Клиент

Проблема

Команда может применяться несколько разЛидер получил команду, закоммитил и умер, неуспев ответитьКлиент делает перезапрос

ИдемпотентностьКлиент присваивает командам уникальныепоследовательные номера

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 60 / 65

Page 61: Базы данных. Distributed Commit

Raft Клиент

Проблема

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

Решениеno-op в начале семестраHeartbeat с большинством кластера перед ответомна read

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 61 / 65

Page 62: Базы данных. Distributed Commit

Raft Проект

Альтернативное домашнее задание

Проект akka-raft:Open-source Raft implementationScalaAkka ExtensionParameterized by Akka FSMExtended with API (spray-based)Use Case: etcd12 implementation

12https://github.com/coreos/etcdЦесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 62 / 65

Page 63: Базы данных. Distributed Commit

Заключение Библиотечка

Библиотечка

Think Distributed: A Distributed Systems Podcast13

Наборы открытых данных для курсовой работы14

13http://thinkdistributed.io/14Via @pulser: http://www.hackathon.spb.ru/#!datasets/c1miv

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 63 / 65

Page 64: Базы данных. Distributed Commit

Заключение Homework: Feature request 1

Homework: Feature request 1

Key-Value API (кто ещё не)Данные не влезают в память (>= 4 ГБ)Используйте открытые источники данныхСтресстест в виде shell-скрипта

СкачалиРаспаковалиЗапустили Storage (Xmx1G)Залили в Storage

Срок реализации до 2013-10-14Hints: mmap(), дисковый кэш, ...

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 64 / 65

Page 65: Базы данных. Distributed Commit

Заключение Вопросы?

Вопросы?

http://incubos.org/contacts/Общие вопросы — в Twitter: @incubosВопросы по лекциям — в комментариях:http://incubos.org/blog/Частные вопросы — в почту[email protected]

Цесько В. А. (CompSciCenter) Distributed Commit 23 сентября 2013 г. 65 / 65