分布式事务原理解析

1. 分布式事务原理解析

1.1. TCC分布式事务

了解过TCC分布式事务的都知道它有三个阶段:try,confirm,cancel,但很多文章就只有原理图,和对原理图的解释,看一遍也留不下印象,这里用实际场景举个例子,说明TCC分布式事务原理

  • try阶段:假设我们又订单系统,它需要调用库存和积分系统,try阶段我们进行的是预处理,比如下单1个商品,在try操作中,我们在库存表设置个冻结字段,表示冻结1个商品,商品的存量先不扣除,而积分表同样添加个预增加积分字段,添加个预积分比如10
  • confirm阶段:我们为什么要经历try阶段?,为了尽可能的保证各个系统都是正常工作的,数据库,服务都没有挂掉,资源没有不足,则可以最大程度上保证confirm阶段能正确执行,confirm阶段也就是正式的扣除库存和增加积分
  • cancel阶段:若try阶段执行错误,则会对前面已经执行的try阶段的系统执行cancel操作,也就是反向SQL回滚,冻结的商品-1,预积分-10。到这里有没有疑问?我首先想到的是若confirm或cancel操作再执行失败怎么办?这里就要由TCC分布式事务框架保证了,它会记录事务活动日志,再confirm或cancel失败后不断尝试调用confirm和cancel的逻辑,所以这里需要开发者自己保证,你的SQL是正确的

TCC分布式框架推荐:ByteTCC,tcc-transaction,himly

1.2. 最终一致性分布式事务

1.2.1. 原理

最终一致性方案一般都是有消息中间件来完成的,核心流程如上图所示

  • 假设上游服务为服务A,可靠消息服务为服务B,下游服务为服务C,首选A发送请求给B表示我将要发消息了,你准备下,然后B记录下待确认的数据;
  • A服务正式走完本地数据库逻辑,在发送B确认消息,说我执行完了,你可以确认了,然后B就更新消息的状态为已发送,并把消息发送给MQ
  • 此时服务C订阅了MQ,接收到B通过MQ发送过来的消息,并执行本地数据库操作,在执行完毕后手动ack确认消费完毕,这就走完了全部流程

1.2.2. 问题

下面来考虑这中间会有什么问题了,为什么这样能保证分布式事务的最终一致性?

  • 首先是服务A调用B过程中若不成功或者服务B若没保存待确认消息,那就直接返回的就是失败,还没有操作数据库,所以没有影响
  • A操作数据库和发送确认消息,我们需要放在同一个本地事务中,确保同时成功或失败,这样成功了当然没问题,失败了呢?因为B服务的数据库已经存在待确认消息,可以在B服务开条线程定时判断待确认消息,若发现待确认消息很久没被确认,则主动向A发起请求,判断该操作是否成功了?成功则改状态为已确认,继续执行,失败则删掉该记录
  • B到MQ的过程,若是失败了,MQ挂了之类的,我们可以在B服务后台起个线程,定时判断已确认的消息,在一定时间后是否变成已发送,没有发送的再主动发送
  • 这样后就只剩MQ到C服务了,MQ有重试机制,所以只要业务逻辑没问题,就可以保证最终一致性(这个过程中需要保证MQ到C服务,接口方法需要幂等性)
  • 上述流程需要特别注意的一个点就是MQ,我们需要保证MQ的高可用,否则一旦全部MQ宕机,依赖MQ的分布式事务都不能完成

1.2.3. MQ挂了怎么办

越大的公司,考虑的就越多,任何组件都可能挂掉,MQ如果就一个集群,就要考虑这个集群压力过大到爆掉了怎么办?资金雄厚并发压力大的公司可以直接搞再搞一套备用的,当MQ请求不通后,立即自动切换到备用MQ集群,当然这肯定会造成资源的浪费,毕竟要再搞一套MQ不运行一直放那里,这里再给出一套参考方案(如果你们有redis集群的话)

  • redis有种队列的数据结构,它是可以用来临时充当消息队列的,所以这里要讨论的是,如果用redis当备用方案需要考虑什么问题?
  • 通知机制:当MQ挂了,我们需要将所有用到MQ事务的系统都切换到备用redis方案,所以我们要有个通知机制,本来吗这个类似广播模式的通知应该是MQ完成的,但没了MQ,我们要有其它方案,比如zookeeper的watch机制,zk有监听机制可以通知监听它节点的系统,打开降级开关,达到通知其它系统的效果
  • 消息读取热点问题:我们把消息放到redis的队列会有个对应的key,我们不能把所有消息都放一个key的value中,这样会导致这个value数据量过大;所以这里给出方案:划分上百个队列,对消息hash后放入这些队列,这样尽可能的把消息分散到不同的key
  • 故障的恢复:当我们把MQ恢复过来时,我们也要通知系统,该切换回来了,这个该怎么做呢?可以开启一个线程,每隔一段时间尝试给MQ投递一个消息查看是否恢复,若恢复了,就可以再次通过zookeeper来关闭降级开关

参考:
拜托,面试请不要再问我TCC分布式事务的实现原理!
最终一致性分布式事务如何保障实际生产中99.99%高可用?

原文地址:https://www.cnblogs.com/sky-chen/p/11359634.html

时间: 2024-08-29 01:21:37

分布式事务原理解析的相关文章

MQ关于实现最终一致性分布式事务原理解析

