Где применяется богоподобная теория CAP?

CAP — обязательная теория для архитекторов, разрабатывающих или проектирующих распределенные системы.

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

Теорема CAP, также известная как теорема Брюэра, была гипотезой, предложенной Эриком Брюэром, ученым-компьютерщиком из Калифорнийского университета, и позже было доказано, что она является общепризнанной теоремой в области распределенных вычислений. Однако Брюэр не дал подробного определения трех CAP (согласованность, доступность, устойчивость к разделению), когда он опубликовал CAP, поэтому в Интернете много говорят о различных интерпретациях CAP.

Теорема CAP

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

В распределенной системе (имеется в виду набор узлов, которые связаны друг с другом и совместно используют данные), когда дело доходит до операций чтения и записи, могут быть гарантированы только Consistence, Availability и Partition Tolerance.Два из них, другой должны быть принесены в жертву.

В этой версии теории CAP обсуждаются распределенные системы, и в ней больше внимания уделяется взаимосвязи и совместно используемым данным. Фактически, она также проясняет некоторые недостатки первой версии с тремя вариантами выбора и двумя. Распределенные системы не обязательно имеют взаимосвязь и совместно используемые данные. Например, между кластерами memcached нет соединения и общих данных, поэтому распределенные системы, такие как кластеры memcached, не входят в сферу обсуждения теории CAP, но кластер Mysql — это взаимосвязь, совместное использование и репликация данных, поэтому тип кластера MySQL принадлежит к обсуждение объекта теории CAP.

Последовательность

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

Доступность

Исправный узел возвращает разумный ответ за разумное время.

Допуск перегородки

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

В распределенной среде сеть не может быть на 100% надежной, и могут быть сбои, поэтому разбиение на разделы является необходимой опцией.Если выбран CA и отказ от P, если происходит разделение, то для обеспечения C система должна запретить запись Если это необходимо для обеспечения A, нормальный раздел может записывать данные, а неисправный раздел не может записывать данные, поэтому он конфликтует с C. Следовательно, для распределенной системы теоретически невозможно выбрать архитектуру CA, а необходимо выбрать архитектуру CP или AP.

Теория распределенных транзакций BASE

Теория BASE является расширением и дополнением к CAP, и дополнением к схеме AP в CAP.Даже в случае выбора схемы AP, как лучше в конце концов достичь C.

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

Пример практического применения CAP в эксплуатации

Кажется, что есть много понимания.Чтобы узнать о CAP проекта, вы можете обратиться к книге Ли Юньхуа «Изучение архитектуры с нуля».Главы 21 и 22 подробно описывают теоретические детали CAP и процесс эволюции версии CAP. .

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

Центр регистрации услуг, что выбрать: AP или CP?

Проблемы, решаемые сервисным реестром

Прежде чем обсуждать CAP, давайте уточним, что в основном решает реестр служб: первое — это регистрация служб, а другое — обнаружение служб.

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

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

Некоторые компоненты, используемые в настоящее время в качестве реестра, примерно следующие: zookeeper of dubbo, eureka springcloud, consul, nameServer RocketMq и nameNode hdfs. В настоящее время основные микросервисы — это dubbo и springcloud, а наиболее часто используемые — zookeeper и eureka Давайте посмотрим, как выбрать реестр в соответствии с теорией CAP. (springcloud тоже может использовать zk, но это не мейнстрим и обсуждаться не будет).

смотритель зоопарка выбирает CP

Zookeep гарантирует CP, то есть запросы на доступ к zookeeper в любое время могут получить непротиворечивые результаты данных, а система отказоустойчива для сегментации сети, но не может гарантировать доступность каждого сервиса. Из реальной ситуации, при использовании zookeeper для получения списка сервисов, если zk выбирает или более половины машин в zk кластере недоступны, данные не будут получены. Поэтому zk не может гарантировать доступность услуги.

эврика выбрать AP

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

Проблема согласованности данных между zookeeper и eureka

