Фреймворк: распределенная теория CAP, BASE

Java
Фреймворк: распределенная теория CAP, BASE

предисловие

По мере расширения бизнеса появляется все больше и больше функций. Поместите все функции в одну и ту же службу, код смешанный и чередующийся, что затрудняет обслуживание, и легко вызвать небольшую ошибку, которая сделает всю службу недоступной. Поэтому мы разделим его на множество различных сервисов (формирование микросервисов) по бизнес-функциям.Система, состоящая из множества сервисов, имеет громкое название: распределенная система, и как мы должны управлять статусом сервисов в системе?, Что такое соответствующие теории?

  • Распределенные и кластеризованные
  • транзакция базы данных
  • Распределенная транзакция
  • Согласованность распределенных данных
  • Теория CAP
  • БАЗОВАЯ теория

Следуйте по официальному аккаунту, общаться друг с другом и найдите на WECHAT: okek вперед

Распределенные и кластеризованные

  • Распределенная относится к системе, образованной путем обмена информацией и взаимодействия с несколькими службами или компонентами, подключенными через сеть.
  • Кластер относится к целому, образованному несколькими экземплярами одного и того же сервисного компонента.
  • Эти два понятия полностью не противоречат друг другу, и распределенная система тоже может быть кластером. Кластер zookeeper также является распределенной системой, его сервисы будут общаться и взаимодействовать друг с другом.
  • Дело в том, что кластер не является распределенной системой. Например, несколько HTTP-серверов с балансировкой нагрузки не будут взаимодействовать друг с другом. Если часть балансировки нагрузки не включена, ее нельзя назвать распределенной системой.

транзакция базы данных

  • Транзакции работают на основе данных.Необходимо обеспечить, чтобы данные транзакций обычно хранились в базе данных.Поэтому, когда мы вводим транзакции, мы должны вводить характеристики ACID транзакций базы данных.
  • Атомарность, все операции во всей транзакции либо завершаются, либо не завершаются, и нельзя застаиваться на каком-то звене посередине
  • Непротиворечивость, до начала транзакции и после ее завершения ограничения согласованности данных базы данных не нарушаются.
  • Изоляция, которая может предотвратить несогласованность данных из-за перекрестного выполнения, когда несколько транзакций выполняются одновременно.
  • Долговечность, после завершения транзакции модификация данных постоянна, даже в случае сбоя системы они не будут потеряны

Распределенная транзакция

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

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

Сложности распределенных транзакций

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

Согласованность распределенных данных

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

теория CAP

  • Проблемы, связанные с трудностями распределенных транзакций, введенные ранее, в конечном итоге приведут к несогласованности данных.Ниже приводится теоретический анализ проблемы согласованности распределенных систем, и распределенные решения (доступность и согласованность) будут представлены на основе этих теорий. : Теория CAP)
  • Непротиворечивость: все узлы имеют доступ к последней идентичной копии данных.
  • Доступность: исправный узел возвращает разумный ответ (не ответ об ошибке или тайм-ауте) за разумное время.
  • Устойчивость к разделам: когда распределенная система имеет сетевые разделы, она все равно может предоставлять услуги внешнему миру.

Когда происходит сетевой раздел, если мы хотим продолжить службу, то строгая согласованность и доступность могут быть только 1 из 2. То есть, когда сеть разделена, P является предпосылкой, и после того, как P определено, можно выбрать C и A. То есть допуск к разделу (допуск к разделу) мы должны достичь

Почему нет гарантии CA в то же время?

Если система «разделена», узел в системе выполняет операцию записи. Чтобы обеспечить консистенцию C, операции чтения и записи других узлов должны быть запрещены, которые конфликтуют с A; если для того, чтобы убедиться, что операции чтения и записи других узлов являются нормальными, то согласованность данных не может быть гарантировано, а это конфликтует с помощью

Кейс практического применения CAP

  • ZooKeeper гарантирует СР. Запросы на чтение к ZooKeeper в любое время могут получить согласованные результаты, но ZooKeeper не гарантирует доступность каждого запроса, например, сервис недоступен во время процесса выбора лидера или когда недоступно более половины машин.
  • Что гарантирует Эврика, так это AP. Eureka предназначена для того, чтобы отдавать приоритет A (доступность). В Эврике нет узла-лидера, все узлы одинаковы и равны. Поэтому у Eureka не будет ситуации, когда сервис недоступен в процессе выборов или когда больше половины машин недоступно, как у ZooKeeper. Eureka гарантирует, что даже если большинство узлов выйдет из строя, это не повлияет на нормальное предоставление услуг, пока доступен один узел. Просто данные по этому узлу могут быть не самыми последними

БАЗОВАЯ теория

  • BASE является в основном доступным, мягким и в конечном итоге согласованным. Теория BASE является результатом компромисса между согласованностью (C) и доступностью (A) в CAP.
  • Согласованность в конечном счете — это частный случай слабой согласованности.Система гарантирует, что состояние согласованности данных может быть достигнуто в течение определенного периода времени.

в основном доступны

Основные средства распределенных систем, доступных во времена непредсказуемых сбоев, позволяют потере частичной доступности; это то, что позволяет потерей части наличия этого?

  • Потеря времени отклика: в нормальных условиях обработка запроса пользователя для возврата результата занимает 0,5 с, но из-за сбоя системы время обработки запроса пользователя становится равным 3 с.
  • Потеря системных функций: при нормальных обстоятельствах пользователи могут использовать все функции системы, но из-за внезапного расширения доступа к системе некоторые неосновные функции системы недоступны.

мягкое состояние

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

возможная согласованность

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

Добро пожаловать на ошибку в тексте

Справочная статья