分布式事务——理论篇
数据库事务的四个原则ACID 原子性，一致性，隔离性，持久性微服务的软件开发，数据库相互分离，在调用多个服务的过程中，涉及到多个数据库，数据库本身事务无法满足多个数据源之间的ACID。因此引出目前业界比较难处理的分布式事务问题。
分布式事务
原则CAP
一致性，可用性，分区容错性。
在分布式事务处理过程，不可能同时满足上述三者，只能同时满足两者，后续通过其他方案来弥补，到达最终一致性。
理论BASE
通过控制软状态的变化，到达最终一致性效果
相关协议
XA 两段式协议
XA有协调者，负责通知按链路执行通知所有参与者准备执行，待收到所有参与者都可以执行成功消息，通知参与者正式提交。因为XA协议是链路顺序执行，很容易因为某个端点超时处理，造成“同步阻塞”，影响之后链路的正常执行，而造成整个事务失败。
基于两段式产生的三段式协议
对于二阶段中同步阻塞问题优化，引入超时机制，解决阻塞问题。三阶段分为预备，准备，终止事务在预备，准备阶段任何参与者回复执行异常或者等待超时，则直接终止事务。但是等待超时，其他事务回滚，超时者本身却执行成功，也存在造成数据不一致性的情况。
具体的实现方案
1、最终一致性（可靠消息服务）
方案特点
可独立部署，独立伸缩（扩展性）
兼容所有实现JMS标准的MQ中间件
能降低业务系统与消息系统间的耦合性
可在数据可靠的前提下确保最终一致性
利用可靠消息服务的时候，注意处理逻辑过程的幂等性，防止因为网络波动，重复请求，分布式消息消费，用户重复操作，未关闭的重试机制等原因造成的逻辑重复处理。
在幂等性的处理方案分为以下几种
1)、分布式锁
2)、数据库唯一索引
3)、状态流转——状态机控制
4)、乐观锁，多版本控制
5)、select + insert （先查后处理，此方式对于高并发场景不建议使用）
2、TCC （阿里框架）
本质上是二阶段提交，实现最终一致性。
try confirm cancel，在try预处理过程，通过执行结果，选择confirm或者cancel二者之一。
方案特点
不与具体的服务框架耦合
位于业务服务层，而非资源层
灵活选择业务资源的锁定粒度
适用于强隔离性，严格一致性要求的业务场景
适用于执行时间较短的业务
3、最大努力通知型方案
适用于跨平台,尽量去处理通知，即便失败，影响不大的场景
在实际的业务场景中一般这几种情况配合使用，能满足具体的业务场景。
红太狼
小灰灰
布满荆棘的人生
亦凉
「爱情、让人受尽委屈。」
还没有评论，来说两句吧...