Прежде всего, должно быть ясно, что первоначальное намерение eureka — создать реестр, но zk — это скорее служба распределенной координации, но поскольку его характеристики даны реестру dubbo, его ответственность больше заключается в обеспечении данных ( Данные конфигурации, данные о состоянии) согласуются между всеми службами, находящимися под юрисдикцией, поэтому нетрудно понять, почему zk разработан как CP, а не AP.Основной алгоритм zk, ZAB, заключается в решении проблемы избыточных данных в распределенных систем Проблема согласованной синхронизации между сервисами.

По более глубокой причине, zookeeper построен по принципу CP, то есть он должен поддерживать согласованность данных каждого узла, если узел под zookeeper отключен или сеть разделена на кластер (например, подсети коммутатора не могут получить доступ друг к другу), то zk удалит их из своей области управления, и внешний мир не сможет получить доступ к этим узлам, даже если эти узлы исправны и могут предоставлять нормальные услуги, поэтому запросы к этим узлам будут потеряны .

Однако у eureka вообще нет таких забот.Ее узлы относительно независимы, и нет необходимости рассматривать вопрос согласованности данных.Это должно быть рождение eureka предназначено для регистрационного центра.По сравнению с zk, выбор узла-лидера и Журнал транзакций является экстремальным, что больше способствует поддержанию и обеспечению надежности работы eureka.

Давайте посмотрим на проблемы, которые несоответствие данных принесет eureka в сервисе регистрации, это не что иное, как то, что на определенном узле зарегистрировано больше сервисов, а на определенном узле меньше сервисов, что может привести к тому, что некоторые ip-узлы будут зарегистрированы. в определенный момент.Количество звонков небольшое, и у некоторых ip нод есть небольшое количество звонков. Также возможно, что есть какие-то грязные данные, которые должны были быть удалены, но не были удалены.

Резюме: Должна ли регистрация службы выбирать AP или CP

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

Поэтому для регистрации службы доступность важнее согласованности данных, выбирайте AP.

Распределенная блокировка, выбрать AP или выбрать CP?

Вот три способа реализации распределенных блокировок:

• Распределенная блокировка на основе базы данных
• Распределенная блокировка на основе Redis
• Распределенная блокировка на основе zookeeper

Распределенная блокировка на основе базы данных

построить структуру таблицы

Используйте УНИКАЛЬНЫЙ КЛЮЧ таблицыidx_lock (method_lock) в качестве единственного первичного ключа, действие вставки выполняется при выполнении блокировки и успешном входе в базу данных, блокировка считается успешной, а когда база данных сообщает о дублирующейся записи, это означает, что блокировку получить невозможно.

Однако этот метод в принципе не позволяет реализовать отказоустойчивость P-раздела для mysql, который не может автоматически переключать ведущий-ведомый одним ведущим (автоматическое переключение ведущий-ведомый в MySQL в настоящее время не имеет идеального решения). Можно сказать, что этот метод сильно зависит от доступности базы данных.Операция записи базы данных является одной точкой.Как только база данных зависнет, блокировка станет недоступной. Этот подход в основном выходит за рамки обсуждения CAP.

Распределенная блокировка на основе Redis

Однопоточная последовательная обработка Redis, естественно, предназначена для решения проблемы сериализации и подходит для решения распределенных блокировок.

Метод реализации:

setnx key value Expire_time
获取到锁 返回 1 ， 获取失败 返回 0

Чтобы решить проблему переключения блокировок базы данных «главный-подчиненный», вы можете выбрать режим кластера redis или дозорного дозорного для достижения аварийного переключения «ведущий-подчиненный». снова главный узел. .

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

Таким образом, режим репликации Redis — это режим AP. Чтобы обеспечить доступность, при репликации ведущий-ведомый «ведущий» имеет данные, но «ведомый» может не иметь данных. В это время, как только ведущий зависает или дрожит сеть и по другим причинам, он может переключиться на «ведомый». " узел. В настоящее время это может привести к тому, что два деловых округа получат две блокировки одновременно

Процесс выглядит следующим образом:

