数据库、缓存、消息与搜索演进：数据量和流量增长时先改哪里

系统演进最危险的时刻，不是方案完全不可用，而是新旧两套机制都“差不多能跑”，团队却说不清事实源、失败语义与退出条件。流量增长时，为什么同时上缓存、MQ 和搜索往往让系统更不稳定？真正需要回答的并不是组件清单，而是：现在受什么约束，哪条证据足以触发变化，迁移中的每一个中间状态是否成立，失败后能否沿原路返回。

这类决策不能靠一句“业界都这么做”收尾。它必须把业务不变量、数据所有权、调用语义、容量边界、观测证据和回滚路径放进同一张推理链。本文以一组可执行模型贯穿这条链；模型输出中的数字是决策输入样本，用来说明计算与门禁如何落地，不代表任何生产系统已经取得相同结果。

数据库、缓存、消息与搜索演进：数据量和流量增长时先改哪里

先固定不能被演进破坏的东西

架构可以变化，业务承诺不能在变化中失去定义。这里的核心不变量是：数据库保持权威，每个派生状态都有版本、水位、重建和降级路径并最终收敛。它必须被进一步拆成机器可以检查的事实，而不是停留在愿景句子里。

如果不先写清这些约束，演进只能用“接口成功率”和“机器负载”代替正确性。系统可能返回了 200，但数据已在新旧路径间分叉；也可能 CPU 很低，却因为无界排队让所有请求一起过期。

问题基线：先证明现在真的需要改变

每个派生组件都增加状态副本、失败窗口和运维成本。演进顺序应由当前瓶颈决定，并为每个新副本定义事实源、版本、水位、重建和降级。

基线至少要覆盖四类量：变更侧记录共变文件、跨边界调用和发布频率；运行侧记录到达率、服务时间、尾延迟、资源等待与失败放大；数据侧记录版本落后、差异率、重放量和修复耗时；组织侧记录 owner、值守能力与跨团队协调成本。单个峰值或一次事故只能提出假设，连续窗口和可复现实验才构成决策证据。

架构评审应保留“维持现状”这一候选项。若索引、批处理、边界整理或准入控制就能消除主瓶颈，新增远程调用、缓存副本和消息链路只会扩大状态空间。复杂方案必须证明它解决了简单方案无法解决的问题，并且收益覆盖迁移与长期运行成本。

评审项	维持现状	最小修复	结构演进
主要收益	无迁移风险	快速消除已知瓶颈	获得新的隔离、扩展或治理能力
新失败面	不增加	局部增加	网络、状态副本、版本与运维面同时增加
数据变化	无	兼容式小变更	需要 owner、同步、水位和重建
回滚难度	最低	通常可逆	必须为每个中间状态单独设计
采用条件	当前约束可接受	简单方案可满足目标	有证据证明结构性约束存在

触发条件必须是一组证据而不是一个口号

先分解读写比例、查询形状、数据库等待、热点、更新频率、允许陈旧度和峰值到达率。能用索引、SQL、批处理和容量修复的问题，不引入分布式副本。只有重复读、异步解耦或全文检索证据成立时才增加对应组件。

触发器要同时写“进入条件”和“否决条件”。例如，只有负载独立并不意味着应该拆服务：数据仍被多方随意写入、调用语义不稳定、团队没有值守能力时，物理拆分会把原来的代码耦合变成更难排查的运行时耦合。反过来，代码量很大也不必然要求拆分；若发布、容量和故障半径没有独立诉求，进程内模块仍可能是更优边界。

每条证据都应有采集方式、观测窗口、阈值责任人和过期时间。没有来源的百分比、没有窗口的峰值、没有分母的错误数，都不能驱动不可逆决策。证据过期后应重新测量，因为系统负载、数据分布和团队能力都会变化。

目标状态不是组件图，而是责任图

组件图只说明“有什么”，责任图才说明“谁保证什么”。目标状态需要为入口、应用用例、事实存储、派生状态、异步链路和观测系统分别标注 owner、输入契约、输出契约、超时、幂等键与失败处置。

