上一篇【第05篇】全文索引搜索引擎真正的心脏下一篇【第07篇】算法基本功上折半查找与高效排序摘要前面讲的都是单机视角。可现实里索引可能几百 G、查询可能每秒几万次一台机器根本兜不住。这时候就得上分布式。本文聊聊为什么必须分布式、MapReduce 怎么用分而治之建好大索引以及查询时多机结果怎么合并。顺带说说用户真正面对的搜索界面那三件套才是体验的命门。一、为什么要分布式单机装不下也扛不住单机搜索引擎的天花板很实在。容量天花板。索引再怎么压缩百亿级网页的索引也得按 T 计算单块磁盘装不下单机内存更放不下词典。算力天花板。每秒几万次查询单机 CPU 算到冒烟也扛不住峰值。尤其大促、热点事件时流量能瞬间翻几倍。可用性天花板。单机挂了搜索全瘫。对很多业务来说搜索挂几分钟都是真金白银的损失。分布式就是冲着这三件事来的把数据拆到多台机器解决容量、把请求分摊到多机解决算力、给数据做副本解决可用性。【单机 vs 分布式的三道天花板】 单机: 容量受限 / 算力受限 / 单点故障 分布式: 数据分片(容量) 请求分摊(算力) 多副本(可用性)二、MapReduce 式建索引化整为零建索引是 CPU 和 IO 双密集的活儿最适合用分治拆开。思路是这样的把海量文档切成很多小片分发给多台机器每台机器独立建自己那片的局部索引最后再把局部索引合并成完整索引或者干脆让每片各管一块查询时各查各的。这就是 MapReduce 思想的用武之地Map 阶段各算各的局部结果Reduce 阶段归并。【分治建索引】 全量文档 │ 切分 ▼ ┌─────┬─────┬─────┬─────┐ │片A │片B │片C │片D │ ← 各机器并行建局部索引 └──┬──┴──┬──┴──┬──┴──┬──┘ │ │ │ │ └─────────┴─────────┘ │ 归并 / 分片存储 ▼ 完整可查的索引好处明显加机器就能线性加速建索引。坏处是工程复杂度上来了任务调度、失败重试、结果合并都得自己操心。Hadoop 生态当年就是为这类需求生的。三、查询时怎么合并多机结果建索引能分片查询也得能合并。一次跨分片查询通常是这么跑的协调节点收到用户请求把它转发给所有相关分片。每个分片在自己那部分索引上独立查询、本地打分排序只返回自己这片的 Top N。协调节点把各片的 Top N 收上来做一次全局排序再取总的前 N 条返回。【查询合并流程】 用户请求 │ ▼ 协调节点 ──┬──▶ 分片1: 本地查排序 → 返回TopN ├──▶ 分片2: 本地查排序 → 返回TopN └──▶ 分片3: 本地查排序 → 返回TopN │ ▼ 协调节点: 全局合并排序 → 总TopN这里有个坑要提醒各分片返回的是本地 TopN全局 TopN 不一定就从各片 TopN 里出极端情况某个片的第 N1 名其实比另一片的第 1 名分数还高。严谨实现得考虑这个不过多数业务用本地 TopN 近似也就够了。这点后面讲 ES 聚合和深分页时还会撞见。四、搜索用户界面三件套说完后端看看用户真正面对的东西。一个能用的搜索界面至少有三件套。输入框。用户在这敲词。好的输入框还会做联想词提示、拼写纠错、拼音搜索让你还没敲完就猜到你要啥。结果列表。这是主场。每条结果要有标题、摘要命中词高亮、来源、时间。摘要怎么截、高亮怎么做都直接影响点击率。筛选与分类。左边一列按品牌/价格/品类聚合统计让用户能逐级下钻。这个功能背后就是 Facet 聚合后面会专门讲。【搜索界面三件套】 [ 输入框: 支持联想/纠错/拼音 ] ← 入口 │ ▼ ┌─────────────────────────────┐ │ 结果列表: 标题高亮摘要来源 │ ← 主场 └─────────────────────────────┘ │ [ 左侧筛选: 品牌/价格/品类 下钻 ] ← 收敛五、体验决定成败我见过不少团队内核打磨得很好界面却很敷衍结果不排序、摘要乱截、筛选没有用户搜一次就走了。搜索这东西用户感知到的就是那个框和那页结果。内核决定能不能搜到界面决定愿不愿意继续用。两者缺一不可。后面我们会花专门一篇讲搜索接口、翻页、联想词和查询意图这里先建立UI 也是一等公民的意识。六、为本系列后半程埋个伏笔分布式计算和搜索界面正是本系列后半段的重头戏。Solr 和 Elasticsearch 之所以存在很大程度就是为了解决单机装不下、扛不住这件事它们把索引切成分片、给分片做副本、用 ZooKeeper 一类协调者管集群状态让你加机器就能扩。现在你脑子里应该已经有了一张完整的地图数据从爬虫来进索引倒排是心脏查询时合并打分返回外面套着用户界面底层靠分布式撑规模。接下来几篇我们先补点算法和工程基本功然后就正式动手写代码。七、分布式里的取舍CAP 与最终一致性讲分布式绕不开一个老话题CAP。一个分布式系统一致性C、可用性A、分区容忍P理论上最多同时满足两个。搜索引擎这类系统通常选 AP优先保证可用和分区容忍一致性上做妥协接受最终一致。什么意思你刚发了一篇新商品理论上搜索应该立刻能搜到。但在分布式、异步建索引的架构下它要等个零点几秒甚至几秒才能被搜到。这就是最终一致不是实时一致但过一会儿肯定一致。为什么搜索引擎敢这么选因为搜不到最新一条用户通常不觉得是事故但搜索服务整体挂了、输入框转圈圈那是真事故。所以保可用性、牺牲强一致是业界共识。ES 的近实时就是这个取舍的产物刷新间隔refresh interval就是调节一致性和性能的旋钮。【CAP 取舍在搜索里的体现】 强一致 高可用理论不可兼得网络分区时二选一 搜索选 AP服务不挂优先新数据秒级迟到可接受 调节旋钮refresh intervalES 近实时再说个真实的故障场景让你感受下分布式的坑。某次集群扩容新节点加入后分片重新分配期间部分分片处于未分配状态查询落到这些分片就报错。如果没给查询加忽略未分配分片的容错整个搜索就可能抖一抖。分布式带来的不只是扩展能力还有一堆单机时代想都没想过的失败模式。这也是为什么我们第二段先把单机引擎写扎实分布式留到后面专门啃。分片本身也有学问。怎么把文档分到不同分片常见两招哈希分片对文档 ID 取哈希均匀打散简单但范围查询麻烦范围分片按时间或 ID 区间切范围查询友好但容易热点倾斜。副本则是另一回事每个分片存几份一份挂了其他顶上读请求还能分摊到多个副本上既容错又提速。这些在讲 ES 分片时会再细拆。本篇小结单机搜索引擎有容量、算力、可用性三道天花板分布式靠数据分片、请求分摊、多副本来突破。建索引用 MapReduce 式分治查询时各分片本地算 TopN、协调节点全局合并。用户真正感知的是搜索界面三件套输入框、结果列表、筛选分类体验往往决定搜索的成败。后半系列要啃的 Solr/ES核心就是解决分布式这件事。下一篇我们补点算法基本功。先聊两个搜索引擎里无处不在的小工具折半查找和排序。上一篇【第05篇】全文索引搜索引擎真正的心脏下一篇【第07篇】算法基本功上折半查找与高效排序
