Пример реального мира Паксос
Может кто-нибудь дать мне реальный пример того, как алгоритм Paxos используется в распределенной базе данных? Я прочитал много работ на Paxos, которые объясняют алгоритм, но ни одна из них не объясняет на реальном примере.
Простым примером может служить банковское приложение, в котором учетная запись изменяется через несколько сеансов (т. Е. Депозит в кассе, дебетовая операция и т. Д.). Используется ли Paxos, чтобы решить, какая операция произойдет первой? Кроме того, что подразумевается под несколькими экземплярами протокола Paxos? Как, когда это используется? По сути, я пытаюсь понять все это на конкретном примере, а не на абстрактных терминах.
2 ответа
Например, у нас есть система MapReduce, в которой мастер состоит из 3 хостов. Один хозяин, а другие рабы. В процедуре выбора мастера используется алгоритм Paxos.
Также Chubby из Google Big Table использует Paxos: сервис Chubby Lock для слабо связанных распределенных систем, Bigtable: распределенную систему хранения для структурированных данных.
Может кто-нибудь дать мне реальный пример того, как алгоритм Paxos используется в распределенной базе данных?
MySQL использует Paxos. Вот почему для высокодоступной установки MySQL требуется три сервера. Напротив, типичная конфигурация Postgres - это конфигурация "главный-подчиненный" с двумя узлами, на которой не работает Paxos.
Я прочитал много работ на Paxos, которые объясняют алгоритм, но ни одна из них не объясняет на реальном примере.
Вот довольно подробное объяснение Paxos для репликации журнала транзакций. А вот исходный код, который реализует его в Scala. Paxos (он же multi-Paxos) оптимально эффективен с точки зрения сообщений, поскольку в кластере с тремя узлами в устойчивом состоянии лидер принимает свое собственное следующее значение, передает на оба других двух узла и знает, что значение является фиксированным, когда оно получает один ответ. Затем он может поместить сообщение фиксации (обучающее сообщение) в начало следующего отправляемого значения.
Простым примером может служить банковское приложение, в котором учетная запись изменяется через несколько сеансов (т. Е. Депозит в кассе, дебетовая операция и т. Д.). Используется ли Paxos, чтобы решить, какая операция произойдет первой?
Да, если вы используете кластер базы данных MySQL для хранения банковских счетов, тогда Paxos используется для обеспечения того, чтобы реплики согласовывались с мастером в отношении порядка применения транзакций к банковским счетам клиентов. Если все узлы согласовывают порядок применения транзакций, все они будут иметь одинаковые сальдо.
Операции с банковским счетом не могут быть переупорядочены без учета других остатков, которые могут нарушать бизнес-правила, не превышающие ваш кредит. Тривиальный способ обеспечить заказ - это просто использовать один серверный процесс, который определяет официальный заказ просто на основе порядка сообщений, которые он получает. Затем он может отслеживать остатки на каждом банковском счете и применять бизнес-правила. Тем не менее, вам не нужен только один сервер, так как он может дать сбой. Вам нужны серверы реплик, которые также получают команды кредита и дебета и согласны с мастером.
Проблема с наличием реплик, которые должны содержать одинаковые балансы, состоит в том, что сообщения могут быть потеряны и повторно отправлены, а сообщения буферизуются коммутаторами, которые могут доставлять некоторые сообщения с опозданием. Общий эффект состоит в том, что если сеть нестабильна, трудно доказать, что протоколы быстрой репликации никогда не приведут к тому, что разные серверы увидят, что сообщения поступили в разных порядках. Вы будете в конечном итоге с разными серверами в одном кластере с разными балансами.
Вам не нужно использовать Paxos для решения проблемы банковских счетов. Вы можете просто сделать простую репликацию master-slave. У вас есть один мастер, один или несколько подчиненных, и мастер ждет, пока он не получит подтверждения от подчиненных, прежде чем сообщить любому клиенту результат выполнения команды. Проблема там потерянных и переупорядоченных сообщений. До изобретения Paxos производители баз данных только что создали дорогостоящее оборудование, разработанное для обеспечения очень высокой избыточности и надежности для работы master-slave. Что было революционным в Paxos, так это то, что он работает с обычными сетями и без специального оборудования.
Поскольку банковские приложения были прибыльными при использовании дорогостоящего специального оборудования, вполне вероятно, что многие реальные банковские системы все еще работают таким образом. В таких случаях поставщик базы данных поставляет специализированное оборудование со встроенной надежной сетью, на которой работает программное обеспечение базы данных. Это очень дорого, а не то, что хотят небольшие компании. Компании, которые заботятся о затратах, могут настроить кластер MySQL на виртуальных машинах в любом общедоступном облаке с нормальной сетью, и Paxos сделает его надежным, а не используя специальное оборудование.
Кроме того, что подразумевается под несколькими экземплярами протокола Paxos? Как, когда это используется?
Я написал блог о том, что multi-Paxos - это оригинальный протокол Paxos. Проще говоря, в случае выбора порядка транзакций в кластере вы хотите направить транзакции в виде потока значений. Каждое значение фиксируется в отдельном логическом экземпляре протокола. Как описано в моем блоге о Paxos для кластерной репликации, алгоритм очень эффективен в стационарном режиме, когда требуется только одна передача туда и обратно между главным и достаточным количеством узлов, чтобы получить большинство, то есть один другой узел в кластере из трех узлов. При возникновении сбоев или проблем с сетью алгоритм всегда безопасен, но требует больше сообщений. Поэтому, чтобы ответить на ваш вопрос, типичные приложения нуждаются в нескольких раундах Paxos, чтобы установить порядок клиентских команд в кластере.
Следует отметить, что Raft был специально придуман как подробное описание того, как выполнять репликацию кластера. Оригинальные документы Paxos требуют, чтобы вы выяснили многие детали для выполнения кластерной репликации. Таким образом, мы можем ожидать, что люди, которые специально пытаются реализовать кластерную репликацию, будут использовать Raft, поскольку разработчику ничего не придется выяснять самостоятельно.
Итак, когда вы могли бы использовать Paxos? Его можно использовать для изменения членства в кластере кластера, который записывает значения на основе другого протокола, который может быть правильным, только если вы знаете точное членство в кластере. Корфу является отличным примером того, где он устраняет узкое место записи с помощью одного главного устройства, когда клиенты одновременно выполняют запись в сегменты серверов. Тем не менее, он может делать это точно только тогда, когда все клиенты имеют точное представление о текущем членстве в кластере и структуре сегментов. Когда происходит сбой узлов или вам нужно расширить кластер, вы предлагаете новое членство в кластере и макет сегмента и запускаете его через Paxos для достижения консенсуса по всему кластеру.
База данных Clustrix - это распределенная база данных, которая использует Paxos в менеджере транзакций. Paxos используется внутренними компонентами базы данных для координации сообщений и поддержания атомарности транзакций в распределенной системе.
- Координатор - это узел, на котором произошла транзакция
- Участники - это узлы, которые изменили базу данных от имени
- Считыватели транзакций - это узлы, которые выполняли код от имени транзакции, но не изменяли никакого состояния.
- Акцепторы - это узлы, которые регистрируют состояние транзакции.
При выполнении фиксации транзакции предпринимаются следующие шаги:
- Координатор отправляет сообщение ПОДГОТОВИТЬ каждому участнику.
- Участники блокируют состояние транзакции. Они отправляют ПОДГОТОВЛЕННЫЕ сообщения обратно Координатору.
- Координатор отправляет сообщения ACCEPT акцепторам.
- Акцепторы регистрируют идентификатор участника, транзакцию, идентификатор фиксации и участников. Они отправляют ПРИНЯТЫЕ сообщения обратно Координатору.
- Координатор сообщает пользователю, что фиксация прошла успешно.
- Координатор отправляет сообщения COMMIT каждому Участнику и Читателю.
- Участники и Читатели фиксируют транзакцию и соответственно обновляют состояние транзакции. Они отправляют сообщения COMMITTED обратно координатору.
- Координатор удаляет внутреннее состояние и теперь готово.
Это все прозрачно для приложения и реализовано во внутренней базе данных. Таким образом, для вашего банковского приложения все, что нужно сделать уровню приложения, - это выполнить обработку исключений для конфликтов тупиков. Другим ключом к реализации базы данных в масштабе является параллелизм, который обычно поддерживается с помощью MVCC (Multi-Version параллелизм управления).
Raft- это алгоритм консенсуса, который прост для понимания. Это эквивалентноPaxosв отказоустойчивости и производительности. Разница в том, что она разбита на относительно независимые подзадачи и полностью решает все основные части, необходимые для практических систем.Raft должен был быть более понятным, чем Paxosпосредством разделения логики, но он также формально признан безопасным и предлагает некоторые дополнительные функции. Raft предлагает общий способ распределения конечного автомата по кластеру вычислительных систем, гарантируя, что каждый узел в кластере согласен с одной и той же серией переходов состояний.
Практическое использование на плоту
etcd строго согласованный, distributed key-value storeкоторый обеспечивает надежный способ хранения данных, к которым должен получить доступ распределенная система или кластер машин. Он изящно обрабатывает выборы лидера во время сетевых разделов и может выдерживать сбой машины, даже в главном узле. Приложения любой сложности, от простого веб-приложения доKubernetes, может читать и записывать данные в etcd.
etcd написан на Go, который имеет отличную кроссплатформенную поддержку, небольшие двоичные файлы и большое сообщество. Связь между машинами etcd осуществляется через алгоритм консенсуса Raft.