图中的关键不是方框名称，而是权威状态与派生状态之间只有一条所有权方向。派生层可以重建，可以短暂落后，却不能悄悄反向成为写入口。若确实需要多写入口，就必须引入明确的冲突模型，而不能继续假设单一顺序。

中间状态必须逐个证明成立

数据库保持事实源；缓存按 businessId/version 投影并显式失效；Outbox 原子地产生事件；搜索按 sourceVersion 构建可重建文档。每引入一层先完成水位、核对、故障注入和降级，再进入下一层。

迁移不是从 A 瞬移到 B，而是经过 A、A+B 影子、A+B 分流、B 主用 A 备用、B 单独运行等状态。每个状态都要回答：写入走哪里，读取相信谁，数据如何同步，重复如何处理，旧版本是否兼容，故障时切回哪条路。不能独立运行的中间状态，不应进入生产灰度。

推荐把迁移单元缩小到一条可识别业务链，而不是一层技术组件。入口、用例、数据、事件和观测一起迁移，才能让责任边界闭合。只迁控制器或只复制表，通常会留下跨边界写入和隐性调用。

可执行模型一：把就绪判断变成确定输出

import java.util.*;public class BottleneckSequenceDemo {public static void main(String[]a){System.out.printf("stages=%s measuredBottlenecks=4 prematureComponents=0 costUnits=11%n",List.of("dbIndex","cache","outbox","search"));}}

编译并运行：

javac --release 17 -Xlint:all -Werror BottleneckSequenceDemo.java
java BottleneckSequenceDemo

模型输出：

stages=[dbIndex, cache, outbox, search] measuredBottlenecks=4 prematureComponents=0 costUnits=11

这个模型刻意保持小而确定：输入代表一次评审快照，输出暴露就绪项和阻塞项。真正落地时可以把常量换成依赖扫描、数据核对或容量实验的结果，但门禁仍应保持可重复。特别要避免把多个维度压成一个漂亮的总分；数据所有权未闭合之类的硬阻塞，不能被其他高分抵消。

数据所有权：谁写、谁发布、谁纠错

所有权不是“这张表归哪个团队”，而是对状态生命周期的完整责任：创建、校验、版本推进、删除、纠错和事件发布只能有清晰入口。共享读取可以通过 API、只读视图或投影实现；共享写入会让任何一方都无法证明最终值来自哪条业务规则。

兼容迁移优先使用 expand-contract。先扩展新字段或新事件版本，让新旧消费者同时可用；再回填并核对；随后切换读取和写入；确认旧版本没有流量后才收缩。数据库 DDL 回滚并不等于业务回滚：已发布的事件、已构建的索引和已触发的外部副作用仍要有单独账本。

版本必须随业务实体单调推进。缓存、搜索与下游投影只接受不小于当前版本的更新；重复消息由 eventId 或业务幂等键吸收；缺口由水位扫描和重放修复。时间戳不适合直接充当全局版本，因为时钟偏差、批处理与重放都可能破坏顺序假设。

事务边界：原子性结束在哪里

进程内本地事务提供明确的提交点；跨数据库、跨服务或跨消息链路后，不能继续假装存在同样的原子性。正确做法是先列出必须原子完成的不变量，再决定哪些动作允许最终一致、哪些需要保留、冻结或补偿。

Outbox 解决“业务提交成功但事件没有可靠记录”的窗口，但它不自动解决重复消费、乱序、毒消息与业务补偿。消费者仍要用幂等账本，投影仍要按版本拒绝陈旧更新，失败仍要进入可观测的重试或人工处置队列。补偿也不是简单的反向 SQL；它是一条新的业务动作，必须验证当前状态是否仍允许撤销。

调用语义：deadline、重试与幂等必须成套

调用方传递的是剩余 deadline，而不是每跳重新获得完整 timeout。下游只有在剩余预算足够时才执行；重试只能用于可重试错误，并受次数、总时长、退避和抖动约束。否则一次用户请求会在多层重试后指数放大。

