2 分钟
在项目中集成 Seata（AT模式）
首先，更新 到 版本： 引入 Seata 相关的依赖定义： 修改 加入 Seata 相关的配置： 只需要用普通的 标签来声明： 业务端（通常是微服务）的数据库中需要创建一个 表： 需要用 Seata 提供的 标签声明一次分布式事务的开始：
文章索引
6 篇文章从技术到生活，把写过的东西慢慢翻一遍。
标签：分布式事务清除筛选
1 分钟
生产环境 seata 高可用部署
生产环境 seata 高可用部署 更新 codo-java-bom 的版本到 1.2.2： com.codo.tech codo-java-bom 1.2.2 添加 zookeeper 的依赖包： com.101tec zkclient o
1 分钟
基于消息队列解决异步调用的分布式事务问题
经典的转账问题： 支付宝事务： 1. 数据库中mayun扣100元； 2. 将（给余额宝mayun加100元）封装成消息发给消息队列； 操作数据库和操作消息队列，如何保证一致性？ 支付宝事务： 1. 数据库中mayun扣100元； 2. 事
16 分钟
分布式事务实战：Seata AT 模式在订单履约链路中的应用
保证即使 finally 块中的 调用失败（网络抖动、OOM 等），定时任务也能兜底回推。 Seata AT 模式的一阶段是**直接提交本地事务**，全局事务的提交/回滚由 TC 协调。这意味着： 在 T1~T3 之间，其他请求查询包裹可能
3 分钟
seata分布式事务的脏读问题
用户将两个调拨单(A001,A002)进行拼单生产拼单后的调拨单A003,并将A003提交到仓库 问题: 什么时候能够查询到调拨单A003? 答: 在T1时刻后 T2时刻前 问题: 在T1时刻后T2时刻前提交,该调拨单能否提交成功? 因为s
2 分钟
Inventory回推状态给OMS改造
正常情况下派单结果要先于状态变更结果推送给OMS，但是因为目前这两个动作是分别由不同的任务触发的，并且都是异步的，所以有一定概率导致状态变更结果先于派单结果推送给OMS，导致派单结果被忽略掉，造成系统错误。 Seata分布式事务引发的脏读问