第2章实时索引概述

2、实时索引概述：实时索引的定义、为什么需要实时索引、实时索引与批量索引的对比

先给个最直白的定义：实时索引，就是数据一写入，立马就能被搜到。

嗯，就这么简单。你想想看，用户刚发了一条微博，刷新一下页面，这条微博就出现在搜索结果里了。背后支撑这个能力的，就是实时索引。

我个人习惯把实时索引理解成「零延迟的索引管道」。数据从产生到进入搜索库，中间几乎没有等待时间。不像以前那种老做法——攒一批数据，半夜跑个定时任务，第二天早上才能搜到。

核心特征：

我在项目中遇到过不少人对「实时」有误解。有人觉得「实时」就是零延迟，其实不是。真正的实时索引，允许有几百毫秒到几秒的延迟，关键是没有人为的批量等待。说白了，数据流到哪，索引就跟到哪。

这个问题我问过很多刚入行的同学。答案五花八门，但核心就三个字：快、准、活。

你想想看，现在谁还愿意等？用户发了一条评论，刷新半天看不到，他直接就走了。我做过一个电商搜索项目，当时用的是批量索引，每天凌晨4点更新一次。结果白天上架的新商品，用户搜不到，白白损失了30%的转化率。

后来换成实时索引，商品上架后5秒内就能搜到。效果立竿见影——当天转化率就涨了15%。

我的经验：实时索引不是锦上添花，而是生存刚需。尤其在电商、社交、资讯这些领域，延迟超过10秒，用户流失率会直线上升。

有些场景，批量索引根本没法用。比如：

我曾经接手过一个新闻搜索系统，用的是批量索引，每天更新两次。结果突发新闻出来，用户搜不到，被竞争对手抢走了大量流量。后来我改成了实时索引，新闻发布后3秒内就能出现在搜索结果里。嗯，效果很明显。

说白了，数据是有「保质期」的。越新鲜的数据，价值越高。实时索引能让你在数据价值最高的时刻，把它呈现给用户。

举个例子：双十一大促，商品价格每5分钟变一次。如果用批量索引，用户看到的可能是10分钟前的价格，这会导致严重的体验问题。实时索引能保证用户看到的价格，就是当前的实际价格。

注意：实时索引不是万能的。如果你的业务场景对数据一致性要求极高（比如金融交易），实时索引反而可能带来风险。我见过有人把实时索引用在账务系统上，结果数据还没完全落盘就被搜到了，出了大问题。

很多新手搞不清这两个概念的区别。我直接给你一张对比表，一目了然：

这个问题没有标准答案。我个人的判断标准是：看数据的新鲜度对业务有没有直接影响。

如果答案是「有」，那就上实时索引。比如：

如果答案是「没有」，那就老老实实用批量索引。比如：

一个小技巧：很多系统其实是「混合架构」——核心数据走实时索引，非核心数据走批量索引。我在做搜索系统时，商品标题、价格、库存这些关键字段走实时，而商品详情、评价这些次要字段走批量。既保证了核心体验，又控制了成本。

做了这么多年搜索引擎，我踩过不少坑。分享几个最常见的：

「实时」不等于「零延迟」——我曾经跟产品经理承诺「实时更新」，结果他理解成「零延迟」，上线后天天被投诉。后来我学乖了，提前说清楚：实时索引允许几百毫秒到几秒的延迟。
实时索引不能保证强一致性——数据写入后，可能因为网络抖动、节点故障导致短暂的不一致。如果你的业务要求「写入后必须立刻读到」，那实时索引可能不适合你。
实时索引的成本比批量高——持续占用资源，对硬件和运维的要求都更高。我见过有人为了「实时」两个字，把服务器成本翻了3倍，结果业务根本不需要那么高的时效性。

嗯，说到这里，你应该对实时索引有了一个比较全面的认识。下一节，我会带你看看实时索引的具体实现机制——到底是怎么做到「数据一写入，立马就能搜到」的。