本文讲述阿里云官方文档中关于通过MQ实现分布式事务最终一致性原理 概念介绍 事务消息:消息队列 MQ 提供类似 X/Open XA 的分布式事务功能,通过消息队列 MQ 事务消息能达到分布式事务的最终一致. 半事务消息:暂不能投递的消息,发送方已经成功地将消息发送到了消息队列 MQ 服务端,但是服务端未收到生产者对该消息的二次确认,此时该消息被标记成“暂不能投递”状态,处于该种状态下的消息即半事务消息. 消息回查:由于网络闪断.生产者应用重启等原因,导致某条事务消息的二次确认丢失,消息队列 MQ

[java][db]JAVA分布式事务原理及应用

JTA(Java Transaction API)允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据.JDBC驱动程序的JTA支持极大地增强了数据访问能力. 本文的目的是要提供一个关于的Java事务处理API(JTA)的高级的概述,以及与分布式事务相关的内容.一个事务处理定义了一个工作逻辑单元,要么彻底成功要么不产生任何结果. 一个分布式事务处理只是一个在两个或更多网络资源上访问和更新数据的事务处理,因此它在那些资源之间必然是等价的.在本文中,我们主要关心的是如何处理

JAVA分布式事务原理及应用(转)

JTA(Java Transaction API)允许应用程序执行分布式事务处理--在两个或多个网络计算机资源上访问并且更新数据.JDBC驱动程序的JTA支持极大地增强了数据访问能力. 本文的目的是要提供一个关于的Java事务处理API(JTA)的高级的概述,以及与分布式事务相关的内容.一个事务处理定义了一个工作逻辑单元,要么彻底成功要么不产生任何结果. 一个分布式事务处理只是一个在两个或更多网络资源上访问和更新数据的事务处理,因此它在那些资源之间必然是等价的.在本文中,我们主要关心的是如何处理

分布式事务 原理及使用范例一则

摘要:在软件开发和数据库操作中,经常出现需要共同进退的情况,要么一起成功,要么一起失败. 假设案例:A向B转账3000元rmb. update Account set Amount=Amount-3000 where name='a' update account set Amount=Amount+3000 where name='b' 场景:假设在第1行代码执行成功,第2行代码还未执行的情况下.未继续执行. 结果:A的钱没了!B没收到钱! 此时推荐使用分布式事务来解决这类问题. 解决方案 应

tcc分布式事务框架解析

前言碎语 楼主之前推荐过2pc的分布式事务框架LCN.今天来详细聊聊TCC事务协议. 2pc实现:https://github.com/codingapi/tx-lcn tcc实现:https://github.com/yu199195/hmily 首先我们了解下什么是tcc,如下图 tcc分布式事务协议控制整体业务事务分为三个阶段. try:执行业务逻辑 confirm:确定业务逻辑执行无误后,确定业务逻辑执行完成 cancel:假如try阶段有问题,执行cancel阶段逻辑,取消try阶段的

分布式事务原理与实践

事务简介 事务的核心是锁和并发,采用同步控制的方式保证并发的情况下性能尽可能高,且容易理解.这种方式的优势是方便理解:它的劣势是性能比较低.计算机可以简单的理解为一个标准的打字机,尽管看起来计算机可以并行处理很多事情,但实际上每个CPU单位时间内只能做一件事,要么读取数据.要么计算数据.要么写入数据,所有的任务都可以看成这三件事的集合.计算机的这种特性引出了一个问题:当多个人去读.算.写操作时,如果不加访问控制,系统势必会产生冲突.而事务相当于在读.算.写操作之外增加了同步的模块,进而保证只有一

大规模分布式存储系统原理解析与架构实战

始读于2014年5月31日兔家中,前三章完成于2014年6月10日22:21:41 后几张是讲一些具体产品的内容,对于每一个产品,都需要确实的使用和经验,以后需要的时候再研究不迟,技术永远在使用中进步更大. 以前对存储尤其是分布式存储的整体知识体系不是太清楚,只是片段式的知道一些理论,通过此书的学习,对分布式存储的原理将豁然开朗,不管是理论的还是后面几章讲述的具体产品,都能做到知其然知其所以然.另外,书中对Paxos协议也进行了深入介绍,理解此协议对时下流行的去中心化将有"夫子言之,于我心有戚戚

redis实现分布式锁原理解析

目录 1.什么是分布式锁? 2.redis实现的分布式锁 3.内部实现解析 3.1.redis中的数据变化 3.2.redisson的实现方式 1.什么是分布式锁? 分布式锁,是控制分布式系统之间同步访问共享资源的一种方式.在分布式系统中,常常需要协调各个系统之间的动作.如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源,那么访问这些资源的时候,往往需要互斥来防止彼此干扰来保证一致性,在这种情况下,便需要使用到分布式锁. 2.redis实现的分布式锁 使用的是redisson框架操作

大厂面试必知必会:图解分布式事务实现原理

问题场景 什么是事务? 事务是数据库从一个稳定状态变迁到另一个稳定状态的保证,具备 ACID 这 4 个特性: 原子性(Atomicity):一个事务中的所有操作,要么全部完成,要么全部不完成,不会结束在中间某个环节.事务在执行过程中发生错误,会被回滚到事务开始前的状态. 一致性(Consistency):在事务开始之前和事务结束以后,数据库的完整性限制没有被破坏. 隔离性(Isolation):两个事务的执行是互不干扰的,两个事务时间不会互相影响. 持久性(Durability):在事务完成以