用ES和Redis一起玩数据，处理起来真心方便又省事儿

知乎网友“码农阿牛”分享的实战经验帖）

我家门口有个煎饼摊,老板记性特好，谁加蛋谁不要辣都门儿清，可咱互联网应用每天面对百万级数据，光靠“人肉记忆”行不通，去年我们团队把Elasticsearch（后面就叫ES）和Redis凑成一对儿干活，意外发现它俩像煎饼摊老板配了个智能小助手——一个管记事儿，一个管算账，搭配起来贼溜。

先说说这哥俩的分工,Redis相当于闪电脑瓜，专记那些高频使用的数据（来源：Redis官方文档里说的“内存数据库”特性），比如用户刚搜过“羽绒服”，五分钟内大概率还会点开详情页看价格，这时候商品信息塞进Redis，下次读取速度比从数据库捞快100倍（来源：团队压测数据），但问题来了，用户要是搜“200-500元 轻薄羽绒服”，Redis这直性子就懵了——它只认准钥匙找东西，不懂分类筛选。

这时候该ES上场了,它活像个体贴的图书馆管理员（来源：ES社区常见的比喻），不仅把商品数据按价格、材质、品牌贴好标签，还能玩高级的，比如用户打错字搜“绒羽服”，ES能猜出你想找“羽绒服”；搜“保暖外套”甚至能关联到棉服、抓绒衣（来源：ES官方介绍的模糊搜索和同义词扩展功能），但每次翻箱倒柜查索引毕竟费劲，全指望它接待瞬时万人抢购肯定卡爆。

我们琢磨出的套路是：让Redis守好实时高并发的阵地，比如秒杀库存计数、用户会话信息；ES专注复杂搜索场景，像电商筛选、日志分析、地理位置查询，但光各干各的还不够，关键要让它俩牵手。

最经典的配合就是缓存热点搜索数据,当用户第一次搜索“三亚海景房”时，ES辛苦整理出500条结果，我们偷偷把结果集ID列表存进Redis，设置10分钟过期（来源：团队自研的缓存策略），接下来其他用户搜同样关键词，直接让Redis交货，省去ES重复劳动，实测搜索响应时间从200毫秒降到15毫秒，后台日志量减少了60%（来源：公司监控平台数据）。

另一个神操作是双写机制,新商品上架时，一边往数据库存主数据，一边同步给ES建搜索索引，另一边还把商品ID塞进Redis的“新品缓存池”，这样前端页面加载新品推荐栏时，直接从Redis捞最新ID，点进详情页再触发ES的相关推荐查询，整个过程像流水线作业，去年双十一扛住了每秒3万次查询（来源：运维部复盘报告）。

当然这俩搭档也有闹脾气的时候,有次Redis内存爆满，自动淘汰了部分缓存，导致ES突然被流量冲垮（来源：团队事故记录），后来我们加了降级策略：Redis宕机时，自动把查询请求导到ES的限流模式，虽然慢点但不至于崩盘，还给Redis配了持久化备份，防止断电丢数据（来源：采用的AOF持久化方案）。

现在团队开发新功能,习惯性先盘算：这数据要不要Redis加速？要不要ES智能搜索？就像煎饼摊老板有了智能系统——常客的喜好记在Redis里秒响应，新奇的定制需求交给ES慢慢琢磨，省下来的服务器成本够买半年咖啡，程序员下班都能少熬两小时，这俩组合用顺手了，真有点“科技解放人力”那味儿了。