完结，地图常翻
从那条搜不到「燕麦拿铁」的 LIKE 开始，20 篇写完：倒排、分词、mapping、近实时、查询、评分、聚合、集群、分片、同步、调优。最后一篇不添新知识，只做一件事——把散落的内容拼成一张出事时能直接翻的作战地图。
作战地图：症状 → 篇目 → 第一动作
| 症状 | 第一动作 | 复习篇目 |
|---|---|---|
| 搜不到明明存在的东西 | _analyze 看分词，核对 match 与 term | 第 4、7 篇 |
| 排序结果不符合预期 | explain 拆分 _score | 第 8 篇 |
| 聚合报错或结果无意义 | 检查字段是不是 text 聚合 | 第 5、11 篇 |
| 写入后搜不到 | 确认 refresh 周期与链路差异 | 第 6 篇 |
| 翻页到深处报错 | 换 search_after 或限页 | 第 10 篇 |
| 导入速度感人 | bulk 加副本归零加关刷新 | 第 12 篇 |
| 集群灯变黄变红 | _cat/shards 看未分配分片 | 第 13 篇 |
| 内存持续上涨 | 数一数分片总数与 fielddata | 第 11、14 篇 |
| 接口 P99 飙升 | 慢日志抓现场加 profile 定位 | 第 17 篇 |
| MySQL 与 ES 对不上 | 跑对账任务查同步链路水位 | 第 15 篇 |
按生命周期的阅读路径
| 阶段 | 要解决的问题 | 篇目 |
|---|---|---|
| 选型与建库 | 为什么用、世界观、分词、mapping、分片规划 | 第 1-5、14 篇 |
| 原理打底 | 近实时与段、查询、评分 | 第 6-8 篇 |
| 功能搭建 | 高亮纠错、深分页、聚合 | 第 9-11 篇 |
| 运维扩容 | 写入调优、集群、数据同步 | 第 12、13、15 篇 |
| 产品化调优 | 产品链路、查询调优、场景与陷阱 | 第 16-19 篇 |
三条心法
心法一：一切问题先回到倒排。搜不到、搜不准、搜得慢，八成是词条不对或查询形态不对。倒排里有什么，决定你能查到什么；查询怎么写，决定你怎么用它。
心法二：段不可变塑造一切行为。近实时、墓碑删除、段合并、reindex——ES 的很多「怪」都源自 Lucene 段的不可变设计。理解了这一点，行为就都顺理成章，重建索引从事故变成日常。
心法三：没有校验就没有一致性。同步链路永远可能静默失败，对账任务、慢查询日志、三色灯监控，是把「应该没问题」变成「确实没问题」的唯一路径。
十条上线检查清单
| 序号 | 检查项 |
|---|---|
| 1 | 中文分词器装好并验证过，不是 standard 裸奔 |
| 2 | mapping 显式定义，dynamic 关闭或 strict |
| 3 | 数值时间字段不是 text，聚合字段有 keyword 子字段 |
| 4 | 主分片数按一年数据量规划，单分片 10-50GB |
| 5 | 对外用别名，索引名带版本号，重建有预案 |
| 6 | 写入带业务主键，重试幂等 |
| 7 | 筛选条件进 filter 上下文，深分页方案定了 |
| 8 | 同步链路有对账任务，漂移能被发现 |
| 9 | 慢查询日志打开，P99 与零结果率在监控里 |
| 10 | master-eligible 为奇数，副本数小于节点数 |
尾声
至此，「503 咖啡馆」的技术栈已经点亮了三大件：Redis 缓存实战 16 篇管快、MySQL 实战 22 篇管存、消息队列实战 20 篇管传，加上这 20 篇 Elasticsearch 管搜——78 篇，四个战场，一套后端攻坚地图。老王的商城能扛住下一个大促，你现在也有底气说：这套系统，我看得懂也守得住。
下一个系列已经在路上：分布式 ID——分库分表之后，订单号谁来发？ Snowflake 的时钟回拨怎么办？欢迎届时来 503 咖啡馆继续围观。老王在这里等你。
评论 (0)