搜索技术架构

这幅图是某大厂前几年的搜索架构：

搜索支撑的业务线包括商品、店铺、订单、用户等大大小小20多个，双11期间搜索量在2亿/天，实体服务器超过100台。按功能分为分布式实时引擎、dump中心、数据分析和运维平台几大块

dump中心
实质是根据实例搜索与展现的需求将数据库中相关字段组装成document，并生成索引替换上线的过程。我们的dump分为全量和增量模式。
全量模式，依赖hadoop的批处理方式流程如下

1)将业务涉及到的db数据表加载到hdfs上，db表的每天快照对应hive上的一个日期分区
2)通过hive sql脚本过滤表中的业务字段，结合多表做join生成基础表，基础表也对应到hdfs上一个文件目录
3)运行mapreduce任务，对数据进行加工处理，并最终在dump机上生成索引文件。其中dump机可看作是一个不对外服务的搜索实例，它拥有与线上实例一样的schema和config配置文件。
数据的加工可能包括以下几种：
a. 对字段进行重命名
b. 对字段赋缺省值
c. 根据已有字段生成新字段
d. 对字段值做数值转化、归一化处理
e. 调用业务外部依赖接口，获取额外组装信息
4） 对线上leader的索引数据做替换，并结合增量补全数据
5） 同步replica到leader的数据更新 整个流程逻辑比较简单，但其中有几个重难点还是值得关注：
a. 流程的自动化和配置化
b.索引文件的分发和管理，特别是在分布式大数量的场景下
c.数据完整性和准确性的检验
增量模式，binlog+canal+mq的方式
采用canal解析db主库binlog，将update/insert的record主键信息存入mq，消费mq拿到主键后查询slave库，组装record生成document并实时写入。这里有个细节需要注意，就是当binlog的解析比数据库自身主从同步快时，可能会导致从slave库查不出更新的记录导致增量丢失，在我们的实际场景中确实发生过索引替换上线过程较复杂，涉及到增量数据备份（一般从当天凌晨开始）、追补增量数据、堆积mq阻塞写请求替换索引等步骤

基于solr的分布式实时引擎
分布式上采用了solrcloud，主要有shard的分片和路由、leader选举、容灾恢复等特性。

实时内核上参考了zoie的设计，即两个内存索引core和一个磁盘索引core实现
1） 在添加索引的过程中，索引是同时写入到disk core和ram0 core（当前可用）的，此时检索disk和ram0后merge就可以实时返回新增的文档
2） 当ram0写入到达一定阈值后，开始flush数据到disk上，在这个合并过程中会创建ram1 core。新的文档全部添加到ram1上，而ram0是只读的，此时检索文档需要通过ram0、ram1、disk。因为ram0和disk合并中并没有重新打开indexReader，无需对数据去重
3） 当ram0全部flush到disk上后，重新打开indexReader，并将ram1和ram0进行swap
4） 文档更新，写入当前ram core并在disk上进行标记删除，合并过程中先真实删除disk上的标记文档，然后在将ram上的更新向disk合并
5） 分布式去重

数据分析
主要是基于埋点日志的数据挖掘，支撑了业务指标计算、商品离线导航、相关性统计排序、链路监控优化等日常工作

hesearch平台
是我们的后台MVC系统，提供搜索数据服务、监控报警、配置管理、机器运维、元数据及权限管理的功能模块

http://mp.weixin.qq.com/s?__biz=MzI4OTU3ODk3NQ==&mid=2247483896&idx=1&sn=94025e338b0181d63ed84466f5c26ab1&chksm=ec2c4b48db5bc25e836ec559b30776d7e1a206dd5e551562c4313684635601fd50a40e428344&mpshare=1&scene=23&srcid=0215h1KGgbvr56eyIVgMCBI1#rd