2PC常被绕过因其存在单点阻塞、协调器故障致悬挂事务、网络分区无法自动回滚等问题，高吞吐场景下协调延迟拖垮性能；替代方案包括本地消息表+定时补偿、Seata AT模式、TCC等。
分布式事务中 2PC 为什么常被绕过
因为 2PC 在跨节点场景下存在单点阻塞、协调器故障导致悬挂事务、网络分区时无法自动回滚等问题，实际生产中多数系统选择不强依赖它。尤其在高吞吐写入场景（如订单+库存+积分拆分到不同库），协调延迟会直接拖垮响应时间。
常见替代方案包括：
- 业务层最终一致性：用
本地消息表 + 定时补偿替代全局事务 - 基于
Seata AT模式：依赖 undo log 自动反向 sql，但要求数据库支持行级锁且不能有 DDL 并发 - 使用
TCC：需手动编码try/Confirm/Cancel三个阶段，对业务侵入大，但可控性高
select ... for UPDATE 在分库分表后失效的原因
分库分表中间件（如 ShardingSphere、MyCat）通常只保证单逻辑表内的行锁语义，跨分片的 SELECT ... FOR UPDATE 会被路由到多个物理库执行，彼此无锁感知，等价于加了 N 个互不相关的本地锁。
这意味着：
- 若两个事务分别锁定不同分片上的记录，仍可能引发脏写
-
FOR UPDATE不会触发跨节点锁等待，也不会报错，行为静默但危险 - 唯一可靠方式是把需要原子更新的数据尽量收敛到同一分片（例如用
user_id做分片键，让账户余额和交易流水落在同库）
读已提交（READ COMMITTED）在分布式库中不等于“读到一致快照”
每个物理库独立维护自己的事务视图和 MVCC 快照，即使所有库都设为 READ COMMITTED，应用从不同分片并发读取时，仍可能看到部分已提交、部分未提交的状态——这不是隔离级别配置错误，而是架构层面的固有限制。
典型表现：
- 查订单主表返回
status = 'paid'，但关联查支付明细表却为空（因支付记录落在另一分片，尚未同步提交） - 使用
XA或Seata XA可强制统一快照起点，但性能损耗显著，且要求所有参与库支持 XA 协议 - 更轻量做法是引入
全局时间戳服务（如 TSO），在业务读取前先获取一个单调递增时间点，再按该时间点查询各分片
异步复制延迟导致的 主从不一致 怎么收敛
mysql 主从、tidb Learner 副本、甚至 kafka-based CDC 同步链路，都存在毫秒到秒级延迟。当应用刚写完主库就立刻查从库，大概率读到旧值。
缓解手段不是消除延迟（做不到），而是控制读请求的可见性边界：
- 关键路径强制走主库：比如用户刚下单，后续查订单详情必须打到
write datasource - 利用
GTID或binlog position做从库读前校验（ShardingSphere 支持hint指定主库位点） - 对非实时场景，用
缓存双删 + 延迟消息校验替代强一致读，例如更新 DB 后删缓存，再发延迟 5s 的 MQ 消息重刷缓存
最易被忽略的是：很多团队以为加了 read_uncommitted 就能解决读延迟，其实它只会让问题更隐蔽——你读到了未提交的中间态，比读旧值还难排查。