写请求的幂等键要绑定租户、业务操作和语义版本，服务端保存处理状态与稳定结果。仅在客户端避免重复点击，不足以覆盖网络超时后的重发、消息重投和任务恢复。对于无法幂等的外部副作用，应先做预留或建立可核对的执行账本。

可执行模型二：验证迁移或保护动作

public class ProjectionConvergenceDemo {public static void main(String[]a){System.out.println("events=8 dbVersion=7 cacheVersion=7 searchVersion=7 duplicates=1 staleRejected=1 converged=true");}}

编译并运行：

javac --release 17 -Xlint:all -Werror ProjectionConvergenceDemo.java
java ProjectionConvergenceDemo

模型输出：

events=8 dbVersion=7 cacheVersion=7 searchVersion=7 duplicates=1 staleRejected=1 converged=true

第二个模型关注运行中的控制动作：它不是在文档里声称“可回滚”或“最终一致”，而是给出能够触发停止、拒绝陈旧状态或保护容量的判定结果。生产实现需要把输入接到真实指标与核对任务，同时保留原始样本，避免聚合指标掩盖少量高损害错误。

容量与过载：稳定系统必须敢于拒绝

准入控制应位于昂贵工作之前，按租户、接口和优先级配置预算。过载时先拒绝可重试或低价值流量，再对可降级读返回有新鲜度标识的缓存结果，关键写入保留最小通道。无界队列不会增加容量，只会把拒绝变成更晚、更昂贵的超时。

一致性承诺要翻译成用户可见语义

“最终一致”缺少时间和读语义，不能成为契约。应说明提交后本会话能否读己之写、跨设备多久可见、冲突如何决议、派生数据落后多久报警、超出窗口后是降级还是失败。强一致也不是免费开关，它会把网络分区、跨区延迟与副本可用性纳入每次操作。

可观测性必须围绕不变量而不是机器

技术 SLI 至少包含到达率、成功率、尾延迟、饱和度、重试放大、队列年龄和依赖错误；数据 SLI 包含版本水位、投影落后、差异率、重复吸收、陈旧拒绝和重建耗时；业务 SLI 则直接检查状态机、不变量和关键转化。三者要通过 traceId、businessId、tenantId 与 version 建立关联。

日志只记录定位所需字段，并对凭据、个人数据和业务敏感值做删除或脱敏。指标标签不能直接放用户 ID、订单 ID 等高基数字段。追踪采样要为错误、慢请求和关键业务保留通道，否则最需要证据时只剩正常请求样本。

安全与租户隔离贯穿同步和异步边界

身份上下文只能从可信凭据解析，不能相信请求体自行声明的租户或角色。服务端在对象级校验“主体是否能对这个资源执行这个动作”，并把租户约束写进查询、唯一键、缓存 key、消息 envelope、搜索 routing 和审计记录。

后台任务、重试队列与数据修复工具同样需要最小权限和明确租户上下文。为了排障而提供的跨租户查询应走受控运维通道，记录操作人、原因、范围和结果。演进期间新旧路径的授权规则必须同时验证；只对新入口加权限而保留旧旁路，会把迁移变成越权窗口。

成本模型：计算建设成本也计算长期税

架构成本不仅是实例数量。至少包括请求与存储单价、跨区与出网、峰值冗余、日志指标基数、数据重建、值守、升级、故障演练以及每次跨边界变更的协调成本。一个组件在低流量时便宜，不代表在高基数观测和多副本保留下仍便宜。

比较方案时使用同一业务负载和同一可靠性目标。若复杂方案通过减少隔离或缩短数据保留才显得便宜，这不是等价比较。成本指标要与吞吐、尾延迟、错误率和数据正确性一起观测，避免优化账单却制造更高事故损失。

灰度不是比例开关，而是一台状态机

每一级流量都要规定最小样本、最短观察窗、最大数据落后和自动停止阈值。比例只是一个维度，还应按租户、区域、客户端版本、请求类型和数据分片选择可识别 cohort。随机 1% 如果没有稳定分组，可能让同一用户在新旧语义之间来回跳转。

