Read a text distributed transaction

Local Services

Transaction Transaction consists of a set of SQL, it has a four ACID properties

ACID

Atomicity atom of a set of SQL make up the transaction, either all take effect, either whole does not take effect, the situation will not be part of the entry into force of

Consistency consistency of the database after the transaction operations transition from one state to another. It can be said is the description from the atomic behavior, but consistency is the description from the results

Isolation isolation data object transaction data object with respect to the operation of other transaction operations isolated from each other, independently of each other

durability persistence transaction is committed, the result is permanent, even if downtime occurs (non-disk damage)

Transaction implementation

For the MySQL database (InnoDB storage engine), isolation is achieved through a transaction isolation between different granularity of locking mechanism; atomicity, consistency and durability redo logs and undo log rolling log ensured through the redo log .

redo log when the database changes made to the data, the need to read data pages from disk buffer pool, and then make changes in the buffer pool, then this time the data page buffer pool is inconsistent with the data on the page content on the disk, He said buffer pool data page is dirty page dirty, if abnormal DB service restart happened this time, these data have not in memory, and not synchronized to a disk file (note, synchronized to the disk file is random IO), that is, will be data loss occurs, if at this time, can have a file, when the end of the data page change buffer pool in, the corresponding change log record to the file (note that logging is a sequential IO), then when the DB services when the situation crash occurred, DB recovery, but also can record the contents of this file, reapply the file to disk, the data is consistent.

undo log undo log for storing modified data value before, if abnormal modification can use the undo log to achieve rollback operation, to ensure transactional consistency. In addition InnoDB MVCC transaction log undo feature is also based implementation. undo log into insert undo log (log insert statement produced after the transaction commits delete) and update undo log (log delete and update statements generated, deleted due to the undo log may provide MVVC mechanism to use, so the transaction can not be submitted ).

Issues into

CAP theory

CAP principle, also known as CAP theorem means that in a distributed system, consistency (Consistency), availability (Availability), partition fault tolerance (Partition tolerance). CAP principle means that a maximum of only two points while achieving these three elements, the three can not be taken into account. However, due to the distributed systems, fault tolerance partition must exist, we can only compromise the consistency and availability.

Traditional the DBMS, such as MySQL fact CA combination, in a master-slave architecture, in the case of separate read and write, the expense of a certain consistency (from primary delay).

Base Theory

Basic available base available distributed system in case of failure, allowing the loss of part of the available functions, ensure that the core functions are available

soft state soft state to allow an intermediate state of the system, this does not affect system availability status

eventually consistent final consistency intermediate state of the system after a short time to reach a consistent state

How to solve

For example scenario

Consider a business scenario, the system calls the system B A refund service refund, the refund system A change internal state, then call the system C SMS service to inform users.

In such a scenario, the network since there must be unreliable, there is the issue of consistency between A, B, C three systems.

Local Table

For the scenario described above, the two tables design refund record table and the SMS log table and the corresponding compensation Job

The specific implementation process:

1. New refunds record sheet processing status
2. Call system B refunds the refund
3. Update refund record status for the corresponding status (success / failure)
4. If the refund is successful, the new SMS record, the record state is to be sent
5. C system calls SMS service, send a text message
6. Update records as sent SMS

Refund compensation Job Search record refund processing records in the table, call the refund system B service successfully processed a refund:

1. SMS new record, the record state is to be sent
2. C system calls SMS service, send a text message
3. Update records as sent SMS

SMS notification compensation Job records check SMS records to be sent, the system calls the C SMS service

1. C system calls SMS service, send a text message
2. Update records as sent SMS

note:

• System B and System C uuid need to support the transfer of powers such as caller
• System A, B, C will be short-lived inconsistent, but eventually agreed

Transaction message

Think of it as two-phase commit messages implemented to ensure that the final consistency in a distributed system. Transactional messages may be performed to ensure that the transmission and local transaction message may be performed atomically.

However, due to the nature of the transaction messages asynchronously, the caller can not get the treatment results of a consumer for the other party does not care about the result of the return / the other party is responsible for ensuring the success of treatment

For the scenario described above, two additional way to solve transaction message consistency, system A interacts with the system by means of the system B and C sends a transaction message

