seata xid是什么_分布式事务原理分析及SpringBoot整合RabbitMQ实现可靠事件,TCC补偿事务模型及什么是接口幂等性...

分布式事务

在单数据库系统中，实现数据的一致性，通过数据库的事务来处理比较简单。在微服务或分布式系统中，各个独立的服务都会有自己的数据库，而不是在同一个数据库中，所以当一组事务(如商品交易中，商品的库存、用户的账户资金和交易记录等)的处理是分布在不同数据库中的，分布式事务就是为了解决在多个数据库节点中保证这些数据的一致性。
分布式事务里有个BASE理论，在分布式数据库中，存在强一致性和弱一致性。

强一致性的好处是，对于开发者来说比较友好，数据始终可以读取到最新值，但这种方式需要复杂的协议，并且需要牺牲很多的性能。它的理论参考:XA理论，理解2PC(二阶段提交)，3PC(三阶段提交),JAVA中对XA理论的实现标准是JTA(Java Transaction API)，本篇偏向弱一致处理方式，不做过多描述强一致性的分布式事务讲解。
弱一致性，对于开发者来说相对没有那么友好，无法保证读取的值是最新的，但是不需要引入复杂的协议，也不需要牺牲很多的性能。
弱一致性是当今企业采用的主流方案，它并不能保证所有数据的实时一致性，所以有时候实时读取数据是不可信的。它只是在正常的流程中，加入了提供修复数据的可能性，从而减少数据不一致的可能性，大大降低数据不一致的可能性。

什么时候使用分布式事务

对于像电商中用户隐私信息、商品信息、交易记录以及资金等数据，这些具备价值的核心数据，关系到用户隐私和财产的内容，应该考虑使用分布式事务来保证一致性。
但对于用户评价、自身装饰和其他一些非重要的个性化信息，可以采用非事务的处理。因为一个正常的系统出现不一致的情况是小概率事件，而非大概率事件，对于一些小概率的数据丢失，一般来说是允许的。之所以这样选择，主要基于两点，一个是开发者的开发难度；另一个是用户的体验，过多的分布式事务会造成性能的不断丢失

弱一致性分布式事务解决方案有如下几种:

• 状态表

• RabbitMQ可靠事件

• 最大尝试

• TCC模式

※当然除了上述这些，也可以借助阿里的分布式中间件seata,它包含了多种包括强一致性、弱一致性的分布式事务解决方案。

幂等性

在分布式事务中，各个访问操作的接口，都需要保证幂等性。
所谓幂等性，是指在HTTP协议中，一次和多次请求某一个资源，对于资源本身应该具有同样的结果，也就是其执行任意多次时，对资源本身所产生的影响，与执行一次时的相同。实现方式有以下几种:

• 唯一索引 -- 防止新增脏数据

• token机制 -- 防止页面重复提交

• 悲观锁 -- 获取数据的时候加锁(锁表或锁行)

• 乐观锁 -- 基于版本号version实现, 在更新数据那一刻校验数据

• 分布式锁 -- redis(jedis、redisson)或zookeeper实现

• 状态机 -- 状态变更, 更新数据时判断状态

※说明:如何实现接口的幂等性,可以分篇在接口的幂等性文章里解说。

状态表实现分布式事务

这里拿电商的商品交易为例，讲述下思路:

1. 需要商品数据库:商品表、商品交易明细表；资金数据库:用户账户表、账户交易明细表

2. 主要流程包括:
   商品表减商品库存、
   商品交易明细表中添加新的交易记录、
   用户账户表中扣减用户账户表的资金、
   资金交易明细表中记录账户交易明细表

3. 需要准备一个状态表,用redis的Hset数据类型比较合适

4. 这里假设相关的明细记录表中，有4个状态:
   1--准备交易,
   2--交易成功,
   3--被冲正,
   4--冲正记录

交易流程

※流程说明
在商品服务中,商品减库存后，记录商品交易明细，如果没有异常，就将商品交易记录的状态位设置为“1—准备提交”，并且记录在Redis的状态表中。
商品服务通过RESTFUL调用资金服务，如果成功，就将账户交易明细表的记录的状态位设置为“1—准备提交”，并且记录在Redis的状态表中。
最后，读取Redis相关的所有状态位，确定是否所有的操作都为“1—准备提交”状态，如果是，则更新产品服务的记录状态为“2—提交成功”，然后发起资金服务调用，将对应的记录(可通过业务流水号关联)的状态也更新为“2—提交成功”，这样就完成了整个交易。
如果不全部为“1—准备提交”状态，则发起各库的冲正交易，冲掉原有的记录，并且归还商品库存和账户金额。发起冲正交易,把原明细记录状态更新为3--被冲正,并往明细表中添加对应的新记录,状态为4--冲正记录

Rab