企业官网建设流程全解析

现在最流行的网站开发工具,网站建设成本包括什么,凡科建站官网 网络服务,视频网站如何优化一、TC、TM、RM 核心定义 订单 / 账户服务 精准角色划分1. 三大核心角色#xff08;绝对核心#xff0c;牢记#xff09;TC#xff08;Transaction Coordinator#xff09;#xff1a;事务协调者 → 独立部署的Seata Server 服务端#xff0c;唯一的「总控中心」职责 订单 / 账户服务 精准角色划分1. 三大核心角色绝对核心牢记TCTransaction Coordinator事务协调者→ 独立部署的Seata Server 服务端唯一的「总控中心」职责统一生成分支事务 IDBID、维护 XID 和 BID 的一对多绑定关系、存储所有全局 / 分支事务状态、接收 TM 的全局提交 / 回滚指令、向 RM 下达分支提交 / 回滚指令不参与任何业务逻辑。TMTransaction Manager事务管理器→订单服务order就是唯一的 TM职责分布式事务的发起者 / 入口在标注GlobalTransactional的方法里本地生成全局事务 IDXID→ 把 XID 绑定到自己的线程上下文 → 向 TC注册这个 XID 的全局事务→ 执行业务创建订单 远程调用扣钱→ 业务执行完后只携带 XID 向 TC 发起「全局提交 / 回滚」指令。关键TM只持有 XID全程不碰 BID、不知道 BID 的存在。RMResource Manager资源管理器→订单服务 账户服务account都是 RMRM 是「干活的执行者」只要操作数据库 / 资源的都是 RM订单服务RM执行「创建订单」的本地数据库操作是全局事务下的第一个分支账户服务RM执行「扣钱」的本地数据库操作是全局事务下的第二个分支职责拿到 XID → 向 TC 注册分支事务、获取 TC 分配的 BID → 执行本地业务逻辑 → 等待 TC 的分支提交 / 回滚指令 → 执行最终的提交 / 回滚。关键RM持有 XIDBID只和 TC 交互和 TM 无直接指令交互。✅ 二、订单 扣钱 完整分布式事务执行流程按你的场景一步不差前提order 和 account 都引入了 Seata 客户端、配置了 TC 地址order 有GlobalTransactional是 TMRMaccount 无注解纯 RM所有 XID 的透传、绑定、分支注册全是 Seata 自动做业务代码无感知。完整步骤TMorder生成 XID 注册全局事务执行GlobalTransactional的创建订单方法Seata 本地生成唯一 XID绑定到 order 的线程上下文然后向 TC 注册「这个 XID 的全局事务」TC 记录这个 XID 的全局事务状态为「执行中」。TMorder作为 RM执行本地分支order 执行「创建订单」的 SQLSeata 拦截 SQL发现线程上下文有 XID → 自动向 TC 注册分支TC 生成BID1并返回 → order 执行创建订单 生成 undo_log完成第一个分支的预执行。XID 自动透传至 accountorder 远程调用 account 的扣钱接口Seata 的 Feign 拦截器自动从线程上下文拿 XID塞进请求头account 收到请求后Seata 的 MVC 拦截器自动从请求头提取 XID绑定到 account 自己的线程上下文。RMaccount注册分支 执行业务account 执行「扣钱」的 SQLSeata 拦截 SQL发现线程上下文有 XID→ 判定自己是分布式事务的一员自动向 TC 注册分支TC 生成BID2并返回 → account 执行扣钱 生成 undo_log完成第二个分支的预执行。✅ 核心判断逻辑RM 只认「线程上下文 RootContext 里有没有有效 XID」有就走分布式事务逻辑没有就直接放行走普通本地事务。TMorder发起全局指令order 的业务方法执行完毕无异常 提交有异常 回滚只携带XID向 TC 发起「全局提交 / 回滚」请求全程不带任何 BID。TC 总控协调所有 RMTC 拿到 XID 后找到这个 XID 绑定的所有 BIDBID1BID2分别向 order、account 下发「分支提交 / 回滚」指令指令里带 XIDBID。所有 RM 执行最终操作order 和 account 收到 TC 的指令后根据 XIDBID 执行最终的提交删除 undo_log或回滚根据 undo_log 恢复数据执行完后向 TC 汇报结果TC 更新全局事务状态整个分布式事务结束。✅ 三、你问的 2 个核心安全问题精准答案无多余问题 1万一有人往 context 里放一个混乱的无效 XID怎么办→完全无效直接被拦截Seata 有两层校验第一层本地快速校验 XID 格式混乱的字符串比如abc123不符合 Seata 的 XID 格式规范直接判定无效跳过分布式事务逻辑走普通本地事务第二层就算格式像真的向 TC 注册分支时TC 里没有这个 XID 的全局事务记录直接返回失败RM 抛异常分支注册失败业务要么回滚要么走本地逻辑。问题 2万一有人往 context 里放一个真实有效的、但不是当前事务的 XID怎么办→能注册分支但完全无影响数据绝对安全核心原因 3 个TC 只会给「处于执行中」的 XID 注册分支若这个 XID 已经提交 / 回滚 / 超时直接注册失败就算注册成功这个错配的分支只会收到「原 XID 对应的 TM」的指令和当前事务毫无关系当前事务的提交 / 回滚指令不会下发给它兜底分支和业务是强绑定的错配的分支执行的还是「当前扣钱 / 创建订单」的业务就算被回滚也只是当前业务执行失败不会篡改任何其他业务的数据数据一致性不受影响。✅ 四、核心关键结论所有重点浓缩背下来就行角色orderTMRMaccountRMSeata ServerTCID 归属XID 由 TM 本地生成BID 由 TC 统一分配TM 只拿 XIDRM 拿 XIDBID核心判断RM 靠「线程上下文有没有 XID」判断是否参与分布式事务有则走 Seata 逻辑无则放行交互关系TM 只和 TC 交互XIDRM 只和 TC 交互XIDBIDTM 和 RM 之间无任何事务指令交互只传业务参数安全兜底无论注入什么 XID都无法篡改数据最多导致当前业务执行失败无一致性风险。✅ 五、补充 2 个你大概率会问的细节提前给你省得再问细节 1同一个服务能既是 TM 又是 RM 吗能就是你的订单服务这是Seata 最常见的场景分布式事务的入口服务既发起全局事务TM又执行本地的资源操作RM。细节 2如果 account 自己调用自己的接口没有 XID 会怎样account 的线程上下文没有 XIDSeata 不会拦截扣钱逻辑走普通的本地数据库事务和 Seata 无关完全正常执行。最后给你一个极简口诀能把所有逻辑串起来TM 生 XIDTC 发 BIDRM 看 XID有则跟 TCTM 只传 XIDTC 管所有 BID全程自动化业务无感知✔️