seata学习及原理总结、分布式锁的实现
tc seata服务器@globaltranctiontm 事务的发起方rm事务的参与方Transaction Coordinator (TC): 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。Transaction Manager(TM):控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。假设有三个微服务,分别是服务A、B、C,其中服务A中调
·
tc seata服务器
@globaltranction
tm 事务的发起方
rm事务的参与方
-
Transaction Coordinator (TC): 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
-
Transaction Manager(TM): 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
假设有三个微服务,分别是服务A、B、C,其中服务A中调用了服务B和服务C,TM、TC、RM三者之间的交互流程如下图:
seata
分布式事务用的比较少 底层是有锁的
只有蚂蚁金服有
forkjoin框架详解
无锁并发框架disruptor
分布式锁有哪些主流实现方式?redis 和 zk 锁有什么区别?
大体分为两类。
乐观锁: 基于版本号机制和CAS实现,与存放版本号的存储无关。
悲观锁:
- 基于数据库记录,进入时写数据,退出时删记录
- 数据库行锁,比如分布式quartz,它是一把排它锁
- 基于Redis的setnx函数(由于大多数会设置超时,所以推荐用带px的set原子函数)
- 基于zookeeper
区别:
redis获取锁是轮训机制。锁释放后会有多个调用者争抢,某些任务有可能饿死。
zk是监听机制,有变动会接到通知。除了非公平锁,也可以实现公平锁。
从优雅性来说,显然redis胜出
更多推荐
已为社区贡献2条内容
所有评论(0)