sofa-seata ╰+攻爆jí腚メ 2023-02-11 12:30 5阅读 0赞 最近工作好不容易有点空闲时间,工作上又碰到了分布式事务的问题,正好最近又在看sofa rpc,于是很自然的过渡到了sofa的seata,一个star很多的分布式事务框架。 原理官网讲的很清楚了: ### Seata AT 模式 ### 前提 * 基于支持本地 ACID 事务的关系型数据库。 * Java 应用,通过 JDBC 访问数据库。 整体机制 两阶段提交协议的演变: * 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。 * 二阶段: * 提交异步化,非常快速地完成。 * 回滚通过一阶段的回滚日志进行反向补偿。 ### 写隔离 ### * 一阶段本地事务提交前,需要确保先拿到 全局锁 。 * 拿不到 全局锁 ,不能提交本地事务。 * 拿 全局锁 的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁。 以一个示例来说明: 两个全局事务 tx1 和 tx2,分别对 a 表的 m 字段进行更新操作,m 的初始值 1000。 tx1 先开始,开启本地事务,拿到本地锁,更新操作 m = 1000 - 100 = 900。本地事务提交前,先拿到该记录的 全局锁 ,本地提交释放本地锁。 tx2 后开始,开启本地事务,拿到本地锁,更新操作 m = 900 - 100 = 800。本地事务提交前,尝试拿该记录的 全局锁 ,tx1 全局提交前,该记录的全局锁被 tx1 持有,tx2 需要重试等待 全局锁 。 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70][] tx1 二阶段全局提交,释放 全局锁 。tx2 拿到 全局锁 提交本地事务。 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 1][] 如果 tx1 的二阶段全局回滚,则 tx1 需要重新获取该数据的本地锁,进行反向补偿的更新操作,实现分支的回滚。 此时,如果 tx2 仍在等待该数据的 全局锁,同时持有本地锁,则 tx1 的分支回滚会失败。分支的回滚会一直重试,直到 tx2 的 全局锁 等锁超时,放弃 全局锁 并回滚本地事务释放本地锁,tx1 的分支回滚最终成功。 因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的,所以不会发生 脏写 的问题。 ### 读隔离 ### 在数据库本地事务隔离级别 读已提交(Read Committed) 或以上的基础上,Seata(AT 模式)的默认全局隔离级别是 读未提交(Read Uncommitted) 。 如果应用在特定场景下,必需要求全局的 读已提交 ,目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 2][] SELECT FOR UPDATE 语句的执行会申请 全局锁 ,如果 全局锁 被其他事务持有,则释放本地锁(回滚 SELECT FOR UPDATE 语句的本地执行)并重试。这个过程中,查询是被 block 住的,直到 全局锁 拿到,即读取的相关数据是 已提交 的,才返回。 出于总体性能上的考虑,Seata 目前的方案并没有对所有 SELECT 语句都进行代理,仅针对 FOR UPDATE 的 SELECT 语句。 ### 工作机制 ### 以一个示例来说明整个 AT 分支的工作过程。 业务表:product <table> <thead> <tr> <th>Field</th> <th>Type</th> <th>Key</th> </tr> </thead> <tbody> <tr> <td>id</td> <td>bigint(20)</td> <td>PRI</td> </tr> <tr> <td>name</td> <td>varchar(100)</td> <td>null</td> </tr> <tr> <td>since</td> <td>varchar(100)</td> <td>null</td> </tr> </tbody> </table> AT 分支事务的业务逻辑: <table> <tbody> <tr> <td> <pre>update product set name = 'GTS' where name = 'TXC'; </pre> </td> </tr> </tbody> </table> 一阶段 过程: 1. 解析 SQL:得到 SQL 的类型(UPDATE),表(product),条件(where name = ‘TXC’)等相关的信息。 2. 查询前镜像:根据解析得到的条件信息,生成查询语句,定位数据。 <table> <tbody> <tr> <td> <pre>select id, name, since from product where name = 'TXC'; </pre> </td> </tr> </tbody> </table> 得到前镜像: <table> <thead> <tr> <th>id</th> <th>name</th> <th>since</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>TXC</td> <td>2014</td> </tr> </tbody> </table> 1. 执行业务 SQL:更新这条记录的 name 为 ‘GTS’。 2. 查询后镜像:根据前镜像的结果,通过 主键 定位数据。 <table> <tbody> <tr> <td> <pre>select id, name, since from product where id = 1; </pre> </td> </tr> </tbody> </table> 得到后镜像: <table> <thead> <tr> <th>id</th> <th>name</th> <th>since</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>GTS</td> <td>2014</td> </tr> </tbody> </table> 1. 插入回滚日志:把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录,插入到 UNDO\_LOG 表中。 <table> <tbody> <tr> <td> <pre>{ "branchId": 641789253, "undoItems": [{ "afterImage": { "rows": [{ "fields": [{ "name": "id", "type": 4, "value": 1 }, { "name": "name", "type": 12, "value": "GTS" }, { "name": "since", "type": 12, "value": "2014" }] }], "tableName": "product" }, "beforeImage": { "rows": [{ "fields": [{ "name": "id", "type": 4, "value": 1 }, { "name": "name", "type": 12, "value": "TXC" }, { "name": "since", "type": 12, "value": "2014" }] }], "tableName": "product" }, "sqlType": "UPDATE" }], "xid": "xid:xxx" } </pre> </td> </tr> </tbody> </table> 1. 提交前,向 TC 注册分支:申请 product 表中,主键值等于 1 的记录的 全局锁 。 2. 本地事务提交:业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。 3. 将本地事务提交的结果上报给 TC。 二阶段-回滚 1. 收到 TC 的分支回滚请求,开启一个本地事务,执行如下操作。 2. 通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。 3. 数据校验:拿 UNDO LOG 中的后镜与当前数据进行比较,如果有不同,说明数据被当前全局事务之外的动作做了修改。这种情况,需要根据配置策略来做处理,详细的说明在另外的文档中介绍。 4. 根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句: <table> <tbody> <tr> <td> <pre>update product set name = 'TXC' where id = 1; </pre> </td> </tr> </tbody> </table> 1. 提交本地事务。并把本地事务的执行结果(即分支事务回滚的结果)上报给 TC。 二阶段-提交 1. 收到 TC 的分支提交请求,把请求放入一个异步任务的队列中,马上返回提交成功的结果给 TC。 2. 异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。 从实际业务模型出发,一个用户购买模型,主要涉及三个服务:库存服务、账户服务、订单服务,一笔业务过来后先扣账户余额,再扣库存,最后创建订单,其中有任何一步失败都需要回滚前面执行的操作,每个服务使用有自己独立的数据库,这种情况就需要使用分布式事务来控制了。 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 3][] 关于seata的实现原理官网讲的很清楚了,但是使用文档很匮乏,所以我就主要分享一下使用与配置,我使用的是eureka作为注册中心 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 4][] 细的原理略过,但是整体框架得知道,其实很多情况下都是对整体不了解所以看使用文档报各种各样的错。 TM和RM都是集成在微服务中的,不用额外部署,但是这个TC是个单独的进程,需要另外部署的(有点service mesh的味道了)。 第一步:TC server的部署 参考这篇文章的单机部署章节:[链接地址][Link 1] 集群部署也很简单,文章中也有介绍,我就不赘述了 第二步才是项目的运行: 参考这篇文章:[链接地址][Link 2] 我使用的是AT模式+Feign,但是文章中关于事务分组讲的云里雾里,我表示我很懵 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 5][] 其实事务分组主要是为了解决TC集群节点出问题能快速failover,所以多了一层这个分组到映射集群的配置,详情请看官方文档介绍:[链接地址][Link 3] `seata-server`中有个配置文件`registry.conf`,里面有很多注册中心的实现,我使用的eureka,所以type改为eureka,然后看到下面eureka的具体配置,里面有三个参数,application的值其实就对应了分组映射的集群名称,当然不是必须设置为default,只要`seata-server`的application和项目中的集群名称一致就行。 另外,`spring.cloud.alibaba.seata.tx-service-group`的值为A,那么`seata.service.vgroup_mapping.`后面就得填A,然后值是集群名称(默认default)。举例如下: `spring.cloud.alibaba.seata.tx-service-group:abc` `seata.service.vgroup_mapping.abc:default` 再重复一遍:搞这么复杂就是为了TC集群节点出问题能快速failover 如果使用feign那么其实是在底层HttpUrlConnection头上加了个全局事务ID,这个实现是在`Spring Cloud Alibaba`里实现的,所以须要引入 `Spring Cloud Alibaba Seata`相关依赖 既然用了eureka,那么肯定需要自己搭一个eureka服务器,很简单,自行百度。 最后再附一张整体架构图。 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 6][] [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200524231808930.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200524231831584.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 2]: https://img-blog.csdnimg.cn/20200524231853727.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 3]: https://img-blog.csdnimg.cn/20200524231914936.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70 [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200524231931568.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70 [Link 1]: http://www.iocoder.cn/Seata/install/ [Link 2]: http://www.iocoder.cn/Spring-Cloud-Alibaba/Seata/?self [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 5]: https://img-blog.csdnimg.cn/2020052423194837.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70 [Link 3]: https://seata.io/zh-cn/docs/user/transaction-group.html [watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU_size_16_color_FFFFFF_t_70 6]: https://img-blog.csdnimg.cn/20200524232008774.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2phdmFlcl9sZWU=,size_16,color_FFFFFF,t_70
还没有评论,来说两句吧...