文件检索服务全链路：元数据索引、中文分词与限流运维

做文件检索这件事我前前后后折腾过三个版本最早是一个只给自己用的本地文件索引脚本后来扩展成团队内部资料检索再后来帮人评估过一个面向公众的网盘搜索网站项目。三次经历下来最大的感受是——技术难度远没有想象中高真正难的是在能搜到和该不该被搜到之间划线。很多人一上来就想着爬虫怎么写、索引怎么建结果站点跑到第三天就被投诉、被限流、被上游封掉前面搭的东西全白费。所以我这篇不打算只讲技术而是把定位、采集、索引、接口、前端、运维整条链路按我实际做过的顺序拆开讲重点讲每一步为什么这么选、哪些地方容易翻车。适合两类人看一是想自己搭一个文件检索服务的开发者二是手上有大量分散文件、想做个内部搜索入口的团队。哪怕你只是想搞清楚搜索引擎到底怎么把一堆文件名变成可检索的东西看完也能自己动手跑一个最小可用版本出来。1. 动手之前先把搜什么定死定位与合规边界1.1 网盘搜索的三种形态技术栈完全不同很多人把网盘搜索网站当成一个东西其实这里面至少是三种完全不同的产品形态选错了形态后面所有的技术选型都是白费。第一种是个人/团队文件索引。你把散落在各个网盘账号、不同目录、不同共享空间里的文件元数据文件名、大小、修改时间、所在路径、分享状态同步到自己维护的一个索引库里只给自己或团队成员用。这种形态不涉及公开采集数据源是授权过的技术上就是个增量同步 全文检索一个 SQLite 加 FTS5 或者单机 Meilisearch 就能扛住几十万条。第二种是公开资源导航。它不存文件甚至不做全量采集而是维护一份人工审核过的公开分享页面清单提供分类浏览和关键词跳转。这种形态的核心工作量在审核和分类不在技术索引量可能只有几万条但每一条都要有人看过。第三种是聚合检索。从公开可访问的页面上采集分享链接的元数据建成索引对外提供搜索。这种形态技术复杂度最高也最容易踩线——采集边界、更新频率、失效链接处理、投诉响应每一项都得有明确策略。我在第一次做的时候就犯过混形态的错本想做第二种结果爬虫写顺手了变成第三种站点的定位一下子就模糊了。后来我把三者的差异列了个表每次启动新项目都先对一遍形态数据来源索引量级主要技术难点主要风险点个人/团队索引自有账号授权同步万到百万级增量同步一致性权限隔离公开导航人工审核录入千到万级分类体系维护链接失效聚合检索公开页面元数据采集十万到千万级采集调度与索引更新采集边界、投诉响应形态定不下来后面所有决策都是摇摆的。比如你做的是第一种那就不需要分布式爬虫、不需要反爬对抗、不需要内容审核队列你做的是第三种那索引重建、失效检测、投诉处理链路一个都不能少。我见过一个团队用聚合检索的架构去做内部文件搜索结果光爬虫调度就写了两个月实际上完全没必要。1.2 为什么只索引元数据是这类站点的生存线这条是我踩过最深的坑之后总结出来的任何文件检索服务索引层和存储层必须彻底分开。所谓只索引元数据指的是你的数据库里只保留文件名、文件类型、大小、创建时间、来源页面地址、可访问状态这些描述性字段绝不缓存文件本体也不提供绕过来源页面直接获取文件内容的通道。用户搜到结果之后点击跳转到原始来源页面由来源方决定是否允许访问。这样做有三个实打实的好处不只是为了合规好看第一是存储成本。一个索引条目大概 300 到 800 字节一百万条也就几百兆一台小机器完全放得下。你要是缓存文件本体哪怕只缓存缩略图和预览片段容量也会瞬间失控。第二是失效处理简单。文件本体被删了你没法感知但元数据里的来源页面可访问状态可以定期探测失效就打标记或者下线用户搜到的结果不会大量 404。第三是责任边界清晰。你只描述某处存在一个叫这个名字的文件不参与分发来源方删除之后你的索引跟着失效链路是闭合的。提示如果你在设计阶段就规划了文件预览在线解压直链接口这类功能几乎可以肯定这个架构迟早要推倒重来。这些功能的成本和法律风险都远高于搜索本身收益却很低。1.3 上线前必须自己过的几道检查我在第二次做这类项目时给自己定了一个上线前清单后来每次都会拿出来对一遍。这个清单不涉及任何具体法规条文纯粹是从工程可控性角度出发的自我检查采集来源是否全部是无需登录即可访问的公开页面有没有任何一步是绕过访问控制的是否遵守了来源站点的 robots 约定和访问频率限制有没有并发过高导致对方服务受影响的可能索引里是否存在文件本体、缩略图、内容摘要等非元数据字段结果页是否有明确的内容由来源方提供的标识用户是否能清楚知道点击后会跳到哪里是否有可用的投诉/下架通道收到反馈后多久能把某条索引摘掉这个流程是否演练过查询接口是否有频率限制单个 IP 每分钟能发多少次请求超了怎么处理是否有敏感词过滤用户搜某些词时返回空结果而不是报错最后一条尤其容易被忽略。早期的版本我压根没做关键词过滤结果某些明显不该被检索的词也能搜出东西来虽然后来加了黑名单但日志里留下的记录清理起来很麻烦。正确做法是在查询入口和索引写入两个环节都做过滤前者挡住用户输入后者挡住脏数据入库。2. 元数据从哪来采集层的设计与取舍2.1 采集的边界感比采集能力更重要聊采集之前先说清楚一件事这一节讲的所有内容前提都是目标页面公开可访问、且对方没有明确拒绝采集。任何需要登录、需要绕过验证、需要伪造身份才能拿到的数据都不在讨论范围内。这不是保守是因为绕过访问控制拿到的数据你既没法保证稳定性对方一改策略你就断供也没法保证可持续性量越大风险越高。在合法边界内元数据的来源其实有这么几类公开的分享页面很多服务提供分享链接未设密码的分享页面对任何人可见页面里就包含文件名、大小等信息公开的站点地图和目录页有些资源站本身提供分类列表这类页面结构规整是最理想的采集对象开放数据接口少数服务提供公开的检索接口有明确的调用配额用户主动提交让用户提交自己的公开分享链接审核后入库这条路的量小但质量最高我在实际项目里用户主动提交 公开目录页这两类占了入库量的绝大部分反而是全网扫分享页这种听起来最猛的方式投入产出比最低——因为大量分享页面是私有的、带密码的、早就失效的扫一万个页面可能只有几十条可用数据还容易触发对方的风控。2.2 爬虫调度队列、去重、增量这三件事采集层的核心其实就三个问题任务怎么排队、重复的怎么去掉、已经采过的怎么知道要不要重采。这三个问题不解决爬虫跑到一定规模必然失控。我用的是一套很朴素的组合Redis 做任务队列布隆过滤器做 URL 去重MySQL 存采集状态。整体结构如下# 任务入队只入队未访问过的 URL import redis from bloom_filter2 import BloomFilter # 内存布隆过滤器 r redis.Redis(host127.0.0.1, port6379, db0) bf BloomFilter(max_elements50_000_000, error_rate0.001) def push_task(url, priority5): # 布隆过滤器判断可能访问过误判率千分之一 if url in bf: return False bf.add(url) # 用有序集合做优先级队列score 越小越优先 r.zadd(crawl:queue, {url: priority}) return True这里有几个细节值得说为什么用有序集合而不是列表。列表只能先进先出但采集任务是有优先级的——新发现的目录页应该优先于深度翻页即将失效的链接应该优先于陈年老链接。用ZADD加分数消费端ZPOPMIN取最小分天然就是个优先队列。布隆过滤器的误判要接受。它只会误判存在把没访问过的当成访问过不会误判不存在。也就是说少量 URL 会被漏采但绝不会重复采。对于百万级 URL 的场景千分之一的误判率意味着漏掉一千条左右完全可以接受。真要精确去重就把 URL 做 MD5 前 16 位存到 MySQL 的唯一索引里代价是每次都要查库。增量策略比全量重采重要得多。早期我图省事每周全量重跑一遍结果跑一次要十几个小时中途挂了还得从头来。后来改成按上次探测时间排序只重采超过 7 天没探测的并且把探测结果分成三态可访问、已失效、需要复核。失效的连续三次探测都失败才真正下线避免因为对方临时故障误杀。2.3 文件名的清洗决定了搜索质量的天花板这一步是整个项目里最不起眼、但影响最大的环节。原始采集回来的文件名是这样的【某某工作室】2023年度合集[高清版]完整- 第01集.mkv [某某组] 某某作品 1080P 中文字幕.mp4 某某资料 最终版(1)(1).zip如果直接把这些字符串塞进索引用户搜2023能搜到一堆噪音搜第01集又会因为全角半角、空格差异匹配不上。所以要有一层规范化处理。我做的规范化包括这几步全角转半角统一括号、冒号、数字去除装饰性符号把【】[]()这些统一替换成空格大小写归一扩展名和英文单词统一转小写连续空白折叠多个空格合成一个提取结构化字段用正则捞出年份、分辨率、集数、语言标记单独存成字段而不是留在标题里import re import unicodedata def normalize_filename(name: str) - dict: # 全角转半角 name unicodedata.normalize(NFKC, name) # 装饰符号统一成空格 name re.sub(r[【】\[\]()《》], , name) # 提取扩展名 ext if . in name: base, ext name.rsplit(., 1) if len(ext) 5 and ext.isalnum(): name, ext base, ext.lower() else: ext # 提取年份1900-2099 years re.findall(r\b(19\d{2}|20\d{2})\b, name) # 提取分辨率标记 res re.findall(r\b(480|720|1080|2160)[pPiI]\b, name, re.I) # 折叠空白 clean re.sub(r\s, , name).strip().lower() return { clean_name: clean, ext: ext, year: years[0] if years else None, resolution: res[0].lower() p if res else None, }为什么要把年份、分辨率单独抽出来。因为用户搜2023 1080p这种行为非常普遍如果这些都混在标题字符串里做全文匹配相关度会非常差——一个标题里恰好含2023但其实是文件大小 2023KB 的条目会排到真正 2023 年发布的内容前面。抽成独立字段之后就可以做精确过滤而不是模糊匹配。我实测下来加了这一层清洗之后同一个查询的相关度主观评分大概能提升三成以上尤其是那种关键词很短、结果很多的查询。3. 索引与检索为什么最后我没用数据库直接查3.1 量级决定选型别一上来就上重型方案选型这件事我的原则永远是按数据量倒推而不是按流行度选。我做过三档索引量级方案单次查询耗时说明10 万以内SQLite FTS55~30ms单文件零运维最省事100 万以内Meilisearch 单机3~20ms自带中文分词和拼写容错1000 万以上OpenSearch/ES 集群20~100ms需要分片规划最开始我用的是 MySQL 的LIKE %关键词%十万条数据的时候勉强能跑五十万条的时候一个查询要两秒多因为前置通配符导致索引完全失效每次都是全表扫描。这个坑很小但很典型很多人以为给字段加个索引就行了却不知道前置通配符会让 B 树索引彻底失效。换成 FTS5 之后同样的查询降到十几毫秒。FTS5 是 SQLite 内置的全文检索模块用倒排索引实现建表非常简单-- 建虚拟表tokenize 用 unicode61 处理多语言 CREATE VIRTUAL TABLE file_fts USING fts5( clean_name, tokenize unicode61 remove_diacritics 2 ); -- 插入数据时同步写入 FTS 表 INSERT INTO file_fts(rowid, clean_name) SELECT id, clean_name FROM files; -- 查询按相关度排序bm25 越低越相关 SELECT f.id, f.clean_name, bm25(file_fts) AS score FROM file_fts JOIN files f ON f.id file_fts.rowid WHERE file_fts MATCH 关键词 ORDER BY score LIMIT 20;数据量涨到百万级之后FTS5 的写入性能开始成为瓶颈——每次插入都要更新倒排表批量导入的时候速度掉得很厉害。这时候才考虑换 Meilisearch 这类独立服务。我的建议是先用 FTS5 把整个链路跑通确认产品形态成立之后再迁移不要一开始就上分布式否则光是集群运维就能把你拖死。3.2 中文分词的坑文件名其实不是自然语言这是我在这个项目里踩得最深的一个技术坑。标准的中文分词器比如 IK、jieba是按自然语言的词边界切的。但文件名不是自然语言它是一堆关键词的堆砌没有语法结构。比如某某项目2023年度总结报告最终版自然语言分词可能切成某某/项目/2023/年度/总结/报告/最终/版用户搜年度总结能匹配上但用户搜项目总结就匹配不上——因为项目和总结之间隔了别的词。更麻烦的是中英文混排和缩写。用户搜AI绘画标题里写的是人工智能绘画语义上是一回事字面上完全匹配不上。我最后的解决方案是双路索引一路用分词后的词项处理正常的关键词查询一路用二元切分bigram把年度总结切成年度度总总结虽然索引体积会膨胀两三倍但能保证任意两字组合都能命中def bigram_tokenize(text: str) - list[str]: 中文二元切分 英文按空格切用于兜底匹配 tokens [] buf for ch in text: if \u4e00 ch \u9fff: # 中文字符 if buf: tokens.append(buf) buf tokens.append(ch) elif ch.isalnum(): buf ch else: if buf: tokens.append(buf) buf if buf: tokens.append(buf) # 中文相邻字组合 result [] for i, t in enumerate(tokens): result.append(t) if i 1 len(tokens) and len(t) 1 and len(tokens[i 1]) 1: result.append(t tokens[i 1]) return result代价是索引体积。一百万条记录纯分词索引大概 200MB加了 bigram 之后涨到 600MB 左右。用磁盘换召回率我觉得这个交易很划算因为用户搜不到东西的挫败感远比多花几百兆硬盘严重。另外一个技巧是建同义词表。把常见的等价表达维护成一张小表查询时自动扩展。比如高清和1080p、合集和全集、资料和文档。这张表我是一边看搜索日志一边手工加的加了两百多条之后零结果查询的比例从 12% 降到了 4% 以下。3.3 排序不只是相关度热度、时间、可用性都要算进去纯按相关度排序用户体验会很差。原因很简单相关度只看文本匹配不看内容质量。一个标题里恰好堆满关键词的失效链接会排在一个标题朴素但真实可用的条目前面。我的排序公式大概是这样final_score relevance * 0.6 hot_score * 0.2 freshness * 0.15 availability * 0.05其中relevance来自 BM25做归一化处理hot_score是近 7 天的点击量取对数后归一化用对数是为了防止个别爆款条目长期霸榜freshness按exp(-λ * 天数)衰减λ 取 0.02 左右大概一个月衰减到 55%availability是最近一次探测的可访问状态可访问为 1未探测为 0.5失效为 0这几项权重是可以调的但不要频繁调。我一开始每天都改权重结果搜索结果的排序天天变用户根本建立不起稳定的预期。后来固定成上面这组每季度review一次反而效果更好。3.4 索引重建别名切换是零停机的关键索引需要定期全量重建比如改了分词策略、加了新字段重建期间不能停机这是基本要求。做法是双索引 别名切换# 1. 建一个新索引写入全量数据 curl -X PUT localhost:9200/files_v2 -H Content-Type: application/json -d { settings: { number_of_shards: 3, number_of_replicas: 1 }, mappings: { properties: { clean_name: { type: text } } } } # 2. 全量导入这一步可能跑几小时期间旧索引继续服务 python import_full.py --target files_v2 # 3. 原子切换别名毫秒级完成 curl -X POST localhost:9200/_aliases -H Content-Type: application/json -d { actions: [ { remove: { index: files_v1, alias: files } }, { add: { index: files_v2, alias: files } } ] } # 4. 观察几天没问题再删旧索引 curl -X DELETE localhost:9200/files_v1应用层永远只查别名files不查具体索引名。这是整个方案的核心别名切换是原子的切换瞬间所有请求就走新索引了不需要重启任何服务。我第一次做重建的时候犯过一个错直接把旧索引删了重建结果重建了四个小时站点整整挂了四个小时。用户当天就走了大半。从那以后我就把别名切换写进了运维脚本再也没出过问题。4. 后端接口限流和反滥用是逃不掉的4.1 查询接口的字段设计要克制接口设计上我的原则是返回字段越少越好。早期我把数据库里所有字段都返回给前端包括内部分类 ID、采集时间戳、来源网站的原始 URL 参数结果被人拿去做了二次采集——人家直接拿你的接口当数据源一晚上把你全站数据拉走。现在的返回结构大概是这样{ code: 0, data: { total: 1284, items: [ { id: f_8a3c9e, name: 某项目2023年度总结报告.pdf, size_text: 12.4 MB, type: pdf, updated: 2023-11-20, source_label: 公开目录页, available: true } ] } }注意几点ID 用不可枚举的随机串不用自增 ID。自增 ID 太容易被人按序遍历等于把你的全量数据白送不返回原始 URL只返回一个内部跳转 ID用户点击走/go/{id}服务端做 302 跳转顺便记一次点击不返回文件大小字节数只返回格式化后的文本减少信息泄露不返回任何内部字段尤其是不返回采集时间和采集器标识这个改动看起来微小但对防止数据被批量拉取非常有效。4.2 缓存分层热词预加载比想象中有效搜索接口的流量分布极其不均匀。我统计过自己的日志前 100 个查询词占了总查询量的 60% 以上前 10000 个占了 90%。这种情况下做热词缓存收益巨大。我的做法是三层本地内存缓存进程内 LRU存 top 200 查询词的结果命中率大概 25%响应时间 1ms 以内Redis 缓存存 top 50000 查询词的结果TTL 20 分钟命中率再增加 40% 左右回源查索引剩下 35% 的请求走这里import hashlib import json import redis r redis.Redis(host127.0.0.1, port6379, db1) def search_cached(keyword: str, page: int 1): key_raw f{keyword.strip().lower()}:{page} cache_key s: hashlib.md5(key_raw.encode()).hexdigest()[:16] cached r.get(cache_key) if cached: return json.loads(cached) result do_real_search(keyword, page) # 只有结果数量足够才缓存避免缓存空结果导致永久空 if result[total] 0: r.setex(cache_key, 1200, json.dumps(result, ensure_asciiFalse)) return result一个坑空结果千万不要缓存或者只给很短 TTL 比如 60 秒。我早期设置成所有结果都缓存 20 分钟结果刚上线的那几天索引里数据还很少大量查询返回空这些空结果被缓存下来后来数据补全了用户还是搜不到东西排查了半天才发现是缓存的问题。另一个坑缓存键要考虑分页和排序参数。只按关键词做 key用户翻到第二页会拿到第一页的结果。必须把页码、排序方式这些都拼进 key 里。4.3 被刷了之后我才开始做限流这个事说起来有点丢人。站点上线第二周有人写了个脚本按字母序把所有查询词刷了一遍想把我全站数据拉下来。因为我没做任何限流那次直接把数据库打到了连接数上限站点挂了两个小时。之后我补了三层防护第一层是 Nginx 层的粗粒度限流limit_req_zone $binary_remote_addr zonesearch:10m rate20r/m; limit_req_zone $server_name zoneglobal:10m rate500r/s; server { location /api/search { limit_req zonesearch burst5 nodelay; limit_req zoneglobal burst100; limit_req_status 429; proxy_pass http://backend; } }单个 IP 每分钟 20 次突发允许 5 次。这个阈值对正常用户完全够用没人会一分钟搜 20 次但能挡住绝大多数脚本。第二层是应用层的令牌桶按 IP 用户标识如果有做细粒度控制主要防的是分布在多个 IP 上的慢速刷取。令牌桶比漏桶更适合搜索场景因为它允许短时突发。第三层是行为检测记录每个 IP 的查询词序列如果发现连续 100 次查询的词都是按字母序递增的或者每次都能翻到很深的页码直接临时封禁。这一层容易误伤所以只做临时封禁比如 30 分钟不做永久封禁。注意限流阈值定得太严会把正常用户也挡住尤其是那种打开了多个标签页同时搜索的用户。我一开始设的是每分钟 10 次结果投诉说搜着搜着就不让搜了后来放宽到 20 次才消停。上线前最好自己用真实使用节奏压一遍。5. 前端体验让用户在三次输入之内找到东西5.1 搜索建议的防抖和取消请求搜索框的即时建议看起来简单做不好就是灾难。我见过最差的实现是每敲一个字符发一次请求敲项目总结报告七个字发了七次请求每次返回一堆结果最后显示的是第一个字符的结果因为请求乱序返回。正确的做法是防抖 请求取消let controller null; let timer null; function onInput(e) { const q e.target.value.trim(); clearTimeout(timer); if (controller) controller.abort(); // 取消上一次未完成的请求 if (q.length 2) { renderSuggestions([]); return; } timer setTimeout(async () { controller new AbortController(); try { const res await fetch(/api/suggest?q${encodeURIComponent(q)}, { signal: controller.signal, }); const data await res.json(); renderSuggestions(data.items); } catch (err) { if (err.name ! AbortError) console.error(err); } }, 250); }防抖延迟 250 毫秒是个比较甜的点。低于 150 毫秒用户还没打完就发请求了高于 400 毫秒用户会觉得输入有延迟感。建议词的来源不要直接用搜索日志。日志里全是长尾词直接展示会很奇怪。我的做法是只取最近 7 天查询次数超过 50 次的词按前缀匹配取 top 8再加上几条同义词扩展。这样既有热度保证又不会推荐一堆只被搜过一次的怪词。5.2 结果页的信息密度比美观重要得多这个页面我改过七版最后发现用户真正关心的就三件事文件名够不够清楚、这东西看起来是不是我要的、点进去能不能打开。所以每一条结果的信息排布是文件名高亮匹配词一行灰色小字类型、大小、更新时间、来源标识右上角一个可用性状态标记关键词高亮必须做而且要处理分词边界。用户搜项目总结标题是某项目2023年度总结报告高亮的时候应该把项目和总结分别高亮而不是找连续的项目总结四个字。做法是拿分词结果的每个词项去标题里找逐个替换成高亮标签。结果数量多的时候必须做分组。一百万条数据搜报告能出十万条结果全部平铺毫无意义。我加了一层按文件类型聚合的筛选栏文档、视频、压缩包、其他用户点一下就能把范围缩到万级以内。每页条数不要太多。我做的是默认 20 条最多支持到 50 条。早期设成 100 条一页结果页面渲染慢、用户也不看纯属浪费。5.3 零结果的兜底决定用户会不会再来零结果页是绝大多数搜索产品做得最烂的地方。用户搜不到东西页面就一句没有找到相关内容然后就走了。我做了三层兜底第一层是查询改写。用户搜2023年总结如果零结果自动去掉年字再搜一次搜项目 总结带空格如果零结果去掉空格变成一个词再搜。这些规则很简单但能把零结果率降两个百分点左右。第二层是模糊匹配。用编辑距离做一次容错查询允许一个字符的差异。比如用户把某个词打错了一个字也能搜到。这一层要用在最后否则会引入大量噪音。第三层是相关推荐。从查询词里提取出能匹配上的部分词项给出你是不是想找 XX的链接同时展示几条热门内容。用户在这里流失率最高但也最容易挽回——只要给他一个能点的东西很多人就留下了。我统计过改造前后的数据零结果页的跳出率从 91% 降到了 68%虽然还是很高但已经好太多了。6. 部署运维小成本方案和几次真实故障复盘6.1 一台四核八G能撑到什么程度很多人一听说搜索网站就觉得要上集群实际上百万级索引、日均几万查询一台四核八G的机器完全够用。我的实际配置应用服务2 个进程跑 API占用约 800MB 内存索引服务Meilisearch 单机百万条索引占用约 1.2GB 内存缓存Redis限制 512MB淘汰策略 LRU数据库SQLite存采集状态和点击日志文件约 3GB反向代理Nginx做限流、静态文件、gzip整体内存占用稳定在 5.5GB 左右CPU 峰值在查询量突增时会到 70%平时 10% 以下。磁盘用 80GB SSD索引加数据库加上日志轮转后大概占 15GB。这个配置下单机能扛住每秒 300 次左右的查询。再往上就要考虑加机器了但说实话除非你的站点已经小有名气否则这个量级远远够用。日志我建议一定要做轮转按天切割保留 14 天。我有一次忘了配轮转日志文件涨到 40GB 把磁盘写满了整个服务全部挂掉从报警到恢复用了半小时。6.2 那几次让我印象深刻的故障故障一索引和数据库不同步搜出来的条目点进去 404现象是用户搜到结果点进去提示内容不存在。排查下来发现数据库里的条目已经被标记删除但索引里没同步更新。根本原因是删除操作只写了数据库忘了更新索引。修复方案是把所有涉及状态变更的操作都改成先写数据库再发一条消息到队列由消费者异步更新索引同时在索引里加了一个available字段查询时加过滤条件available:true。故障二某个查询词把内存打爆有一次监控报警说内存占用 98%服务响应超时。登录上去一看是一个查询词触发了超长正则匹配把 CPU 打满了同时请求堆积导致内存暴涨。原因是我的查询改写逻辑里有个用户可控的正则构造用户输入特殊字符时正则引擎回溯爆炸。修复很简单所有用户输入在进入正则之前先转义并且给正则匹配加超时限制。故障三来源站点改了页面结构采集全量失败这个最典型。采集脚本依赖特定的 HTML 结构提取文件名对方改版之后所有采集任务都失败但脚本没有明显的错误日志因为它成功执行了只是提取到 0 条数据。后来我加了一个采集健康度监控每次采集任务完成后统计本次提取到的有效条数如果连续三次都是 0就发告警。这个监控非常简单但救过我好几次。6.3 监控要看哪些指标我的监控面板上就四个核心指标多了也看不过来指标正常范围异常时的含义查询 P99 延迟 200ms索引或缓存出问题零结果率 5%索引数据可能缺失429 响应占比 3%限流过严或遭刷采集有效条数/小时相对稳定来源改版或网络异常零结果率这个指标特别值得盯。它突然升高通常意味着索引出了问题比如重建期间的别名没切对或者是采集停了导致新数据进不来。我设的告警阈值是 15 分钟窗口内零结果率超过 10%触发过一次果然是索引别名切错了。6.4 关于内容反馈通道的一点经验最后一件事也是我认为最重要的一件事必须有一个真实可用的反馈通道而且必须演练过。不是页脚放个邮箱就完事了。我设计的是一个表单提交后进入队列后台有一个处理界面运营人员可以一键把某条索引下线。关键指标是从提交到下线的时间我给自己定的目标是 24 小时内。更重要的是定期演练。我每个月会自己提一条测试反馈走完整流程看看是不是真的能在 24 小时内下线。第一次演练就发现表单提交后其实没有通知任何人邮件进了一个没人看的邮箱。这种问题不演练永远发现不了。做这类服务技术上其实没有多难的东西难的是把每一个环节的边界都守好把每一个故障都当回事。我做了三年多最大的体会是能搜到多少是能力问题该不该被搜到是底线问题后者永远优先于前者。当你发现某个功能能让搜索结果多出几十万条但需要模糊一下边界的时候最好的选择往往是放弃它。少几十万条数据站点照样跑边界模糊了前面所有工作可能一夜归零。这个判断我做过不止一次每次事后看都是对的。