第4章 独立供血：数据拆分与一致性

第4章 独立供血：数据拆分与一致性

本章把镜头沉到服务下面——前面已经把服务切开、通信接通了，可数据还藕断丝连地共享在同一张数据库上。按微服务的第一性原理，每个服务该有自己养的数据。这一章讲三件事：数据怎么拆开各自供血、拆开后跨服务的数据一致性怎么挽回、以及拆完之后那些"跨服务查询"到底怎么做。

很多人拆到这一步才真正撞上痛处：服务能拆，数据库不能分。分分表好像很简单，但从共享大表改成"一家人各管一张表"，立刻推出三个连环问题——跨库事务怎么办？订单变了库存怎么知道？一个查询要找好几个服务的数据怎么拼？这三个问题，就是本章的三站，也是微服务落地时纯理论最救不了你的地方。

一条主线

回到商城，就盯"下单"这一个动作：订单要落账，库存要扣，积分要涨，钱要从支付渠道划走。这些数据以前在同一张库上，能用一个本地事务一起回滚；现在它们分散到各自服务的数据库里。我们一路看这套"分布扣血"怎么既保证数据最终对得上，又不让用户体验到"下单了一秒看库存没动"。

沿途站点

4.1 数据库每服务：切开数据源——讲清为什么要"每个服务各自拥有私有数据库"，数据所有权意味着什么，以及切分时最怕的"共享一个死库"和"跨库事务"陷阱。

4.2 最终一致性与 Saga 补偿缝合：——讲透本地事务为什么做不了跨服务、强一致为什么在微服务里高不可攀，以及 Saga（编排式/协同式）怎么靠"补偿"把账拉回最终一致，顺手把分布式事务几种方案对比清楚。

4.3 聚合查询与 CQRS：拆后的读取面——拆开后最挠头的是"一个详情要从五个服务拼出来"。本文讲三招：服务端聚合、只读副本/物化视图、以及 CQRS 的读写分离，帮你从"跨服务 join"的坑里爬出来。

拐点与结论

本章的认知转折是：在微服务里，"保持一致"不要去硬刚跨库事务，而要接受"最终一致"并主动管理它。把"下单"理解成"要扣好几家账"这个事实，再用补偿、对账、只读副本去兜，比在分布式里勉强做 2PC 强一致实际得多。读完全章你会发现一个反直觉的结论：数据拆得越干净，你的读取面就越要专门设计，CQRS 不是炫技，是被逼出来的解。

这一章最容易踩的三个坑

数据拆分的坑最隐蔽，因为它们藏在"好像没错"里：

1. 硬刚跨库强一致。拆了库还想着"一个事务改两家"，于是上 2PC 分布式事务，结果锁持有时间过长、吞吐崩掉，又慢又脆。微服务里接受最终一致、用 Saga 补偿，往往更实际。
2. 只意识到"写"是耦合，忽略"读"也是。以为"我就顺手查一下别的服务的表"不算耦合，其实把对方数据的语义复制进了自己脑子，对方改表你全盲。只读也要走接口或只读副本。
3. 把读取面拆得太碎，让详情页变成跨服务地狱。每个详情要 join 五个服务，延迟和复杂度一起爆炸。越拆越要专门设计读取面——服务端聚合、物化视图、CQRS 都是被这个逼出来的解。

清楚了这几个坑，站点里读起来就带着问题去找答案。

读完你应该

• 说出"数据库每服务"的数据所有权含义，识别共享库的死结
• 讲清本地事务 vs 分布式事务在微服务里的边界（2PC 的艰难）
• 会用 Saga 的编排式/协同式两种写法描述一个跨服务下单
• 从"跨服务 join"里选对解：服务端聚合 / 只读副本 / CQRS
• 判断一个场景该图强一致还是接受最终一致

下一章的接力

数据这摊账理顺了，服务在逻辑上是健康的了。可怎么把它们真正跑起来、扛住线上流量？第 5 章我们把它装进容器、交给编排平台，再把"上线 + 监护"两件事接上。血供对了，得让器官在现实环境里活下去。