1. Бизнес-поток-1 запрашивает блокировку у главного узла
2. Бизнес-поток-1 получает блокировку
3. Бизнес-поток-1 получает блокировку и начинает выполнение бизнеса
4. В настоящее время блокировка, только что сгенерированная Redis, не была синхронизирована между ведущим и подчиненным.
5. В это время главный узел Redis зависает.
6. Ведомый узел Redis обновлен до главного узла
7. Бизнес-поток-2 хочет, чтобы новый главный узел запросил блокировку
8. Бизнес-поток-2 получает блокировку, возвращенную новым главным узлом.
9. Бизнес-поток-2 получает блокировку и начинает выполнение бизнеса
10. В настоящее время бизнес-поток-1 и бизнес-поток-2 выполняют задачи одновременно.

Вышеупомянутая проблема на самом деле не является дефектом Redis, но Redis принимает модель AP, которая сама по себе не может обеспечить наши требования к согласованности. Redis официально рекомендует алгоритм redlock, чтобы гарантировать, что проблема заключается в том, что для реализации redlock требуется как минимум три экземпляра master-slave redis, а стоимость обслуживания относительно высока, что эквивалентно redlock, использующему три кластера redis для реализации собственного набора согласованности. алгоритмы, что громоздко.Промышленность также использует меньше.

Могу ли я использовать Redis в качестве распределенной блокировки?

Можно ли использовать redis в качестве распределенной блокировки, это не проблема самого redis, а зависит от бизнес-сценария.Сначала мы должны подтвердить, подходит ли наш сценарий для AP или CP.Если он находится в публикации в социальных сетях и других сценариях, мы не очень сильны.Redis очень подходит для предоставления нам высокопроизводительной модели AP, но если это тип транзакции, который очень чувствителен к согласованности данных, нам, возможно, придется найти более подходящую модель CP.

Распределенная блокировка на основе zookeeper

Я только что проанализировал, что redis на самом деле не может обеспечить согласованность данных. Давайте сначала посмотрим, подходит ли zookeeper в качестве нужной нам распределенной блокировки. Прежде всего, режим zk - это модель CP, то есть когда zk lock предоставляется нам для доступа в кластере zk, чтобы убедиться, что эта блокировка существует на каждом узле zk.

(На самом деле это гарантируется тем, что лидер zk отправляет запрос на запись в два этапа, что также является узким местом для большого масштаба кластера zk)

Принцип реализации zk lock

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

характеристика:

• упорядоченный узел

Когда упорядоченный узел создается в родительском каталоге, таком как /lock, узел будет создан из узлов lock000001, lock000002, lock0000003 в строгом порядке и т. д., упорядоченный узел может строго гарантировать, что каждый собственный узел создается в соответствии с порядок и название.

• временный узел

Клиент устанавливает временный узел. Когда сеанс клиента завершится или истечет время сеанса, zookepper автоматически удалит идентификатор решения.

• прослушиватель событий

При чтении данных мы можем установить монитор на узле.Когда данные узла изменяются (1 узел создается, 2 узел удаляется, данные 3 узла становятся данными 4 собственного узла), zookeeper уведомляет клиента.

Объединив эти функции, давайте посмотрим, как zk объединяет распределенные блокировки.

1. Бизнес-поток-1 и бизнес-поток-2 соответственно применяются к каталогу /lock zk для создания упорядоченных временных узлов.
2. Бизнес-поток-1 захватывает файл /lock0001, то есть узел с наименьшим порядком во всем каталоге, то есть поток-1 получает блокировку.
3. Бизнес-поток-2 может захватить только файл /lock0002, а не самый маленький узел заказа, потоку 2 не удалось получить блокировку
4. Бизнес-поток-1 устанавливает соединение с замком 0001 и поддерживает пульсацию, которая является периодом аренды замка.
5. Когда бизнес-поток-1 завершит дело, соединение с зк будет разблокировано, то есть будет снята блокировка

Реализация кода распределенной блокировки zk

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

Резюме: Должны ли использоваться распределенные блокировки CP или AP?

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

Будь то redis, zk, например, модель AP redis ограничит множество сценариев использования, но среди них она имеет самую высокую производительность.Распределенная блокировка Zookeeper гораздо надежнее, чем redis, но ее громоздкий механизм реализации привел к ее производительность не так хороша, как у redis, а производительность zk будет снижаться еще больше по мере расширения кластера.

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

