1. 为什么状态恢复这么难先看清“双写”的底牌前段时间排查了一个很典型的问题某状态存储组件 Hermes 在进程被强制杀掉之后主数据通过 WAL 完整恢复了但全文搜索FTSFull-Text Search却漏掉了最近半小时写入的几百条记录。更麻烦的是从外表看一切正常——服务能启动、接口能响应就是搜索关键词时少了一截数据。这个案例又一次印证了我的判断带全文索引的状态型存储恢复工作不是“跑一遍日志重放”那么简单你得同时守住主存储和 FTS 索引两条线。这也是标题里“双重防线”的由来。1.1 Hermes 的存储侧与索引侧长什么样Hermes 是我这边负责维护的一个内部状态存储组件核心定位是“写入即查”——业务方把结构化状态数据写进来同时能用主键 Key 精确查询也能按若干文本字段做全文检索。这类系统在市面上并不少见日志检索、配置中心、工单系统都会有类似诉求既要有 KV 一样的可靠恢复能力又要有搜索引擎一样的文本召回能力。它的底层结构大致分成两块主存储侧采用 WALWrite-Ahead Log加上内存表定期落盘的经典设计。写入先追加日志再更新内存表内存表达到阈值后冻结并刷成不可变数据文件。索引侧持有倒排索引Inverted Index每次写入时除了写主存储还要同步更新词项到文档 ID 的映射关系。为了避免阻塞主链路索引写入会先落一条索引日志可以理解成 FTS 自己的 mini WAL再异步刷进倒排段文件。这个设计的正常路径非常顺滑写入一条数据主存储和索引几乎同时更新。但崩溃恢复时问题就来了主存储和索引侧都有各自的日志、各自的刷盘节奏、各自的一致性边界。两边没有对齐的话恢复完主存储索引却停留在旧状态于是“数据在但搜不到”的诡异故障就出现了。1.2 崩溃的三种典型姿态我复盘过几次故障后发现崩溃不是一个单一场景至少得区分三种姿态第一干净退出。进程收到终止信号后主动停服先 flush 索引段再落主存储快照最后关闭 WAL。这种退出方式留给恢复的负担最小——两边数据基本一致。但生产环境里很多崩溃根本没有优雅退出的机会。第二半写崩溃。这是最折腾人的一种。比如索引日志写了一半进程就没了。重启后你看到索引日志尾部有半截记录不知道该不该回放也不敢随便回放。这个状态处理不好轻则索引重复词项重则重启后直接加载失败。第三磁盘瞬时失效。磁盘 IO 抖动导致某个倒排段刷盘失败但主存储写入已经提交了。这种情况最阴险因为日志文件看起来是完整的只是段文件缺失或损坏。恢复逻辑如果只盯着日志根本发现不了问题。正是基于这三种崩溃姿态我们设计了“恢复水位线 双通道对账”的整体思路。简单说恢复主数据是一道防线恢复 FTS 索引是第二道防线两道防线之间有明确的对账流程彼此验证。提示恢复方案里最重要的不是“每个组件自己能恢复”而是“两个组件恢复完成后能对上账”。这是我这几次踩坑之后最大的体会。2. 第一道防线主数据恢复与一致性点判定2.1 WAL 重放的正确姿势先聊主存储侧。Hermes 的 WAL 是分段存储的每段固定大小写完一段再开下一段。正常运行时每条写入会先 append 到当前段并带上一个全局自增序列号简写为 seq。这个 seq 是整个系统里最重要的对账线索。恢复时最简单的思路是从第一段 WAL 一路重放到最后一段。但直接这么做有几个问题如果最后一段的尾部是崩溃时残留的半条记录直接按二进制解析会报错甚至把错误数据写进内存表。WAL 里可能包含了一些已经被落盘的旧数据重复重放不仅浪费时间还会让内存表膨胀触发多余的合并操作。所以正确做法是先定位“恢复起点”再从起点向后回放。Hermes 在内存表冻结落盘时会在一个独立的元数据文件里记录当前已经完整落盘的日志位置。这个位置即是恢复起点。重启后从日志文件头部开始扫描跨过这个位置再从之后的第一条完整记录继续解析。遇到尾部半截记录统一截断丢弃不解析、不回放、不报错。这里有一个细节我反复跟团队强调截断半截记录之前必须先把截断点持久化到元数据文件。否则下次崩溃后同一个位置可能再次被识别为“完整记录”导致重复回放。虽然重复回放对 KV 数据不致命但它会污染后面 FTS 侧的对账逻辑。2.2 一致性点恢复的“起跑线”WAL 回放只能保证主存储自身一致但主存储恢复到什么程度FTS 侧需要跟着对齐到哪个时间点必须有个明确参照物。我们内部把这个参照物叫一致性点Consistent Point。一致性点的生成逻辑是这样的系统定期默认 5 秒或在内存表即将冻结时记录一个“当前已确认写入的最大 seq”然后把这个 seq 连同时间戳写进元数据文件。这个动作叫“封点”。封点完成之后主存储侧所有小于等于该 seq 的数据要么已经落盘要么日志完整可回放绝对不允许出现“半截更新”。为什么一致性点很关键因为它给了恢复一个明确的“起跑线”。主存储恢复时重放到一致性点对应的 seq 即可不追求一定回放到日志的最后一条。FTS 索引恢复时也不用无脑扫完整的索引日志只需要把索引状态推进到“包含一致性点之前的所有已确认写入”这个水平。这样做有两个好处一是恢复时间可控。不用每次崩溃都把全量日志重放一遍只需重放一致性点之后的增量。二是两边目标一致。主存储、FTS 索引都朝着同一个 seq 推进而不是各自恢复各自的最后对不齐。实际操作中我会建议把一致性点写入和内存表落盘放在同一个事务边界里处理。也就是说要么一致点更新和磁盘文件刷新一起成功要么一起失败。否则就会出现元数据声称已经封点到 seq10240但落盘文件里实际只包含 seq10200 的数据恢复时直接产生空洞。注意一致性点必须覆盖“主存储已确认但可能尚未落盘”的数据。如果主存储已经向客户端返回写入成功一致性点还没推进到该写入的 seq崩溃后这条写入就会被恢复流程判定为“不需要恢复”造成数据丢失。这块逻辑是排查数据丢漏的第一顺位。3. 第二道防线FTS 索引修复与增量重建3.1 三种修复策略怎么选主存储恢复完成只是第一步接下来面对的是 FTS 索引。这层防线失败的话整体恢复体验会非常割裂数据查得到、搜不到调用方会以为系统数据丢了。FTS 索引修复我总结过三种策略按投入产出比排序增量修复、全量重建、双写补偿。增量修复适用于“索引主体完好只是尾部缺了一段”的场景。实现上依赖一个关键设计——索引侧的 commit 标记Index Commit Marker。每次倒排段刷盘成功索引侧会记录该段已经包含的最大 seq。重启后加载所有索引段拿到最新的已提交 seq再和一致性点对比。差多少就从主存储里批量读取对应的数据记录重新分词、合并进倒排索引。这个方案恢复最快正常情况下几秒钟就能搞定。全量重建适用场景更极端索引段文件损坏、提交标记丢失、或者是恢复逻辑本身有 bug 导致索引状态无法信任。这时候最稳妥的办法就是遍历主存储全部数据按倒排索引格式重建文件。它能保证最后一定一致但代价是耗时与全量数据规模成正比。所以我们在生产环境里平时就保留一份最近一次全量重建的索引快照配合增量数据文件当天级别的崩溃可以直接读取快照恢复不需要从头扫。双写补偿不是我推荐的常规策略但它是一个很重要的兜底手段。正常写入路径上主存储的数据记录本身就携带原始文本字段。FTS 索引重建时并不依赖索引日志而是直接从主存储的原始字段重新分词。这等于把主存储当成索引的“真相源”。设计时注意保证字段不能截断、不能压缩变形否则重建出来和原始写入不一致。3.2 索引脱落检测怎么快速判断该修哪里恢复之前先得知道索引到底哪里掉了。盲目重建是大忌浪费时间不说还可能掩盖真正的故障原因。我实践下来比较可靠的检测手段有两个。第一个手段是文档计数比对。主存储侧统计一致性点之前的有效记录数FTS 侧统计倒排索引里的文档总数。两个数字不一样不用怀疑肯定有一边掉了数据。这个比对了不起眼但最直观也最适合放在监控告警里。第二个手段是 term 抽样比对。从一致性点之前的记录里随机抽一批文本字段分析出高频词项比如“订单”“故障”“工单系统”这类再到倒排索引里查这些词项命中的文档 ID反向比对主存储里对应主键是否存在。抽样能发现一种很隐蔽的问题——索引文档数相同但内容映射错位了。我自己就遇到过这种错位索引段文件重复加载了一次导致某些 term 下挂着重复的文档 ID文档总数从表面看是对的但检索结果里出现大量重复项。单纯计数对比发现不了必须拿具体词项去索引里抽查命中集合。检测时机上我建议主存储恢复结束、服务对外提供查询之前强制执行一次对账。不要指望用户反馈“搜索少了数据”才去查。Hermes 的做法是在恢复编排里固定插入一步“索引承诺校验”只有一致性通过才把服务标记为 Ready 状态。4. 恢复编排实战四阶段状态机4.1 检查、回放、重建、切流的完整流程把两重防线落到具体实现上不能靠零散的恢复代码要有一个可观测、可中断、可重入的编排流程。Hermes 这边的恢复状态机用了四阶段设计检查 → 回放 → 重建 → 切流。每个阶段都有明确的输入、输出和失败处理。阶段一检查CHECKING。启动时扫描所有元数据文件、WAL 分段文件、索引段文件、快照文件建立“可见文件清单”。同时读取出最后一次一致性点、最后一次已提交索引 seq。这个阶段不修改任何数据只做盘点。如果发现关键文件缺失直接进入“重建模式”而不是硬着头皮回放。阶段二回放REPLAYING。从一致性点指向的 WAL 位置开始按序回放到日志尾部。每条回放记录除了更新主存储还会把它的 seq 暂存进一个“待同步队列”。因为后续 FTS 重建需要知道哪些数据是索引侧缺失的这个队列就是增量修复的输入。回放过程中如果解析到损坏的日志块记录损坏位置并跳过尽可能回放完所有可解析的数据。阶段三重建REBUILDING。这个阶段做了一个全局判断先比较主存储已恢复的最大 seq 和索引侧已提交的最大 seq。差值小于某个阈值比如 5000 条走增量修复差值很大或索引文件有损坏标记走全量重建。重建过程中对每个批次的数据做分词、合并倒排段并同步更新索引提交标记。这里强调一点重建不是全局一次性做而是按“批次断点”执行每个批次完成就把进度写入恢复元数据。这样万一重建途中再次崩溃不需要从头再来。阶段四切流SERVING。所有恢复动作完成执行前面提到的索引承诺校验。校验通过后把服务状态从 Recovering 切换为 Ready开始接受外部读写流量。如果校验失败停在 Serving 前保留现场供排查同时自动触发告警。这里不要强制通过否则带着不一致的索引对外服务后面排查成本更高。4.2 参数配置与粗略估算恢复流程里涉及一批可以调的参数直接分享我们实际用的一套默认值回放并发度2因为 WAL 回放依赖顺序语义并发开太大反而容易乱序。增量重建批次大小1000 条/批。太大内存压力高太小提交标记频繁刷盘浪费时间。全量重建并发度48配合分片倒排段写入。单批超时30 秒超过则按失败批次重试最多重试 3 次。索引承诺校验抽样率不小于 1%且最低抽样 1000 条。恢复时间怎么估算我习惯用一个粗算公式全量重建时长 ≈ 主存储有效数据量 ÷单节点扫描速度 × 并发度 文本总量 ÷分词吞吐 × 并发度。比如 100GB 数据单节点扫描速度约 200MB/s分词吞吐按 20MB/s 算并发度 8那么扫描需要约 64 秒分词重建需要约 640 秒整体大概 12 分钟出头。增量修复则快得多因为只需要回放一致性点之后的尾部数据一般控制在几十秒量级。提示如果业务对恢复时间RTO极度敏感建议把一致性点封点频率从 5 秒缩短到 1 秒。代价是元数据刷盘频率变高磁盘写入放大一点但能把主存储恢复范围压缩到 1 秒内的增量非常值得。5. 常见问题与排错实录5.1 重建到一半又崩溃怎么断点续传我在一次全量重建模拟演练中遇到这种情况索引重建到 37% 的时候节点突然重启。第一次写的恢复逻辑没有把“当前重建到哪个批次”持久化结果重启后又从 0% 开始。表面看功能没错但全量重建一次就是十几分钟中断一次就重来完全不可接受。解决思路很简单但很多人会忽略在重建批次的循环里每处理完一个批次先把“已完成批次编号”持久化到恢复元数据文件然后再刷新索引段。恢复启动后扫描元数据发现重建任务未完成直接从最后一个已提交批次的后续开始继续。这里的关键是“先更新元数据再刷索引段”还是“先刷索引段再更新元数据”顺序不能反。正确顺序是先刷索引段文件再更新元数据里的批次进度。因为索引段落盘有一定概率失败如果先把进度标成“已完成”索引段却丢了那断点续传就会跳过一个缺失的批次后续全对不上。反过来索引段刷成功但进度更新失败最坏情况下重启后重复重建这个批次结果也是幂等的。5.2 主数据恢复了但全文搜索查不到刚写入的记录这个现象前面提过但排查过程值得单独说一说。某次故障恢复后业务方反馈“用关键词搜不到最后几分钟创建的工单”。我先查主存储记录存在查 FTS 索引文档总数也对得上。排查了好几轮最后发现是索引提交标记停留在旧的 seq 上导致加载接口把新写入的一批倒排段当成“未提交数据”过滤掉了。根子在于索引侧提交标记的写入和倒排段文件的落盘不在同一个事务里。倒排段文件已经刷到磁盘但提交标记没跟上。恢复时加载逻辑只认提交标记所以文件虽然存在数据却不被纳入检索范围。修改方案有两个维度一是把提交标记的更新时机绑定到倒排段文件落盘成功之后并且定期强制刷盘。二是在恢复流程的检查阶段不只读提交标记还要扫描索引目录下所有段文件的真实内容范围取两者并集作为“可加载数据”。这两条都加上基本能杜绝“文件在、索引看不到”的情况。5.3 孤儿索引段占用磁盘重建时空间不够全量重建的临时文件、历史残留的孤儿索引段会在关键时刻挤占磁盘空间。我第一次跑完整套恢复流程时就吃过这个亏重建到一半磁盘写满恢复直接失败而且留下了一堆没清理干净的临时文件把磁盘空间吃得更紧。现在我们的策略是恢复流程启动时第一件事就是清理临时目录和历史孤儿段清理标准是“不属于当前任何已登记段文件的索引文件”。同时在重建阶段设置一个磁盘水位阈值低于 15% 则暂停重建先执行段文件压缩腾出空间再继续。另外建议日常做一次索引段合并Segment Merge把零碎的小段合并成较大的段。一方面查询性能会更好另一方面真到全量重建时需要处理的文件数量大幅减少失败概率也低很多。5.4 恢复日志完整但索引差异检测偶发误报还有一个小问题说出来供大家参考我们在抽样比对时用了一个随机种子但某些批次的数据都是同一个业务类型文本字段高度相似抽样出来的高频词项区分度低导致误报“索引不一致”。后来把抽样逻辑从“随机词项”改成“随机主键 该主键的全文检索反向验证”彻底解决了误报。写在最后恢复逻辑是平时就要喂出来的这套“双重防线”方案不是仅靠设计文档就能拍板的一定要靠故障演练和线上日志反复打磨。我个人的体会是恢复逻辑的复杂度向来被低估因为它平时根本不执行只有到系统已经出问题的时刻才跑出来干活。越是这种场景越需要平时把每个分支都模拟一遍。我们内部每个月都会做一次随机崩溃演练随机杀掉进程、随机删除段文件、随机截断日志然后看恢复流程能不能正确收敛。演练暴露出来的问题比代码评审多得多。如果你也在维护一个带全文索引的存储组件建议从最简单的一致性点 文档计数对比开始落地把这两条做扎实之后再逐步引入增量重建和全量重建的自动决策。最后再分享一个小技巧给恢复流程的所有关键节点都加上指标埋点阶段耗时、恢复行数、重建进度、对账结果这样每一次恢复都能变成下一次改进的输入而不是黑盒里的一个“反正恢复成功了”。