技术外包网站,建个普通网站,wordpress不安装先写前端,顶尖手机网站建设最终一致性分布式事务概述 强一致性分布式事务解决方案要求参与事务的各个节点的数据时刻保持一致#xff0c;查询任意节点的数据都能得到最新的数据结果#xff0c;这就导致在分布式场景#xff0c;尤其是高并发场景下#xff0c;系统的性能受到了影响。而最终一致性分布式…最终一致性分布式事务概述 强一致性分布式事务解决方案要求参与事务的各个节点的数据时刻保持一致查询任意节点的数据都能得到最新的数据结果这就导致在分布式场景尤其是高并发场景下系统的性能受到了影响。而最终一致性分布式事务解决方案并不要求参与事务的各个节点数据时刻保持一致运行其存在中间状态只要一段时间后能够达到数据的最终一致状态即可在电商场景中使用比较多
典型方案
业界基于Base理论提出的最终一致性分布式事务解决方案有
TCC解决方案可靠消息最终一致性解决方案最大努力通知型解决方案
优缺点
最终一致性分布式事务解决方案的优点
性能比较高这是因为最终一致性分布式事务解决方案不要求数据时刻保持一致不会因为长时间持有事务占用的资源而过度消耗过多的性能具备可用性适合高并发场景
最终一致性分布式事务解决方案的缺点
因为数据存在短暂的不一致所以在某个时刻查询出的数据状态可能会不一致对于事务一致性要求特别高的场景不适用
服务模式
可查询操作需要服务操作具有可标识性主要体现在服务的操作具有全局唯一的标识可以是业务的单据编码如订单号也可以是系统分配的操作流水号另外在可查询的服务模式中也要有完整的操作时间信息幂等性操作指对同一个方法只要参数相同无论执行多少次都与第一次执行时产生的影响相同为了保证数据的最终一致性系统会提供很多次重试操作这个时候就需要接口实现幂等性操作TCC操作这个模式下包括了3个阶段Try阶段尝试业务执行、Confirm阶段确认业务阶段和cancel阶段取消业务执行
Try阶段
完成所有业务的一致性检查预留必要的业务资源并需要与其他操作隔离
Confirm阶段
此阶段会真正执行业务操作因为在Try阶段完成了业务的一致性检查所有此阶段不会做任务业务检查只用Try阶段预留的业务资源进行操作此阶段的操作需要满足幂等性
Cancel阶段
释放Try阶段预留的业务资源此阶段的操作需要满足幂等性
可补偿操作某些数据处于不正常的状态需要通过某种方式进行业务补偿使数据能够达到最终一致性这种因数据不正常而进行的补偿操作就是可补偿操作服务模式
TCC解决方案 TCC是一种典型的解决分布式事务问题的方案主要解决跨服务调用场景下得分布式事务问题广泛应用于分布式事务场景
适用场景 用于具有强隔离性严格一致性要的业务场景也适用于执行时间比较短的业务对于电商场景中下得减库存等业务如果使用TCC分布式事务则会经历Try、Confirm、Cancel三个阶段
需要实现的服务模式 在TCC分布式事务解决方案中需要实现的服务模式包括TCC操作幂等操作、可补偿操作、可查询操作。 例如实现TCC分布式事务方案时需要实现Try、Confirm、Cancel三个阶段的业务逻辑这就是TCC操作在TCC操作的每个阶段的方法都需要实现幂等性这就是幂等操作如果在执行分布式事务过程中业务服务出现了异常情况则需要支持重试阶段以达到事务补偿的目的这就是可补偿操作另外业务服务需要提供可以查询自身内部事务状态的接口以供其他服务调用这就是可查询操作 分支事务失败的情况 本质上讲TCC是一种应用层实现的二阶段提交协议TCC方案的执行流程如下
Try阶段不会执行任务业务逻辑仅做业务的一致性检查和预留相应的资源这些资源能够和其他操作保持隔离confirm阶段当Try阶段所有分支事务执行成后开始执行Confirm阶段通常情况下采用TCC解决分布式事务时会任务Confirm阶段是不会出错的也就是说只要Try阶段的操作执行成功了Confirm阶段就一定会执行成功如果Confirm阶段出错了就需要引入重试机制或者人工处理对出错的事务进行干预Cancel阶段在业务执行异常或出现错误的情况下需要回滚事务的操作执行分支事务的取消操作并且释放Try阶段预留的资源通常情况下采用TCC方法解决分布式事务时同样会认为Cacnel阶段也是一定会执行成功的如果出现错误就需要引入重试机制或者人工处理对出错的事务进行干预
方案的优缺点
TCC方案的优点
在应用层实现具体的逻辑锁定资源的粒度变小不会锁定所有资源提升了系统的性能Confirm阶段和Cancel阶段的方法具备幂等性能够保证分布式事务执行完毕后数据的一致性TCC分布式解决方案有主业务发起整个事务无论主业务还是分支事务所在的业务都能部署为集群模式从而解决了XA规范的单点故障问题
TCC方案的缺点
代码需要耦合到业务中每个参与分布式事务的业务方法都要拆成Try、Confirm、Cancel三个阶段的方法提高了开发的成本
需要注意的问题 使用TCC方案解决分布式事务问题时需要注意空回滚、幂等和悬挂问题
空回滚问题
原因出现空回滚的原因是一个分支事务所在的服务器宕机或者网络发生异常此分支事务调用失败此时并未执行此分支的Try阶段的方法当服务器或者网络恢复后TCC分布式事务执行回滚操作会调用分支事务的Cancel阶段的方法如果Cancel阶段的方法不能处理这种情况就会出现空回滚的问题解决方案识别是否出现空回滚操作的方法是判断是否执行了Try阶段的方法如果执行了Try阶段的方法就没有空回滚否则则出现空回滚
幂等问题
原因由于服务器宕机、应用崩溃或者网络异常等原因可能会出现方法调用超时的情况为了保证方法的正常执行往往会在TCC方案中加入超时重试机制因为超时重试有可能导致数据的不一致问题所以需要保证分支事务的执行以及TCC方案的Confirm阶段和Cancel阶段具备幂等性解决方案在分支事务记录表中增加事务的执行状态每次执行分支事务以及Confirm阶段和Cancel阶段的方法时都查询次事务的执行状态以此判断事务的幂等性
悬挂问题
原因TCC分布式事务中通过RPC调用分支事务Try阶段的方法时会先注册分支事务在执行RPC调用。如果此时发生服务器宕机应用崩溃或者网络异常等情况RPC调用就会超时如果RPC调用超时事务管理器会通知对于的资源管理器回滚事务可能资源管理器回滚完事务后RPC请求达到了参与分支事务所在的业务方法因为此时事务以及回滚所以在Try阶段预留的资源就无法释放了这种情况下就成为悬挂解决方案如果执行了Confirm阶段或者Cancel阶段的方法则Try阶段的方法就不能再执行了具体方案是在执行Try阶段的方法时判断分支记录表中是否存在同一全局事务下Confirm阶段或者Cancel阶段的事务记录如果存在则不执行Try阶段的方法