Распределенные транзакции, как избавиться от ACID и присоединиться к CAP/BASE

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

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

достичь окончательной согласованности

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

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

БАЗОВАЯ модель

Модель BASE является противоположностью традиционной модели ACID. В отличие от ACID, BASE делает упор на отказ от высокой согласованности для достижения доступности. Данные допускают несогласованность в течение определенного периода времени, если гарантируется окончательная согласованность.

Модель BASE — это анти-ACID-модель, которая полностью отличается от ACID-модели: она жертвует высокой согласованностью ради доступности или надежности: «Основная доступность» в принципе доступна. Поддержка сбоя раздела (например, сегментация базы данных) Мягкое состояние Мягкое состояние Состояние может быть асинхронным и асинхронным в течение определенного периода времени. Непротиворечивое в конечном счете является непротиворечивым в конечном счете, а окончательные данные непротиворечивы, но не всегда непротиворечивы.

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

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

• Двухэтапная фиксация (2PC)
• Компенсационная транзакция (TCC)
• локальная таблица сообщений
• Сообщение транзакции MQ

Двухэтапная фиксация (2PC)

На самом деле есть и XA-транзакция базы данных, но реальное применение в реальном интернете в основном редкое, а двухфазный коммит использует принцип XA.

В протоколе XA есть две фазы:

1. Менеджер транзакций запрашивает у каждой базы данных, участвующей в транзакции, предварительную фиксацию этой операции и указывает, может ли она быть зафиксирована.
2. Координатор транзакций требует, чтобы каждая база данных фиксировала данные или выполняла откат данных.

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

Кроме того, хотя протокол двухфазной фиксации разработан для строгой согласованности распределенных данных, все же существует вероятность несогласованности данных, например:

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

Компенсационная транзакция (TCC)

TCC – это двухэтапная сервисно-ориентированная модель. Каждая бизнес-служба должна реализовывать три метода: "попробовать", "подтвердить" и "вычислить". Эти три метода могут соответствовать блокировке, фиксации и откату в транзакциях SQL.

По сравнению с двухэтапной фиксацией TCC решает несколько проблем.

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

1) попробуйте этап

try — это просто предварительная операция для выполнения предварительного подтверждения. Его основная обязанность — завершить все бизнес-проверки и зарезервировать бизнес-ресурсы.

2).Подтвердить этап

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

3) отмена — отменить выполнение.Если попытка не удалась и ресурсы, зарезервированные на фазе попытки, были освобождены, она также должна удовлетворять идемпотентности и может выполняться непрерывно, как и подтверждение.

Пример оформления заказа и формирования заказа на вычет запасов:

Далее давайте посмотрим, как наш процесс размещения заказа на вычет запасов присоединяется к TCC.

При попытке он позволит службе инвентаризации зарезервировать n запасов для этого заказа, позволить службе заказов сгенерировать «неподтвержденный» заказ и одновременно сгенерировать эти два зарезервированных ресурса. При подтверждении будут использоваться ресурсы, зарезервированные на этапе try.В механизме транзакции TCC считается, что если ресурсы, которые могут быть зарезервированы в обычном режиме на этапе try, могут быть полностью отправлены на этапе подтверждения

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

Это не предмет обсуждения того, как реализуются транзакции tcc, а основное внимание уделяется применению распределенных транзакций в теории CAP+BASE. Реализация может означать:GitHub.com/ часто детали…

локальная таблица сообщений

Схема локальной таблицы сообщений изначально была предложена eBay, а полная схема eBayqueue.ACM.org/detail Кухонные двери?…

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

Для локальных очередей сообщений ядром является преобразование больших транзакций в мелкие транзакции или объяснение примера блокировки заказа в приведенном выше примере.

1. Когда мы переходим к созданию заказа, мы добавляем локальную таблицу сообщений, записываем инвентаризацию создания и вычета заказов в локальную таблицу сообщений и помещаем их в одну и ту же транзакцию (полагаемся на локальную транзакцию базы данных для обеспечения согласованности).
2. Настройте запланированное задание для ротации локальной таблицы транзакций, сканирования локальной таблицы транзакций и отправки неотправленных сообщений в службу инвентаризации. Когда служба инвентаризации получит сообщение, она сократит инвентаризацию и запишет ее в таблицу транзакций сервера. Обновить статус таблицы транзакций.
3. Сервер инвентаризации уведомляет службу заказов через запланированные задачи или напрямую, а служба заказов обновляет статус в локальной таблице сообщений.

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

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

