闲鱼技术-元茂
搜索引擎是电商平台成交链路的核心环节，搜索引擎的高可用直接影响成交效率。闲鱼搜索引擎作为闲鱼关键系统，复杂度和系统体量都非常高，再加上闲鱼所有导购场景都依靠搜索赋能，搜索服务的稳定可靠成为了闲鱼大部分业务场景可用能力的衡量标准；如何保障搜索服务的稳定和高可用成为了极大的挑战。
闲鱼搜索作为闲鱼核心系统，有以下几个突出的特点：
鉴于闲鱼商品搜索引擎以上主要特点，本文详细介绍闲鱼搜索在系统高可用上做的各种努力，希望能给读者一些启发。
正式引出搜索稳定性保障方案之前，我们需要对闲鱼搜索技术有一个简单大致的了解；
我们比较过很多外部开源的搜索引擎，都不能完美支持背景中所列的需求点；闲鱼使用的是阿里巴巴最新研发的搜索引擎平台Ha3[[1]]，Ha3是一款非常高效，智能强大的搜索引擎，它完全满足闲鱼搜索的要求；
Elasticsearch[[2]]，也是比较常用的开源搜索引擎，但是其在算法扩展支撑/绝对实时的能力上与Ha3相差甚远；在同等硬件条件下，基于1200万数据做单机性能对比测试发现，Ha3比ElasticSearch开源系统的QPS高4倍，查询延迟低4倍；Elasticsearch在大规模数据量场景下的性能和稳定性与HA3相比尚有很大的差距。
索引构建即我们所谓的离线流程，其执行者BuildService①，负责将不同存储类型的纯文本商品数据构建成搜索引擎格式的索引文件。原始的商品数据有两类，一类是存放在存储上的全量商品数据，这个定期(一般以天为周期)通过DUMP②产出，另一类为实时变更的数据，在商品信息变更后，由业务系统即时同步给消息系统Swift③。最终分发给在线服务的Searcher④更新索引。
搜索查询即我们所谓的在线流程；闲鱼搜索服务应用A发起搜索请求，通过SP⑤进行服务能力编排；首先SP发起QP⑥算法服务调用，进行用户意图预测，并获取排序辅助信息；然后结合QP返回的结果加上业务系统的查询参数，向Ha3搜索引擎发起查询请求；Ha3搜索引擎QueryService⑦中Qrs⑧接收到查询请求后，分发给QueryService中的Searcher进行倒排索引召回、统计、条件过滤、文档打分及排序、摘要生成；最后Qrs将Searcher返回的结果进行整合后返回给SP，SP经过去重再返回给业务系统；
闲鱼搜索的运维体系，是一个相当复杂的构成；其中涉及很多团队的鼎力协作；
首先必须有Ha3搜索引擎团队在底层提供核心的搜索引擎能力支持；主要负责Ha3搜索引擎核心能力的建设维护；提供并维护引擎运维操作平台和实时引擎搜索服务。
然后是算法团队，在Ha3搜索引擎上进行定制，优化用户搜索体验；对闲鱼非结构化的商品通过算法模型进行理解，预测抽取出结构化信息，供搜索引擎商品索引使用；监控维护QP集群服务；开发并使用Ha3引擎排序插件，进行召回数据分桶实验，验证调优。
最后是我们业务工程团队，串联整个搜索流程，监控维护整个搜索链路的可用性；主要维护搜索对接的数据，Ha3搜索引擎接入管理，进行SP搜索服务编排，制定合理的查询计划；以及闲鱼搜索统一在线查询服务的研发维护工作。
本文亦是从业务工程团队的工作角度出发，阐述如何对复杂搜索业务系统进行稳定性的保障；
以上流程可以通过Ha3引擎运维平台手动触发执行，执行完上述流程后，会生成一份新的索引；新的索引集群服务可用后，在线实时模块会将查询服务切换到新的索引集群上，完成一次索引的更新；这个完整流程我们将其称之为"全量"；
全量完成后，当系统有新的商品信息变动，且相应的数据表有启用实时更新(我们称之为增量功能,DB表是通过binlog/ODPS表是通过Swift消息通知的方式实现)，则离线DUMP引擎会感知到此次变动，进而将相应的镜像数据表中商品数据更新，并会按上述离线DUMP流程中的步骤，将这个改动信息一直向引擎上层投递，直至成功更新引擎索引中的相应数据，或者中途被系统规则丢弃为止；这个实时数据更新的流程我们称之为"增量"；增量更新还有一条通道：算法同学可以使用特殊的方式，通过Swift增量消息的方式直接将需要更新的数据不通过DUMP流程，直接更新到Ha3引擎索引中。
闲鱼商品量飞速增长，目前已经达到数十亿；接入了数百的索引字段，由于闲鱼商品非结构化的原因，索引字段中只有一小部分供业务使用；另外大部分都是算法接入的索引，比如大量抽出来的标签数据，向量化数据等，这些向量化数据非常大；最终的情形表现为闲鱼商品搜索引擎的DUMP处理逻辑比较复杂，而且索引数据总量异常庞大，增量消息量也处在非常高的水位，再加上闲鱼商品单库存的现状；因此对数据更新的实时性要求非常高，这些都给稳定性带来了极大的制约。
索引数据是搜索引擎的内容核心，如果进入引擎的索引数据有问题，或者新变更的数据没有更新到引擎索引中，将直接影响搜索服务的质量；
搜索引擎单机房部署期间，时常会因为一些不稳定的因素，导致DUMP全量失败，或者增量延迟，甚至停止；一旦引擎DUMP出现问题，需要恢复基本都很困难，很多场景下甚至需要重新跑全量才能解决问题；但是闲鱼商品索引数据体量较大，做一次全量往往要大半天，没有办法快速止血，对业务造成了较大的影响；于是对搜索引擎进行双机房部署容灾(M/N机房)，互为备份；
两个离线DUMP机房采用相同的引擎配置和相同的数据源，产出相同的索引数据，分别供两个在线机房使用，两个机房的在线流量比例也可以按需实时调整；当M机房出现不可逆问题时，自动或手动将流量全部切换到N机房，实现线上快速止血，然后再按部就班排查解决M机房的问题。
对高稳定性系统，当出现问题，或者即将产生问题时，能即时感知，显得尤为重要；方便实时进行跟踪处理，防止继续扩大；目前使用的主要手段是建立健全完善的多维度监控告警体系；
上文提到，闲鱼搜索引擎索引体量比较大，需要很多团队共同协作，搜索流程复杂度比较高；而且有算法同学的加入，对闲鱼非结构化的商品做了很多AI识别，加上闲鱼都是单库存商品，对引擎实时性要求非常高；前面已经做了一些容灾的保障方案；但是对实时性的感知上还需要更进一步，才能及时知道数据的准确情况，是否存在更新延迟，以及延迟时间大概是多久等一系列健康度信息；
解法是从业务层面进行实时性的监控告警；提取出闲鱼商品量比较大更新也比较频繁的类目K，在闲鱼的后台业务系统中，通过jkeins间隔一定时间（时间步长可以实时调整），使用类目K作为关键词和品类，根据商品更新时间索引降序招回，模拟用户轮询的方式发送搜索查询请求，召回满足要求的第一页商品；然后根据引擎召回数据的商品更新时间与当前系统时间进行差值比对，大于阈值时长（可以实时调整）说明存在较严重的数据更新延迟，则进行告警信息发送；
3.4.1 全链路压测
对搜索服务以及各上游业务系统进行全链路压测改造；并使用线上真实的用户请求构造大批量的压测数据，在保证不影响线上业务正常进行的前提下，验证链路在超大流量模型下系统的容量和资源分配是否合理，找到链路中的性能瓶颈点，验证网络设备和集群容量。
3.4.2 引擎单链路压测
Ha3搜索引擎在线流程，支持通过回放线上高峰时段查询流量的方式，进行引擎在线服务性能压测。
Ha3搜索引擎离线流程，支持通过回放一段时间Swift增量消息的方式，进行引擎DUMP增量性能压测。
将闲鱼搜索链路接入阿里搜索问题排查平台，搜索实时查询请求的各个步骤输入的参数信息/产出的数据信息都会在此工具平台详细展示，方便各种问题的排查跟进，以及数据信息对比；
还可以根据商品Id，卖家Id，卖家Nick进行商品索引信息的披露；可以排查相应商品在引擎索引中的详细数据，如果数据和预想的有出入，具体是离线DUMP哪一步的处理逻辑导致的状态异常，都能一键查询。
接入此问题排查平台后，能非常直观的掌握引擎的运行状况，搜索召回的链路状态；对快速发现问题根源，即时修复问题都有非常重大的作用！
本文主要介绍闲鱼如何保障复杂场景下搜索引擎服务的稳定性，主要从架构部署，隔离性，容量评估，风险感知&管控等方面进行阐述，介绍了如何稳定支撑20+线上搜索业务场景，做到了快速发现恢复线上问题，高效提前预知规避风险案例50+，极大程度提升了搜索服务的用户体验，保障了闲鱼搜索全年无故障；
经过上述治理方案后，闲鱼搜索系统稳定性得到了极大的保障，同时我们也会继续深耕，在搜索能力的高可用、更易用上更进一步，让上游业务更加顺滑；
希望给各位读者带来一些思考和启发。
Ha3: [https://yq.aliyun.com/articles/585400])
ODPS：https://www.aliyun.com/product/odps/