The specific implementation process:

Transmitting the new message transaction refunds refund record, status: Commit process refund transaction message

MQ provides transaction callback refund callback query

• There refund in the recording process and not Commit
• Others Rollback

Send SMS callback inquiry

• There refund and successful record of the Commit
• Others Rollback

Refund sync Job Search record records in the table refund processing, refund synchronization status query interface calls refund system B successfully processed:

• Transaction message sent refunds
• Update refund record status
• Commit SMS transaction message

Theory

Two-phase commit protocol

阻塞问题，参与者将协议消息发送给协调器后，它将阻塞直到收到提交或回滚，只能依赖协调者的超时机制

协调者单点问题，如果协调者出现故障，则某些参与者将一直无法收到提交或回滚的消息。

DTP Model

X / Open分布式事务处理DTP（Distributed Transaction Processing）模型是一种软件体系架构，已经成为事实上的事务模型组件的行为标准。它允许多个应用程序共享由多个资源管理器提供的资源，并允许其工作被协调为全局事务。

ApplicationProgram(AP) 应用程序定义了事务边界并指定构成事务的操作

ResourceManager(RM) 资源管理器用来管理我们需要访问的共享资源，我们可以将它理解为关系数据库、文件存储系统、消息队列、打印机等

TransactionManagger(TM) 事务管理器是一个独立的组件，他为事务分配标识符并监视事务的执行情况，负责事务完成和故障恢复

CommunicationResourceManager(CRM) 通信资源管理器控制一个或多个 TM domain 之间分布式应用的通信。

XA Specification

XA规范是X/Open关于分布式事务处理 (DTP)的规范。规范描述了全局的事务管理器与局部的资源管理器之间的接口。XA规范的目的是允许多个资源（如数据库，应用服务器，消息队列，等等）在同一事务中访问，这样可以使ACID属性跨越应用程序而保持有效。XA使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。

XA规范描述了资源管理器要支持事务性访问所必需做的事情。

TCC

saga

在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

Saga模式的优势是：

• 一阶段提交本地数据库事务，无锁，高性能；
• 参与者可以采用事务驱动异步执行，高吞吐；
• 补偿服务即正向服务的“反向”，易于理解，易于实现；

缺点：

• Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。

开源项目

seata

Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。支持AT、TCC、SAGA、XA四种模式，对微服务框架支持友好。

如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。

TC - 事务协调者 维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM - 事务管理器 定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM - 资源管理器 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

在 Seata 中，分布式事务的执行流程：

• TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
• 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
• TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
• TC 汇总事务信息，决定分布式事务是提交还是回滚；
• TC 通知所有 RM 提交/回滚 资源，事务二阶段结束；

AT模式

AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。 二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

TCC模式

一个分布式的全局事务，整体是 两阶段提交 的模型。全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：

一阶段 prepare 行为 二阶段 commit 或 rollback 行为

TCC 模式，不依赖于底层数据资源的事务支持：

一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。 二阶段 commit 行为：调用 自定义 的 commit 逻辑。 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

Saga模式

目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：

1. 通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
2. 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
3. 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚 （异常发生时是否进行补偿也可由用户自定义决定）
4. You can achieve service orchestration needs to support individual choice, concurrency, sub-processes, the conversion parameters, parameter mapping, service execution state judge, abnormal capture and other functions

The state machine engine principle

• FIG state is performed first stateA, then execute stateB, then execute stateC
• Performing the "status" is an event-driven model, after stateA executed, is generated into the EventQueue routing messages, event messages from the consumer end of the EventQueue taken, performs stateB
• In the entire state machine starts to open calls Seata Server distributed transaction, and production xid, then record "state machine instance" start event to the local database
• When performing a "status" calls Seata Server registered branch affairs and production branchId, and then record the "state of the instance" started the event to the local database
• When a "state" will record "status instance," the implementation of the end of the event to the local database, and then call the state Seata Server reporting branch transactions executed after completion
• When the whole state machine execution is complete, the record "state machine instance" execution completion event to the local database, and then call Seata Server to commit or roll back the distributed transaction

Author: VectorJin
link: https: //juejin.im/post/5e066c9ff265da33b0718f89