共享事务的两种实现与其伪需求本质

共享事务解决的是与全局事务相反的场景：多个服务共用同一个物理数据库 （不是同一进程内的多副本各连各的数据源，而是拆分后的微服务碰巧还连着 同一个库）。理论可行的方案是让各服务共享数据库连接——但数据库连接绑定 IP和端口，跨进程/跨节点共享连接几乎不可行，因此必须新增一个”交易服务器” 中间角色，所有服务都通过它来访问数据库，让交易服务器根据统一的事务ID把 跨服务的操作收敛成一次本地事务；更常见的变种是用消息队列代替交易服务器， 各服务把对数据库的改动通过消息传给统一的消费者去完成持久化（”单个数据库 的消息驱动更新”）。但作者明确指出，这个方案与实际生产系统的压力方向相 悖——数据库本来就是集群里最难水平扩展的瓶颈，现实中只见”用代理把多个 数据库实例做负载均衡”，几乎没有反过来”用一个代理服务器为多个应用协调 事务”的成功案例。更深层的问题是：如果拆分微服务后仍然离不开共享数据库， 那多半说明拆分本身的合理性就值得重新审视——共享事务更像是理论完备性的 凑数条目，而非值得推荐的常规方案。