今朝云计较、大数据、互联网规模的大部门系统都回收了SOA、微处事化的架构。一个涉及端到端全链路的业务操纵往往会由多个处事和数据库实例配合完成。因此，在一致性要求较高的业务场景中，如何担保多个处事之间RPC挪用后的数据一致将成为要害点。

一、漫衍式系统/SOA/微处事架构的特点：

在大型漫衍式系统中要同时可以或许满意，漫衍式一致性(Consistency)、可用性(Availability)和分区容忍性(Partitiontolerance)，是不存在的。在大大都环境下只能满意个中的2项，而实现系统的最终一致性(Base理论)。

( 1 ) CAP特点：

a.一致性(Consistency):( 同样数据在漫衍式系统的各个节点上都是一致的)

b.可用性(Availability):( 所有在漫衍式系统活泼的节点都可以或许处理惩罚操纵且能响应查询)

c.分区容忍性(Partition Tolerance) :(假如呈现了网络妨碍、一部门节点无法通信，可是系统仍可以或许事情)

( 2 ) ACID特点：

a.原子性(Atomicity)

一个事务(transaction)中的所有操纵，要么全部完成，要么全部不完成，不会竣事在中间某个环节。事务在执行进程中产生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

b.一致性(Consistency)

事务的一致性指的是在一个事务执行之前和执行之后数据库都必需处于一致性状态。假如事务乐成地完成，那么系统中所有变革将正确地应用，系统处于有效状态。假如在事务中呈现错误，那么系统中的所有变革将自动地回滚，系统返回到原始状态。

c.断绝性(Isolation)

指的是在并发情况中，当差异的事务同时哄骗沟通的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必需与任何其他并发事务所做的修改断绝。事务查察数据更新时，软件开发，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查察到中间状态的数据。

d.耐久性(Durability)

指的是只要事务乐成竣事，它对数据库所做的更新就必需永久生存下来。纵然产生系统瓦解，从头启动数据库系统后，数据库还能规复到事务乐成竣事时的状态。

二、漫衍式事务的根基先容

漫衍式事务处事（Distributed Transaction Service，DTS）是一种漫衍式事务框架，用来确保在大局限漫衍式/微处事情况下端到端业务操纵的最终一致性。

由CAP定理可知，任何大型的漫衍式系统/微处事在一致性、可用性和分区容忍这三点上只能担保个中的两点。由于在漫衍式系统中常常产生丢包、网络妨碍，分区容忍性是必需要满意的，同时为了分身高可用性，绝大部门系统都将强一致性需求转化成最终一致性的需求，并通过幂等机制担保了数据的最终一致性。

三、常用的漫衍式技能先容

( 1 ) 当地动静表（经典的ebay模式）

该方案的焦点思想在于漫衍式系统在处理惩罚任务时通过动静日志的方法来异步执行。动静日志可以存储至当地文本、数据库或动静行列，然后再通过业务法则按时任务某人工自动重试。以在线付出系统的跨行转账为例：

第一步，伪代码如下，对用户id为A的账户扣款1000元，软件开发，通过当地事务将事务动静(包罗当地事务id、付出账户、收款账户、金额、状态等)插入至动静表：

Begin transaction

         update user_account set amount = amount - 1000 where userId = 'A'

         insert into trans_message(xid,payAccount,recAccount,amount,status) values(uuid(),'A','B',1000,1);

end transaction

commit;

第二步，通知对方用户id为B，增加1000元，凡是通过动静MQ的方法发送异步动静，对方订阅并监听动静后自动触发转账的操纵；这里为了担保幂等性，防备触发反复的转账操纵，需要在执行转账操纵方新增一个trans_recv_log表用来做幂等，在第二阶段收到动静后，通过判定trans_recv_log表来检测相关记录是否被执行，假如未被执行则会对B账户余额执行加1000元的操纵，并会将该记录增加至trans_recv_log,事件竣事后通过回调更新trans_message的状态值。

( 2 ) 动静中间件

a.非事务动静中间件

这里仍然以上面跨行转账为例，我们很难担保在扣款完成之后对MQ投递动静的操纵就必然能乐成。这样一致性好像很难担保。以下伪代码说明白动静投递的异常：

try{

    boolean result = dao.update(model);//更新数据库失败抛出异常

    if(result){

                      mq.send(model);//假如MQ超时可能吸收方处理惩罚失败,抛出异常

    }

}catch(Exception ex){

                          rollback();//假如异常回滚

}