更新时间：2019年7月20日
предисловие
серия статей springCloud:
Понимание SpringCloud (1):nuggets.capable/post/684490…
Понимание SpringCloud (2):nuggets.capable/post/684490…
Понимание SpringCloud (3):nuggets.capable/post/684490…
Вчера мы изучили большинство оставшихся компонентов SpringCloud, центр конфигурации конфигурации, декларативный вызов службы Feign, мониторинг кластера Turbin и шину сообщений Bus.
Что касается содержания компонентов SpringCloud, давайте ненадолго остановимся.Конечно, в последующих статьях я углублюсь в анализ исходного кода компонента и конкретную роль компонента. Сегодня мы начнем изучать проблемы распределенных транзакций в SpringCloud.
По словам известного архитектора Криса Ричардсона, основные трудности, существующие при реализации Spring Cloud, заключаются в следующем:
1. После разделения одного приложения на распределенную систему механизм связи и меры по устранению сбоев между процессами становятся более сложными.
2. После того, как система станет микросервисной, кажущейся простой функции может понадобиться вызывать несколько служб и работать с несколькими базами данных внутри, и проблема распределенных транзакций вызовов служб становится очень заметной.
3. При большом количестве микросервисов становится сложнее их тестировать, развертывать и отслеживать.
По мере развития инфраструктуры RPC первая проблема постепенно решалась. Например, dubbo может поддерживать несколько протоколов связи, а springcloud может очень хорошо поддерживать спокойные вызовы. Что касается третьего вопроса, то с развитием технологий docker и devops, а также внедрением автоматизированных инструментов эксплуатации и обслуживания на различных платформах paas общедоступного облака тестирование, развертывание, эксплуатация и обслуживание микросервисов будут становиться все проще и проще.
Итак, в чем заключается проблема распределенных транзакций?
В springCloud иногда мы пишем, казалось бы, простую функцию, но внутри программы есть возможность вызвать несколько других микросервисов, и эти микросервисы могут быть не только развернуты в кластерах, но и база данных может быть подбиблиотечным разделом, и база данных будет также быть развернуты в кластере, то также будут вызываться несколько баз данных.
Тогда, когда мы выполняем такую простую функцию, как только возникает проблема с вызовом определенного шага и данные не сообщаются на месте, очень вероятно, что данные всей программы будут несогласованными и несогласованными.
Проще говоря, в распределенной системе крупная операция состоит из бесчисленного множества мелких операций, поэтому распределенные транзакции должны гарантировать, что все эти мелкие операции завершатся успешно или все завершатся неудачно, тем самым обеспечив согласованность данных.
По сути, распределенные транзакции предназначены для обеспечения согласованности данных в разных базах данных или системах обмена сообщениями.
Это проблема, с которой должен столкнуться любой разработчик — проблема распределенных транзакций!
*ps: Перед официальным стартом хочу всем порекомендовать еще одну песню.Песня Пенициллина "Rainy Night Manchester" также прозвучала из варьете "Summer of the Band".Надеюсь, она вам понравится. (^_-)☆
Анализ распределенных транзакций
Прежде чем приступить к конкретному анализу, мы должны сначала получить конкретное представление о процессе разработки распределенных вещей.
В первые дни решение для распределенных транзакций было реализовано с помощью 2pc (двухфазная фиксация) и соответствующего варианта 3PC (поскольку у 2PC были фатальные проблемы, 3PC избегал крайних случаев, разделяя первую фазу 2PC).
С развитием Интернета это решение больше не может соответствовать нашему стремлению к производительности, особенно Ant Financial от Alibaba, которая имеет чрезвычайно строгие требования к транзакциям.Поэтому появилась классическая модель TCC на основе 2PC для обеспечения согласованности транзакций.
Однако режим TCC предъявляет чрезвычайно высокие требования к программированию, поэтому существует решение проблемы транзакций, использующее промежуточное программное обеспечение сообщений для обеспечения возможной согласованности транзакций.
До 2017 года Alibaba представила решение GTS для обеспечения строгой согласованности транзакций и предоставления множества услуг интернет-пользователям, что должно быть самым передовым решением для распределенной обработки транзакций.
Это эволюция всей распределенной транзакции.
Добавить содержание:
强一致性：
当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的
更新过的值。这种是对用户最友好的，就是用户上一次写什么，下一次就
保证能读到什么。根据 CAP理论，这种实现需要牺牲可用性。
弱一致性：
系统并不保证续进程或者线程的访问都会返回最新的更新过的值。用户读
到某一操作对系统特定数据的更新需要一段时间，我们称这段时间为“不
一致性窗口”。系统在数据写入成功之后，不承诺立即可以读到最新写入
的值，也不会具体的承诺多久之后可以读到。
最终一致性：
是弱一致性的一种特例。系统保证在没有后续更新的前提下，系统最终返
回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主
要受通信延迟，系统负载和复制副本的个数影响。DNS 是一个典型的最终
一致性系统。
1. Двухэтапная схема подачи 2PC
В 2pc мы предполагаем, что есть две роли, одна — координатор, а другая — участник.
Участник несет ответственность за конкретное выполнение операции.В общем случае транзакция локальной базы данных будет открыта, а затем будет выполнена локальная транзакция базы данных.Однако после завершения выполнения локальная транзакция базы данных не будет отправлена немедленно , но ситуация (успех или неудача) каждого выполнения будет ) сообщаться координатору, а координатор анализирует, обобщая содержание, сообщенное участниками, и, наконец, решает, продолжает ли транзакция выполняться полностью, или полностью откатывается .
В частности, весь процесс можно разделить на два этапа.
Первый этап — этап запроса, когда участники отправляют свое исполнение координатору. Сообщение, отправленное участником, может быть успешным, а может и неудачным (сбой выполнения программы, если сообщение от участника не получено, это тайм-аут, а по умолчанию — сбой).
Второй этап – этап отправки, координатор получает результаты выполнения, присланные всеми участниками, анализируя эти результаты выполнения, координатор судит о том, должна ли продолжать выполняться вся программа или откатывается целиком, и затем отправляет это решение всем участникам участникам.
Недостатки этой схемы очень очевидны:
1.要等到所有的参与者执行完操作，而且参与者发送自己的结果给协调者
的时候，这两点占据了太多的公共资源。（因为要进行通信，协调者和参
与者是份属不同的微服务）
2.协调者在整个体系中太重要了，一旦出错，会导致所有的参与者进入到
阻塞状态。（实际上协调者即便宕机，但是在2PC中，会自动从参与者选
举出一个协调者，但是参与者阻塞的状态无法得到解决。）
3.当协调者统计参与者返回的数据进行分析，得出结果后，将结果发送给
所有的参与者，但是假如一部分的参与者接受结果的时候出错或者通信失
效，没有得到协调者发送的最终结果，那么会导致数据的最终不一致。
Из-за этих недостатков позже появился вариант 2ПК, 3ПК.
2. Трехэтапный план отправки 3PC
Трехэтапная схема отправки, основанная на двухэтапной схеме отправки, позволяет как участникам, так и координаторам иметь механизм тайм-аута, и разбивает первую стадию 2PC на две стадии: сначала спросить, затем заблокировать ресурсы, а затем действительно зафиксировать.
Фаза 1: координатор отправляет запрос участникам, и участники возвращают свои результаты координатору, успех или неудача.
Этап 2: Координатор проводит анализ на основе результатов, предоставленных участниками. Будет два исхода:
1.假如参与者返回的都是成功Yse，那么协调者将会发送预执行消息给参
与者，并且协调者进入到预执行准备阶段。而参与者接收到协调者发送
的指令后，将会把这些操作指令存储到数据库的事务日志中，并且进行
预执行操作。如果参与者成功完成了指令，那么就会返回结果ACK给协
调者，并且等待最终结果。
2.如果有一个参与者返回的是失败No，或者有一个参与者超时了没有返
回结果，那么协调者将会发送中断事务的指令给所有的参与者，让参与
者进行事务中断。
Третий этап: когда координатор получает результаты ACK всех участников, координатор переходит от этапа подготовки к выполнению к этапу формального выполнения и отправляет формально выполненные инструкции всем участникам. Участник получает инструкцию, формально выполняет транзакционную операцию и после успеха снова возвращает координатору инструкцию ACK об успешном выполнении. Точно так же, если один участник возвращает отказ Нет или один участник истекает без возврата результата, координатор отправит команду прервать транзакцию всем участникам, позволяя участникам прервать транзакцию.
Между фазой подготовки и фазой фиксации 2PC вставляется фаза предварительной фиксации, которая является буфером для обеспечения согласованности состояний всех участвующих узлов перед фазой окончательной фиксации.
Недостатки этой схемы:
当协调者发送中断事务的指令给参与者的时候，只有一个参与收到了执
行事务中断的指令，其他参与者没有收到，那么其他参与者会默认正式
执行事务操作。这样就会导致了整个系统状态和数据的不一致了。（一
旦事务参与者迟迟没有收到协调者的正式执行请求，就会自动进行本地
正式执行，这样相对有效地解决了协调者单点故障的问题，这就是3PC
加入的参与者的超时）
3. Схема TCC – компенсационные вопросы
Решение для распределенной транзакции, упомянутое выше, 2PC и 3PC решают проблему на уровне БД (базы данных) и основаны на протоколе XA. Узнайте об этом:
XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：
事务管理器和本地资源管理器。其中本地资源管理器往往由数据
库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而
事务管理器作为全局的调度者，负责各个本地资源的提交和回滚
。总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协
议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点
，那就是性能不理想，特别是在交易下单链路，往往并发量很高
，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想
，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录
prepare阶段日志，主备切换回导致主库与备库数据不一致。许
多Nosql也没有支持XA，这让XA的应用场景变得非常狭隘。
Поскольку 2PC и 3PC, которые основаны на протоколе XA, естественным образом наследуют все проблемы протокола XA, поэтому схема обработки транзакций TCC на основе бизнес-уровня появляется позже.
Решение TCC имеет много общего с протоколом 2PC.Даже сравнение процессов двух решений в основном одинаковое.Главная разница между ними заключается в том, что 2PC — это решение для обработки, основанное на уровне БД, а TCC — это бизнес-процесс. раствор на основе уровня лечения.
Три этапа TCC следующие:
Стадия пробы: в основном для обнаружения и резервирования ресурсов для бизнес-системы.
Фаза подтверждения: подтверждение выполнения бизнес-операции.
Стадия отмены: отменить выполнение бизнес-операции.
Поскольку модель TCC представляет собой решение, которое расширяется на уровне бизнеса, ее необходимо сочетать с бизнес-кодом.
1.所有事务参与方都需要实现try,confirm,cancle接口。
2.事务参与者向事务协调者发起事务请求，事务协调者调用
所有事务参与者的try方法完成资源的预留，这时候并没有
真正执行业务，而是为后面具体要执行的业务预留资源，这
里完成了一阶段。
3.如果事务协调者发现有参与者的try方法预留资源时候发现
资源不够，则调用参与者的cancle方法回滚预留的资源，需要
注意cancle方法需要实现业务幂等，因为有可能调用失败（比
如网络原因参与者接受到了请求，但是由于网络原因事务协调
器没有接受到回执），那么就要进行重试。
4.如果事务协调者发现所有参与者的try方法返回都OK，则事务
协调者调用所有参与者的confirm方法，不做资源检查，直接
进行具体的业务操作。
5.如果协调者发现所有参与者的confirm方法都OK了，则分布式
事务结束。
6.如果协调者发现有些参与者的confirm方法失败了，或者由于
网络原因没有收到回执，则协调器会进行重试。
Если на шестом шаге произойдет сбой после определенного количества повторных попыток, возникнет несогласованность, которую обычно называют эвристическим исключением.
Эвристическое исключение неизбежно, но вероятность этого исключения можно уменьшить до очень небольшой степени, установив соответствующий период ожидания, частоту повторных попыток и меры мониторинга. Чаще всего мы делаем компенсацию за транзакцию. Поскольку каждый шаг нашей операции заключается в записи журнала транзакций в базу данных, мы можем вызвать журнал транзакций в конце и компенсировать это через журнал транзакций. (Грубо говоря, это выполнение ручных услуг)
Вот преимущества:
解决了跨应用业务操作的原子性问题，在诸如组合支付、账务
拆分场景非常实用。TCC实际上把数据库层的二阶段提交上提
到了应用层来实现，对于数据库来说是一阶段提交，规避了
数据库层的2PC性能低下问题。
Недостаток вот в чем:
TCC的Try、Confirm和Cancel操作功能需业务提供，开发成本
高，对程序的侵入性高。此外，其实现难度也比较大，需要
按照网络状态、系统故障等不同的失败原因实现不同的回滚
策略。为了满足一致性的要求，confirm和cancel接口还必
须实现幂等。
Из режима TCC выводится схема обработки транзакций, режим SAGA. Основное отличие этой модели заключается в использовании обратной бизнес-операции для отмены предыдущей бизнес-операции. В режиме SAGA фаза попытки непосредственно обрабатывает целевое поле без предварительной обработки.По сравнению с режимом TCC, SAGA не требует операции подтверждения. Если вам интересно, вы можете пойти и узнать.
4. Программное обеспечение промежуточного слоя для обмена сообщениями RocketMQ — схема возможной согласованности
Схема обработки транзакций, основанная на промежуточном программном обеспечении сообщений, таком как TCC, является гибкой схемой обработки транзакций, и ей нужно только обеспечить конечную согласованность транзакции.
Позвольте мне сначала дать вам картинку, блок-схему обычных сообщений, вы можете понять весь процесс через числовую последовательность на картинке: (Картинка из блога, на который я ссылаюсь:у-у-у. Краткое описание.com/afraid/04 8:986 ах…
..消息生成者发送消息。
..MQ收到消息，将消息进行持久化，在存储中新增一条记录
..返回ACK给消费者。
..MQ提交消息给对应的消费者，然后等待消费者返回ACK。
..如果消息消费者在指定时间内成功返回ACK，那么MQ认为。
消息消费成功，在存储中删除消息，即执行第6步；
..如果MQ在指定时间内没有收到ACK，则认为消息消费失败
，会尝试重新push消息,重复执行4、5、6步骤。
..MQ删除消息。
Что нам нужно, так это непротиворечивость данных, поэтому в процессе обычных сообщений какие процессы вызовут несогласованность данных?
1.第1步，当消息生产者处理业务成功，但是因为宕机的原因，
消息没有发送到MQ那里，导致了事务消息不一致，从而导致
了生产者和消费者的数据不一致了。
2.第4步，MQ发送给消息消费者的时候，因为通信原因，到这
消息消费者没有收到消息，也导致了消息生产者和消息消
费者的数据不一致。
3.消息消费者处理业务成功，发送了ACK消息给MQ，但是MQ
因为处理超时了，返回的是失败消息给消息生产者，导致
生产者事务回滚，也导致了消息生产者和消息消费者的数
据不一致。
Для удаленных вызовов конечным результатом может быть успех, неудача или тайм-аут; в случае тайм-аута конечным результатом обработчика может быть успех или неудача, о которых вызывающая сторона не может знать.
Итак, как насчет транзакционных сообщений?
现在目前较为主流的MQ，比如ActiveMQ、RabbitMQ、Kafka、
RocketMQ等，只有RocketMQ支持事务消息。原因就是RocketMQ
是阿里巴巴的消息中间件。
Поскольку традиционный метод обработки не может решить проблему согласованности между успешной обработкой локальной транзакции генератора сообщений и успешной отправкой сообщения, родилось сообщение транзакции, которое реализует атомарность локальной транзакции генератора сообщений и отправка сообщения и гарантирует сообщение Возможная проблема согласованности между успехом обработки локальной транзакции производителем и успехом отправки сообщения.
(Картинка из блога, на который я ссылаюсь:у-у-у. Краткое описание.com/afraid/04 8:986 ах…
.. 事务消息与普通消息的区别就在于消息生产环节，生产者
首先预发送一条消息到MQ(这也被称为发送half消息)。
.. MQ接受到消息后，先进行持久化，则存储中会新增一条状
态为待发送的消息。
.. 然后返回ACK给消息生产者，此时MQ不会触发消息推送事件。
.. 生产者预发送消息成功后，执行本地事务。
.. 执行本地事务，执行完成后，发送执行结果给MQ。
.. MQ会根据结果删除或者更新消息状态为可发送。
.. 如果消息状态更新为可发送，则MQ会push消息给消费者，
后面消息的消费和普通消息是一样的。
будь осторожен:
Поскольку MQ обычно гарантирует успешную доставку сообщения, если бизнес не возвращает результат ACK вовремя, это может вызвать проблему повторной доставки сообщения MQ. Следовательно, для схемы конечной согласованности сообщений потребители сообщений должны поддерживать идемпотентное потребление сообщений и не могут вызывать повторное потребление одного и того же сообщения.
Недостаток сообщений о транзакциях также очевиден, то есть MQ хранит сообщения для отправки.Если возникает проблема со связью или другая проблема, MQ не может воспринять окончательный результат обработки вверх по течению.
Итак, как сообщение о транзакции RocketMQ решает эту проблему? Его решение очень простое, то есть его внутренняя реализация будет иметь временную задачу для чередования сообщений, статус которых должен быть отправлен, а затем отправить запрос на проверку производителю сообщения, а производитель сообщения должен реализовать прослушиватель проверки. content обычно предназначен для проверки того, успешно ли выполнена соответствующая локальная транзакция (обычно запрос в БД).Если она успешна, MQ установит сообщение для отправки, в противном случае он удалит сообщение.
Конечно, мы также можем добиться окончательной согласованности транзакций с помощью локальных сообщений, но концепция реализации такая же, как и то, что мы знаем сейчас с помощью RocketMQ.
5. GTS — решение для распределенных транзакций.
Вы можете взглянуть на отчет Alibaba на саммите в Шэньчжэне в 2017 году:«Решите мировые технические проблемы! GTS делает распределенные транзакции простыми и эффективными»,дорожка:Jumei.Taobao.org/2017/04/13/…
В этой статье ГТС описан очень понятно, поэтому больше говорить не буду.
резюме
Распределенные транзакции всегда были проблемой, с которой часто сталкиваются разработчики, и текущее решение GTS может быть одним из самых передовых решений на данном этапе.
Однако технологии совершенствуются, и в следующий момент могут появиться более подходящие решения, но в любом случае основная идея состоит в том, чтобы обеспечить согласованность данных и избежать появления грязных данных.
На сегодняшний день распределенные транзакции для изучения очень сложны.Я просто изучаю это поверхностно.Чувствую что в нем слишком много содержания.Кроме того GTS никогда не подвергалась этому,поэтому подробного объяснения не давал.Напишите отдельная запись в блоге для GTS.
Далее я, возможно, не буду писать сообщение в блоге о большом предложении springCloud, но узнаю о другом контенте в java. Кроме того, я на самом деле очень интересуюсь Python, и если у меня будет возможность, я напишу несколько постов в блоге о процессе изучения Python.
Быть по сему.