事务的特性(ACID)
| 特性 | 解释 |
|---|---|
| Atomic(原子性) | 事务边界内的指令要么全部成功要么全部失败 |
| Consistent(一致性) | 事务完成时，各记录的增减数量必须与预期一致 |
| Isolation(隔离性) | 并发事务相互隔离所做的修改互不影响 |
| Duration（持久性） | 事务完成之后，所做的修改是永久性的 |
Mysql里的事务处理过程
- 记录redo log(记录数据修改之后的数据)和undo log(记录数据修改之前的原始数据)文件，确保日志在磁盘上的持久化
- 更新数据记录
- 提交事务 ，redo log写入commit记录
X/OpenDTP事务模型
(X/Open Distributed Transaction Processing Reference Model)
- X/Open是一个组织机构，定义出了一套分布式事务标准， 定义了规范的API接口
- 定义了2PC（two -phase-commit）协议, 用来保证分布式事务的完整性
- J2EE 遵循了X/open DTP规范，设计并实现了java里面的分布式事务编程接口规范-JTA(java transaction API)
- XA是X/Open DTP定义的中间件与数据库之间的接口规范。 XA接口函数由数据库厂商提供
- X/OpenDTP 中的角色
- AP application //应用程序，访问数据库的代码
- RM resouces manager //资源管理器， 数据库
- TM transaction manager //事务管理器，事务协调者
2PC（two-phase-commit）协议
2PC原理
考虑到CAP理论模型中分布式系统固有的不可靠因素，2PC模型提出了两步走的理论
阶段一：提交事务请求（投票）
- TM向所有的AP发送事务内容，询问是否可以执行事务的提交操作，并等待各个AP的响应
- 执行事务。各个AP节点执行事务操作，将undo和redo信息记录到事务日志中，尽量把提交过程中比较消耗时间的准备和操作都提前完成，确保后续事务提交的成功率
- 各个AP向TM反馈事务询问的响应。各个AP成功执行了事务操作，然后反馈给TM “yes”的响应；如果AP没有成功执行事务，就反馈TM “no”的响应。
阶段二: 执行事务提交。TM向所有AP发送提交事务的命令。
2PC出错概率低的原因:
假设一个事务的提交过程总共需要30s， 其中prepare操作需要28（事务日志落地磁盘及各种io操作），而真正commit只需要2s那么，commit阶段发生错误的概率和prepare相比是2/28 (<10%) .只要第一个阶段成功，那么commit阶段出现失败的概率就非常小大大增加了分布式事务的成功概率
中断事务提交的处理模型
2PC中prepare阶段假如出现AP预提交失败的情况
2pc存在的问题
-
数据一致性问题。在二阶段提交的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接收到了commit请求。而这部分参与者接到commit请求之后就会执行commit操作，但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
-
同步阻塞问题。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有公共资源时，其他第三方节点访问公共资源不得不处于阻塞状态。
上面的话可能会让很多初学者一脸茫然，接下来我给大家深入的解释一下。在2PC协议的结构中，各个远程AP上的本地事务被TM联系成为了一个整体事务，如果某个AP上的事务执行结果没有送达TM，会直接导致其他AP也卡在该阶段无法执行最后阶段的commit。大家都知道事务在执行过程中不可避免的会给DB中的表或者行上各种各样的锁，事务commit以后就会自动解锁。问题是如果事务迟迟不能commit就意味着这些锁也迟迟不会释放，锁不释放其它别的代码的事务可能就无法获得锁，导致的后果就是别的事务陆续都被阻塞住了。更可怕的是，在2PC中所有的AP被TM连接成了一个整体，一个AP出问题，其它AP都无法commit，整个系统很有可能会出现雪崩效应。
-
二阶段无法解决的问题：协调者在发出commit消息之后宕机，而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者，这条事务的状态也是不确定的，没人知道事务是否被已经提交
-
单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去
3PC（three-phase-commit）协议
3pc协议原理
阶段一：canCommit
阶段二：preCommit
阶段三：doCommit
相对于2pc的改进点
- 增加了超时机制
- 第二阶段，如果协调者超时没有接收到参与者的反馈，则自动认为失败，发送abort命令
- 第三阶段，如果参与者超时没有接收到协调者的反馈，则自动认为成功开始提交事务（基于概率）
3pc的问题
相对于2PC，3PC主要解决了单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit。而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作。这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。
基于X/open DTP规范的分布式事务实现
- JOTM (java open transaction manager) //基于JTA规范实现的
- Atomikos(已开源)
参考了X/OpenDTP模型的支付宝的DTS架构
DTS
DTS(Distributed Transaction Service)框架是由支付宝在X/OpenDTP模型的基础上改进的一个设计，定义了类似2PC的标准两阶段接口，业务系统只需要实现对应的接口就可以使用DTS的事务功能。DTS最大的特点是放宽了数据库的强一致约束，保证了数据的最终一致性。
DTS具体流程
- TCC分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。
- TRYING、CONFIRMING、CANCELIING大致可以理解为SQL事务中的LOCK、COMMIT、ROLLBACK
- TRYING 阶段主要是对业务系统做检测及资源预留。
- CONFIRMING 阶段主要是对业务系统做确认提交。
- CANCELING 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
- TRYING阶段执行成功并开始执行CONFIRMING阶段时，默认CONFIRMING阶段是不会出错的。即：只要TRYING成功，CONFIRMING一定成功。
- 以上所有的操作需要满足幂等性，幂等性的实现方式可以是：
- 通过唯一键值做处理，即每次调用的时候传入唯一键值，通过唯一键值判断业务是否被操作，如果已被操作，则不再重复操作
- 通过状态机处理，给业务数据设置状态，通过业务状态判断是否需要重复执行
如何更通俗的理解TCC事务模型
- 问题: 支付系统接收到会员的支付请求后，需要扣减会员账户余额、增加会员积分增加商户账户余额。
- 现状: 会员系统、商户系统、积分系统是独立的三个子系统，无法通过传统的事务方式进行处理。
- TCC方案:
- TRYING阶段：我们需要做的就是会员资金账户的资金预留，即：冻结会员账户的金额（订单金额）
- CONFIRMING阶段：我们需要做的就是会员积分账户增加积分余额，商户账户增加账户余额
- CANCELING阶段：该阶段需要执行的就是解冻释放我们扣减的会员余额
开源的tcc框架
- tcc-transaction
- bytetcc
互联网的分布式事务解决方案
目前互联网领域有几种流行的分布式解决方案，但都没有像之前所说的XA事务一样形成X/OpenDTP那样的工业规范，而是仅仅在具体的行业里获得较多的认可
业务接口整合，避免分布式事务
没有分库分表的情况下可以考虑
最终一致性方案之ebay模式
eBay在2008年公布了一个BASE准则，提到一个分布式事务解决方案。eBay的方案其实是一个最终一致性方案，它主要采用消息队列来辅助实现事务控制流程，方案的核心是将需要分布式处理的任务通过消息队列的方式来异步执行，如果事务失败，则可以发起人工重试的纠正流程。人工重试被更多的应用于支付场景，通过对账系统对事后问题进行处理
-
问题: 某个用户产生了一笔交易，那么需要在交易表中增加记录，同时需要修改用户表的金额（余额）。
-
现状: 由于这两个表属于不同的远程服务，所以就会涉及到分布式事务与数据一致性的问题。
user(id, name, amt_sold, amt_bought) //用户表
transaction(xid, seller_id, buyer_id, amount) //交易表 -
方案:
-
先启动一个事务，更新交易表（transaction）后，并不直接更新user表，而是将要对user表进行的更新插入到消息队列中。
伪代码:
bool result=dao.update();
if(result){
mq.send();
} -
目标系统收到该消息以后，启动本地事务去对用户表的余额做调整
-
-
方案分析:
- 根据上面的伪代码的实现方案，可能出现几种情况
(1) 数据库操作成功，向MQ中投递消息也成功
(2) 操作数据库失败，不会向MQ中投递消息
(3) 操作数据库成功，但是向MQ中投递消息时失败，向外抛出异常。数据库操作回滚 - 对于上面c1几种情况，问题都不大。那么我们分析消费端的问题
(1) 消息出队列以后，消费者对应的业务操作要执行成功。如果执行失败，消息不能失效或者丢失。需要保证消息和业务操作一致
答：现在用的比较普遍的MQ都具有持久化消息的功能，如果消费者宕机或者消费失败，都可以执行重试机制
(2) 尽量避免消息重复消费，如果重复消费，也不能影响业务的执行结果
答: 如何避免消息的重复消费-
保证消费者的幂等性
—> 也就是说如果队列中的消息因为网络异常导致发送多次的情况下，仍然要保证消息被应用多次与应用一次产生的效果是一样的 -
避免消息重复消费
—> 通过消费日志表来记录消费状态；增加一个message_applied（msg_id）表，用来记录已经被成功应用的消息。
—> 在消费者执行更新操作之前，先检测该消息是否已经被消费过，消费完成后通过本地事务来更新这个“消费表状态”
-
- 根据上面的伪代码的实现方案，可能出现几种情况
保证最终一致性的模式
查询模式
类似支付宝的单笔交易查询接口
- 任何一个服务操作都提供一个查询接口，用来向外部输出操作执行的状态。服务操作的使用方可以通过接口得知服务操作执行的状态，然后根据不同状态做不同的处理操作
- 为了能够实现查询，每个服务操作都需要有唯一的流水号
- 在柔性事务中我们还可以使用衰减查询(1秒查一次 5秒查一次、10秒查一次)
补偿模式
有了查询模式，我们就能够得知操作所处的具体状态，如果整个操作处于不正常状态，我们需要修正操作中出现问题的子操作。
也许是要重新执行，或者取消已完成的操作。通过修复使得整个分布式系统达到最终一致。这个过程就是补偿模式
根据发起形式，补偿模式又分为如下3种:
- 自动恢复：通过对发生失败操作的接口自动重试或者回滚已经完成的操作
- 通知运营：如果程序无法自动完成恢复，则通过运营人员手动进行补偿
- 通知技术：通过监控或者告警通知到技术人员，通过技术手段进行修复
最大努力通知型
一种特殊的补偿或者重试机制
类似支付宝的接口回调。处理回调解密参数，然后调用更新交易状态相关的服务，将订单更新为付款成功。
同时，只有当我们向支付宝回调url中输出了success字样或者标识业务处理成功相应状态码时，支付宝才会停止回调请求。否则，支付宝会每间隔一段时间后，再向客户方发起回调请求，直到输出成功标识为止。
点评
上面这些方式是非常经典的实现，尽可能避免分布式事务，实现“最终一致性”
各大知名的电商平台和互联网公司，几乎都是采用类似的设计思路来实现“最终一致性”的。
这种方式适合的业务场景广泛，而且比较可靠。不过这种方式技术实现的难度比较大
扫一扫
3013
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