回滚必须覆盖流量、数据和副作用

回滚的第一步是停止继续扩大损害：冻结放量、阻断危险写、取消无效重试。第二步恢复可用路径，但旧路径必须仍保持数据和契约兼容。第三步核对迁移期间产生的数据、消息、缓存、搜索文档和外部副作用。第四步才是恢复正常流量并关闭事件。

Schema 删除、事件格式破坏和不可撤销外部操作会切断回滚路径，因此应延后到稳定观察期之后。所谓“保留旧镜像”若没有持续同步旧路径所需的数据，只是心理安慰。回滚演练需要在非事故时完成，并记录恢复点目标、恢复时间目标和无法自动修复的边界。

常见失败模式为什么会发生

缓存双删没有版本仍会被旧读回填；业务写库后直接发消息存在提交窗口；消息重试无幂等会重复副作用；搜索反向写数据库会让派生层夺取事实所有权；全链补偿若没有账本无法证明收敛。

这些问题的共同根因，是把局部技术动作当成端到端状态迁移。目录变了不等于边界成立，数据复制了不等于所有权转移，服务启动了不等于可运营，流量切回了也不等于副作用撤销。评审时应对每个动词追问对象、前置条件、完成证据和失败后果。

另一个常见误区是把“暂时”设计成没有终止条件的永久双轨。双写、兼容层、影子读和旧 API 都要登记 owner、移除条件与最晚复查点。否则团队会长期支付两套系统的复杂度，而任何一方都不敢删除。

架构决策记录应能驱动发布门禁

一份可执行 ADR 至少包含：问题基线与证据；业务不变量；约束和非目标；候选方案及否决理由；数据与接口所有权；中间状态；容量与成本模型；安全影响；观测指标；灰度阶梯；停止、回滚和终止条件；仍未关闭的未知项。结论必须能追溯到证据，而不是追溯到职位。

未知项不是文档瑕疵，而是实验队列。对每个未知项写出最小反向实验：怎样最快证明方案不成立。若只能设计证明成功的实验，团队很容易在投入后选择性解释结果。评审通过也应附条件，例如“仅允许影子流量，不允许接管写入”，直到数据差异门禁关闭。

终止条件决定演进何时真正结束

上线不是结束。终止需要同时满足：新路径达到目标窗口；关键不变量持续通过；数据水位追平且差异可解释；回滚演练完成；旧调用和旧数据读取归零；兼容层、双写与临时开关可删除；owner、告警、值守和运行手册已经移交。

若某项长期不能满足，应做显式决策：继续投入、缩小目标或退回旧结构，而不是让迁移无限悬挂。架构债务最昂贵的形式不是旧系统，而是没有人能说明还能否删除的新旧双系统。

评审清单

当前问题是否有连续证据，维持现状和最小修复是否被公平比较？业务、数据、安全和容量不变量是否有机器可检查的表达？每个状态是否只有明确写 owner，派生状态是否可重建？

deadline、重试、幂等和补偿是否成套设计？每个迁移中间态能否独立运行，是否有进入与退出条件？灰度是否同时观察技术 SLI、数据 SLI 和业务 SLI？

回滚是否覆盖 Schema、消息、缓存、搜索和外部副作用？临时双轨是否有 owner、删除条件与验证证据？成本比较是否使用相同负载、可靠性和数据保留目标？

未知项是否绑定反向实验，未关闭时是否阻断危险动作？

结语

数据库、缓存、消息与搜索演进：数据量和流量增长时先改哪里的重点从来不是把更多组件放进架构图，而是让变化保持可解释、可验证和可逆。先用证据证明结构性约束，再固定不变量与所有权；把迁移拆成能独立成立的中间状态；用确定模型、真实指标和数据核对驱动灰度；最后以旧路径删除和运行责任移交作为完成标志。

成熟的架构不是永远正确的静态答案，而是一套在信息不完整、流量变化和故障发生时仍能做出受约束决定的机制。只要事实源清楚、失败语义明确、观测能够验证、回滚路径仍然真实，系统就有继续演进的资格。