目录
- 9.1 什么是弱一致性 ?
- 9.2 Seata的弱一致性
- 9.3 Seata的AT模式介绍
- 9.4 AT模式流程图
- 9.5 AT模式注意点
- 9.6 全局锁的理解
- 1、认识全局锁
- 2、注册全局锁
- 3、校验(获取)全局锁
- 4、释放锁
- 5、结论
- 9.7 AT的多数据源场景
9.1 什么是弱一致性 ?
弱⼀致性舍弃了强⼀致性,表示允许在某个时间点 甚⾄某个时间段 主从节点的数据不⼀致性的情况。但是这种不⼀致性只是暂时的,但是数据最终会变的⼀致性。
9.2 Seata的弱一致性
seata的四种模式 除了XA模式是强⼀致性之外 其他的三种⽐如 Saga TCC AT 都属于弱⼀致性,但是除了这些弱⼀致性的解决⽅案之外,还有可以利⽤可靠消息队列实现最终⼀致性的效果等等
AT 是Seata强烈建议使用的方式,95%的人使用Seata都会使用AT模式
9.3 Seata的AT模式介绍
AT模式和XA模式差不多,是由XA模式演化⽽来的,是Seata推荐的⼀种分布式解决⽅案,AT模式最早来源于阿⾥中间件团队发布的TXC服务。 AT模式不再像XA那样,AT模式下数据库不需要⽀持XA协议。并且AT模式和XA模式从编码模型上⼏乎⼀样,可以这样说,会XA的编码 就会AT的编码。
9.4 AT模式流程图
9.5 AT模式注意点
9.6 全局锁的理解
1、认识全局锁
全局锁由表名和操作记录的主键 按照⼀定的规律组成。 seata的AT模式 全局锁保存在TC端(seata-server端) TC端保存全局锁可以在如下三个位置 redis mysql file(默认)
2、注册全局锁
RM 向TC注册分⽀事务,在注册分⽀事务之后,将会操作数据库修改数据,提交事务 之前,将会把修改的表和主键信息封装成全局锁,发送到TC服务器进⾏注册,如果TC服务器发现已经有这个主键 的全局锁 证明有其他事务正在执⾏这条数据 则会跑出全局锁冲突异常,客户端会循环等待并且重试
3、校验(获取)全局锁
提交本地事务时 先要获取这个全局锁,当能获取到全局锁 则会提交本地事务 如果全局锁被占⽤则表示有其他事务在操作这条数据。客户端等待 重试获取锁
4、释放锁
第⼆阶段是异步执⾏的,在TC向RM(客户端)发送 branch Commit请求后,客户端仅将分⽀提交信息插⼊内存列队中,可以理解为 如果第⼀阶段成功,第⼆阶段不出异常的情况下,第⼆阶段⼀开始就会释放全局锁,不会锁定到第⼆阶段执⾏结束才会释放全局锁
5、结论
全局锁将会被客户端持有到第⼆阶段的开始 所以性能不如本地事务⾼