Читаем и обсуждаем Кабанчика, глава 9. Consistency and Consensus

• В видео обсуждается глава 9 книги "Distributed Systems" Мартина Клэпмана.  

• Обсуждаются темы консистенций и стронг, а также их применение в распределенных системах.  

• В видео приводятся примеры консистенций, таких как каузальная и стронг.  

• Обсуждается, как определить причинно-следственные связи и как они влияют на консистенцию системы.  

• В видео подчеркивается важность понимания консистенций для разработки распределенных систем.  

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

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

• Если событие а происходит до события б, то событие б не может произойти до события а.  

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

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

• Если процесс один пишет единицу, процесс два пишет двойку, процесс три читает единицу, процесс четыре читает двойку, то это нормальная ситуация.  

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

• Эти механизмы позволяют обеспечить порядок событий и избежать проблем с консистенцией.  

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

• Для решения этой проблемы вводится понятие "логические часы" или "лаймпорт тайм стемпс".  

• Это позволяет выстроить порядок событий и определить, какое событие произошло раньше или позже.  

• Частичный порядок позволяет определить, что события произошли одновременно или в обратном порядке, но не позволяет определить, какое событие произошло раньше.  

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

• С использованием векторных часов можно выстроить полную линию реализуемости событий.  

• Это позволяет идентифицировать каждое событие и выстроить его в полную линию.  

• Участники обсуждают теорему Брювера, которая говорит о трех факторах консистенции: согласованность, доступность и партишин-толерантность.  

• Они обсуждают, что теорема подразумевает только один вид партишин-толерантности, но на самом деле есть разные виды, такие как феллер и алати.  

• Участники обсуждают различные виды консистентности, такие как строгая консистенция, линия реализуемость и другие.  

• Они также обсуждают, что в теореме Брювера можно достичь только двух из трех свойств, но не всех трех одновременно.  

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

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

• Обсуждение проблемы распределенных транзакций в микросервисной архитектуре, где разные сервисы должны выполнять транзакционные операции.  

• Предлагаются два алгоритма: двухфазный комит и трехфазный комит.  

• В двухфазном комите координатор вводит две фазы: первая фаза - выполнение своих действий, вторая фаза - комит.  

• Если координатор падает, то все откатываются, если все микросервисы ответили "прип", то координатор продолжает отправлять комиты.  

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

• Если координатор падает, то происходит реэлекция координатора и решение о том, откатывать или продолжать.  

• Автор избегает использования распределенных транзакций, предпочитая делить монолитные микросервисы по доменам.  

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

• В книге "Designing Data-Intensive Applications" Мартин Клэпман упоминает трехфазный комит, но не дает подробного описания.  

• Обсуждение использования двухфазных комитов в распределенных транзакциях в базах данных.  

• Упоминается, что не нужно реализовывать их самостоятельно, так как они уже реализованы внутри кластерных систем.  

• Описание алгоритма Рафт, который используется для достижения консенсуса в кластере.  

• Упоминается, что в алгоритме есть фазы выбора лидера и эпохи, в течение которой лидер отправляет сообщения о своем состоянии.  

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

• Демонстрация работы алгоритма на примере кластера из пяти узлов.  

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

• Фолловеры получают сообщения и догоняют лидера, чтобы быть консистентными.  

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

• Упоминается, что лидер может быть выбран из-за тайм-аутов или из-за отсутствия хардбитов.  

• Если лидер не получает хардбиты, он инициирует новые выборы.  

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

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

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

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

• В видео обсуждаются вопросы о рафте и дополнении.  

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

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

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

• Упоминается, что рафт и пксус имеют разные профили работы, где рафт обеспечивает всю нагрузку на одного лидера, а пксус позволяет распределить нагрузку по разным узлам.  

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

• Если кворум не достигнут, то лидер может отменить операцию, даже если она была успешно отправлена.  

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

• В этом случае, операции, отправленные на чтение или запись, могут быть отменены, если кворум не достигнут.  

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

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

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

• В Cassandra, проблема решается на основе временных меток, а в MongoDB используется система оповещений и согласований.  

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

• В случае, когда данные пишутся в оба кластера, но модифицируются только в одном, возникает проблема с выбором лидера.  

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