分布式事务理论
tcc/seata/lcn
商业:dts/gts
分布式事务在聊什么？
数据的一致性问题
数据库事务的特性
ACID
跨数据库的数据一致性
X/OpenDTP事务模型（强一致性）
1.RM 表示资源管理器
2.TM 表示事务管理器
2pc协议
1.写事务日志
2.提交回滚
CAP/BASE
1.CAP
C：consistency(强一致性)
A:avaiablity（可用性）
P: Partion Tolerance 分区容错
如果出现网络分区，还要保证系统的可用性
raft 脑裂
eureka自我保护
CP/AP（场景）
BASE理论
弱一致性模型(最终一致性)
- BA:基本可用，容错性.
- soft ware:柔性状态，允许数据状态的暂时不一致性
- E:最终一致性
数据的一致性:实时一致，还是最终一致；
三态
- 成功
- 失败
- 超时
zookeeper
过半提交，损失了一致性，保证了可用性。AP
事务的解决方案
最终一致性
- 采用消息队列来辅助控制事务的流程
本地的日志表
如何保证幂等性
- 衰减重试
- 消息重发
- dubbo–failover 默认重试
幂等的实现
判断重复请求。不允许重复
- 状态机
- 生成一个token
- 数据库的唯一约束（唯一索引）(MD5)
- redis setNX
状态机
数据的状态来驱动业务的发展。
TCC事务
2pc
把事务的处理逻辑放到了业务上，
下单(1.资金的扣减，2.创建订单)
- try：对于资源的准备
（冻结资金） - commit：数据的提交
（直接提交，扣减资金，调用会计服务，增加某个分录的余额） - cancel：数据的回滚
（回滚用户余额）
MQ 事务性消息
标签：事务,seata,可用性,回滚,一致性,数据,分布式 来源： https://blog.csdn.net/weixin_42022924/article/details/112687448
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。