【背景】
我做了 5 年数据链路，最近在项目里又碰了一次经典的纠结：一个读多写少（读写比约 20:1）的商品聚合接口，QPS 稳态 12k、峰值 30k，后端是 MySQL 主从 + 应用层缓存。
上一次全链路压测，主库直读 P99 在 18ms，从库读 P99 压到 6ms，但代价是主从复制延迟 P99 约 40ms——意味着从库读到的数据最多滞后 40ms。业务方说"40ms 内数据不一致我能接受"，数据平台说"你凭什么说能接受？上次那笔退款不是就踩了从库滞后？"
于是我们搞了个折中方案：核心字段（价格、库存）走主库，展示字段（描述、图片 URL）走从库 + 版本号兜底。代码复杂度直接翻倍，维护成本肉眼可见地涨了。
【常见分歧 / 几种做法】
我观察到的三种典型路线：
A. 全主库强一致读。 简单、正确、不出"读到旧数据"的 bug。但主库压力线性增长，读写比再高一点就要扩主库，成本是 2-3 倍。适合数据量小、写路径极重的场景（比如金融对账）。
B. 全从库 + 版本戳 / 乐观锁。 读性能最好，但业务代码里必须处理"读到旧版本 → 重试 or 降级"的逻辑。一旦某条业务路径漏了版本判断，就是线上事故。我见过一个团队在 3 个服务里各写了一套版本戳校验，逻辑还不完全一致。
C. 字段级混合（我目前用的）。 按"一致性敏感度"把字段拆成主库读和从库读两组。灵活，但 schema 一改、字段归属就可能要重新评估，长期维护成本高。
还有一种我没展开的：D. 全异步缓存（write-behind + 缓存失效广播）。 读走 Redis，写异步落库。延迟最低，但"缓存击穿 → 主库瞬时打满"的尾巴风险需要额外兜底。
【我的倾向与理由】
我倾向 C，但前提是把"一致性敏感度"的判定权交给业务方、用 SLO 谈判写进接口契约，而不是数据平台单方面拍。
理由：
- 数据平台无法替业务判断"这 40ms 的滞后会不会造成资损"——只有业务方知道哪些字段滞后 1ms 都是事故、哪些字段滞后 5s 用户都感知不到。
- 但业务方往往倾向于"全部强一致"（因为出事了他不背锅），所以需要一个机制把"选择最终一致的代价"量化成 SLA 条款，让决策有据可查。
- 字段级拆分虽然维护成本高，但比"全强一致"省下的主库资源，在 30k QPS 这个量级下是实打实的钱。
核心争点在于：这个边界到底该谁定？ 业务说"我只要最终一致"，出了事故他认吗？数据平台说"我按你要求做了"，责任就转嫁了吗？
【想听大家在什么场景下怎么选】
- 你们的团队里，"哪些字段走强一致、哪些走最终一致"这个决策，是业务方主动提的，还是数据平台默认全强一致、业务嫌慢才改的？
- 有没有踩过"业务以为从库是强一致、其实有 50ms 延迟"这种认知差导致的事故？怎么兜的？
- 在 10k QPS 以下的场景，你们觉得"直接全主库"是不是比"搞一套混合读"更划算？维护成本算进去，分界线大概在什么 QPS？
- 版本戳 / 乐观锁这套东西，你们是在 ORM 层、中间件层、还是业务代码层做的？各有什么坑？
欢迎拍砖，尤其是"我选了 B 然后线上炸了"或者"我选了 A 然后 DBA 来找我谈话"的实战故事。