分布式事务状态存储：为什么我劝你慎用 Redis 和 Apollo/Nacos？

最近在群里看到又有兄弟在为分布式事务的“状态到底存哪儿”吵得不可开交。有人觉得 Redis 快，适合做状态机；有人觉得 Apollo/Nacos 统一管理挺好。但作为过来人，我得泼盆冷水：在分布式事务状态同步这个场景下，Redis 和 Apollo/Nacos 都有致命短板，而往往被嫌弃“慢”的本地数据库（或持久化存储），反而是最值得信任的基石。

先说 Redis。它的优势是极致的内存读写速度，但在事务状态这个领域，它的“快”往往是陷阱。

1. 数据易失性风险：虽然有 AOF/RDB，但 Redis 本质还是内存数据库。如果配置不当或发生极端故障，内存数据丢失意味着事务状态归零，这在金融或核心业务中是不可接受的。
2. 缺乏事务语义：Redis 的事务（Transaction）并非 ACID 意义上的事务，它只是命令的批量执行，不支持回滚。在复杂的 Saga 或 TCC 模式中，我们需要的是状态变更的原子性保障，Redis 难以胜任。
3. 缓存与存储的混淆：Redis 擅长做读写分离中的“读”层（热数据缓存），但把核心的“写”状态（事务执行中、已提交）放在这里，违背了架构分层原则。

再看 Apollo/Nacos。它们是优秀的配置中心和服务注册发现组件，但把它们当“状态机”用，属于严重的角色错位。

1. 高并发下的性能瓶颈：它们的底层通常是关系型数据库。虽然做了多级缓存，但面对成千上万的事务分支频繁上报状态（Update Status），配置中心的长轮询或推送机制会带来巨大的网络开销和存储压力。
2. 数据模型不匹配：配置中心的设计初衷是管理“配置项”的变更（低频、大文本），而事务状态是“高频、小数据”的状态流转。用配置中心存储状态，就像用集装箱仓库来当高速公路收费站，不仅拥堵，而且管理粒度也不对。

反观本地数据库（或基于本地文件的存储如 RDBMS、TiKV 等），为什么说它更值得信任？

1. ACID 的硬核保障：这是根本。本地数据库提供的事务隔离性和持久化，是保证“状态不丢、状态不乱”的底线。只有在本地落地了，才能通过 Binlog、Redo Log 确保数据一致性。
2. 状态机的最佳载体：分布式事务往往需要状态机（Pending -> Committing -> Committed）。利用数据库的行锁（Row Lock）或乐观锁（CAS），可以非常优雅且安全地处理状态流转的并发冲突，这是 Redis 和 Apollo 原生不具备的能力。
3. 可观测性与运维：DBA 对数据库的运维手段成熟得多。出问题了，我们可以直接查 SQL 追踪链路，而不需要去分析 Redis 的 Key 过期策略或 Apollo 的 ConfigService 日志。

总结一下：
架构设计要讲究“各司其职”。Redis 用来抗高并发读，Apollo 用来下发配置，而本地数据库（配合消息队列）才是承载分布式事务状态流转的“铁底座”。试图用缓存或配置中心去替代存储的职责，本质上是在拿业务的稳定性去赌性能的提升，这笔账算不过来。