MQ-транзакция

RocketMq официально объявил, что поддерживает распределенные транзакции в версии 4.3.При выборе Rokcetmq для распределенных транзакций обязательно выберите версию выше 4.3.

Распределенная транзакция, реализованная в RocketMQ, на самом деле является инкапсуляцией локальной таблицы сообщений, которая перемещает локальную таблицу сообщений внутрь MQ.

Как асинхронная гарантированная транзакция, сообщения транзакций асинхронно отделяют две ветви транзакций через MQ. Процесс проектирования сообщений транзакций RocketMQ также опирается на теорию двухэтапной фиксации. Общий процесс взаимодействия показан на следующем рисунке:

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

RocketMQ выбирает асинхронное/синхронное обновление, асинхронную/синхронную репликацию, CP и AP.

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

Синхронная очистка/асинхронная очистка

Сообщения RocketMQ могут сохраняться, а данные будут сохраняться на диске. Чтобы повысить производительность, RocketMQ гарантирует, что диск будет записан в максимально возможной последовательности. Когда источник записывает сообщение в RocketMq, существует два способа записи сообщения. сообщение на диск:

1. Асинхронная очистка: сообщение быстро записывается в кэш страниц памяти, и статус успешной записи возвращается немедленно.Когда сообщение в памяти накапливается до определенного уровня, запускается операция записи на унифицированный диск. Этот метод может гарантировать высокую пропускную способность, но также существует риск того, что сообщения могут не сохраниться на диске и быть потерянными.
2. Синхронная очистка: сообщение быстро записывается в кэш страниц памяти, и поток очистки немедленно уведомляется о необходимости очистки диска.После завершения очистки ожидающий поток пробуждается, и возвращается статус успешной записи сообщения.

Синхронная репликация / Асинхронная репликация

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

1. Синхронная репликация: статус успешной записи сообщается клиенту после того, как и мастер, и ведомый успешно записаны.
2. Асинхронная репликация: Пока мастер выполняет успешную запись, он может сообщить об успешном завершении записи клиенту.

Преимущество асинхронной репликации в том, что она может повысить скорость отклика, но жертвует согласованностью.Как правило, алгоритмы, реализующие такие протоколы, нуждаются в добавлении дополнительных механизмов компенсации. Преимущество синхронной репликации заключается в том, что она может гарантировать согласованность (как правило, посредством протокола двухфазной фиксации), но имеет высокие накладные расходы и низкую доступность (см. теорему CAP), что приводит к большему количеству конфликтов и взаимоблокировок. Стоит отметить, что протокол репликации Lazy+Primary/Copy очень удобен в реальной производственной среде.

Настройки RocketMQ следует сочетать с бизнес-сценарием, а режим флеша и режим репликации master-slave ставить разумно, особенно режим SYNC_FLUSH, из-за частого срабатывания действий записи на диск производительность будет значительно снижена. При нормальных обстоятельствах главный и подчиненный должны быть настроены на метод сброса ASYNC_FLUSH, а главный и подчиненный должны быть настроены на метод репликации SYNC_MASTER, чтобы даже в случае сбоя одной машины можно было гарантировать, что данные не будут потеряны.

Суммировать

При построении микросервисов нельзя избежать теории CAP, потому что сеть никогда не будет стабильной, аппаратное обеспечение всегда устаревает, а программное обеспечение может иметь ошибки, поэтому отказоустойчивость разделов является неизбежным предложением в микросервисах.Можно сказать, что как пока Он распределен, пока кластер стоит перед выбором AP или CP, но когда очень жадничаешь, нужна и консистентность и доступность, можно только пойти на небольшой компромисс по консистентности, то есть введение теории BASE в бизнесе. Достигайте конечной согласованности там, где это возможно.

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