索引漏洞正 silently 拖垮你的搜索体验
|
三个月前那官网改版，产品经理拍着胸脯说"搜索体验必须丝滑"，结果上线第二天就被运营骂成狗——用户搜"2024新款"能蹦出2019年的旧款，搜"红色连衣裙"前10条全是黑的。我蹲在性能面板前盯着，首屏加载倒是快，2.3秒就出骨架屏，可搜索结果页的DOM节点数直接飙到3000+，滚动时帧率掉得比电梯还快。后来抓包一看，好家伙，ES索引里"color"字段存的是"red/black/blue"这种拼接字符串，查询时没拆词也没同义词扩展，用户搜"红色"能匹配到才怪。 最绝的是后端那帮人，上周五临下班前突然甩过来个接口文档，说"搜索逻辑要加权重"。我打开一看，好家伙，原本用bool查询的must/should结构，现在要改成function_score，还得在脚本里写一堆if-else判断。我当场在会议室拍桌子："你们知不知道function_score在百万级数据下比bool慢3倍？"后端老王叼着烟慢悠悠说："产品说用户觉得搜索结果不精准，必须加权重。"我盯着他键盘上掉了个"W"键的机械键盘，心想这破键盘敲出来的代码能靠谱才怪。 周一早上到工位，发现测试机屏幕还亮着——昨晚加班跑的索引重建脚本卡在"mapping update"阶段，控制台报错"cluster_block_exception: forbidden"。查日志才发现，运维上周把ES集群的shard数量从5改成了15，结果索引重建时触发了一堆merge操作，I/O直接拉满。我蹲在工位前重新调参数，竖着的显示器上代码缩进都看不清楚，外卖小哥在背后催了三次"您的奶茶要凉了"，最后只能把显示器横过来继续改。 上周三产品又来催："用户说搜索结果排序乱，你们得优化。"我打开kibana的Discover，发现他们说的"乱"其实是时间字段存的是字符串格式"2024-03-15"，而不是date类型，导致按时间排序时"2024-02-28"排在了"2024-03-01"前面。更离谱的是，设计稿里搜索框的placeholder文本是"输入关键词"，结果前端实现时用了"请输入关键词"，多出来的"请"字让输入框宽度超了10px，在移动端直接把"搜索"按钮挤到了下一行。我拿着设计稿去跟前端小李对峙，他指着键盘上掉了的"Enter"键说："这破键盘按回车都费劲，谁有空管10px的细节？"
文章配图，仅供参考 昨天终于把索引漏洞全修了——把color字段拆成数组，时间字段改成date类型，function_score改回bool查询，还加了synonym_graph过滤器处理同义词。本以为能松口气，结果产品经理又发来新需求："用户说搜索结果页的图片加载太慢，你们得优化。"我打开Chrome DevTools，发现图片请求全被CDN缓存了，TTFB只有80ms，但首屏里的12张图片有8张是404——原来后端返回的图片URL里多了个斜杠。我盯着构建日志里那条"image path concatenation error"的警告，突然想起上周三晚上后端老王在会议室抽烟时说："反正用户看不到404，先上线再说。"现在每次看到搜索框都PTSD——用户输入关键词的瞬间，后台要过ES索引、NLP分词、权重计算、CDN缓存、前端渲染七道关，任何一环出问题都会拖垮体验。就像上周五那个"红色连衣裙"的搜索，表面看是索引字段设计问题，实际是产品、设计、后端、运维各自为战的结果。我工位上的显示器还是竖着的，键盘上"W"键的位置贴了个创可贴，外卖APP里存着三家奶茶店的联系方式——这些破事，总得有人扛着。 下一步打算把索引监控做成大屏，实时显示查询耗时、错误率、shard状态。要是产品再提"用户觉得不精准"，我就直接甩监控图："看，现在平均查询耗时120ms，比上周快了40%，再改下去ES集群要炸了。"至于键盘上的"W"键，等这波需求上线了再找行政换新的——现在敲代码的手速，已经练到不用看键盘了。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
