沪江搜索平台化之路

标签: 极客互联 | 发表时间:2017-06-29 13:27 | 作者:shendao
出处:http://www.shellsec.com

作者:曹林华
本文为原创文章,转载请注明作者及出处

背景

随着沪江业务的高速发展以及数据爆炸式的增长,当前公司各产线都有关于搜索方面的需求,但是目前的搜索服务系统由于架构与业务上的设计,不能很好的满足各个业务线的期望,主要体现下面三个问题:

  1. 不能支持对语句级别的搜索,大量业务相关的属性根本无法实现
  2. 没有任何搜索相关的指标评价体系
  3. 扩展性与维护性特别差

基于现状,对行业内的搜索服务做出充分调研,确认使用 ElasticSearch 做底层索引存储,同时重新设计现有搜索服务,使其满足业务方对维护性、定制化搜索排序方面的需求。

整体技术架构

沪江搜索服务底层基于分布式搜索引擎 ElasticSearch,ElasticSearch 是一个基于 Lucene 构建的开源,分布式,RESTful搜索引擎;能够达到近实时搜索,稳定,可靠,快速响应的要求。

沪江搜索平台化之路

image

搜索服务整体分为 5 个子系统

  • 搜索服务(Search Server) : 提供搜索与查询的功能
  • 更新服务(Index Server) : 提供增量更新与全量更新的功能
  • Admin 控制台 : 提供UI界面,方便索引相关的维护操作
  • ElasticSearch 存储系统 : 底层索引数据存储服务
  • 监控平台: 提供基于 ELK 日志与 zabbix 的监控

外部系统接口设计

沪江搜索平台化之路

image

  • 查询接口
    • 查询接口提供http的调用方式,当出现跨机房访问的时候,请使用http接口,其余都可以使用dubbo RPC调用
  • 增量更新接口
    • 数据增量更新接口采用提供MQ的方式接入。当业务方出现数据更新的时候,只需将数据推送到对应的MQ通道中即可。更新服务会监听每个业务方通道,及时将数据更新到ElasticSearch中
  • 全量索引接口
    • 更新服务会调用业务方提供的全量Http接口(该接口需提供分页查询等功能)

      全量更新

      众所周知,全量更新的功能在搜索服务中是必不可少的一环。它主要能解决以下三个问题

  • 业务方本身系统的故障,出现大量数据的丢失
  • 业务高速发展产生增减字段或者修改分词算法等相关的需求
  • 业务冷启动会有一次性导入大批量数据的需求

基于上面提到的问题,我们与业务方合作实现了全量索引。但是在这个过程中,我们也发现一个通用的问题。在进行全量更新的时候,其实增量更新也在同时进行,如果这两种更新同时在进行的话,就会有遇到少量增量更新的数据丢失。比如说下面这个场景

  1. 业务方发现自己搜索业务 index_1数据大量数据丢失,所以进行索引重建。其中index_A是别名,就是我们通常说alias,但是底层真正的索引是index_201701011200(建议:索引里面包含时间属性,这样就能知道是什么创建的)
  2. 首先创建一个新的索引index_201706011200,然后从数据中拉出数据并插入ES中,并记录时间戳T1,最后索引完成的时间戳为T2,并切换搜索别名 index_1指向index_201706011200。
  3. 索引创建成功之后的最新数据为T1这个时刻的,但是T1到T2这段时间的数据,并没有获取出来。同时index_201701011200老索引还在继续消费MQ中的数据,包括T1到T2时间内的缺少数据。
  4. 所以每次索引重建的时候,都会缺少 T1T2时间内的数据。

最后,针对上面这个场景,我们提出通过zookeeper分布式锁来暂停index consumer的消费,具体步骤如下

  1. 创建new_index
  2. 获取该index 对应的别名,来修改分布式锁的状态为stop
  3. index consumer监控stop状态,暂停索引数据的更新
  4. new_index索引数据创建完毕,更新分布式锁状态为start
  5. index consumer监控start状态,继续索引数据的更新
沪江搜索平台化之路

image

这样的话,我们就不用担心在创建索引的这段时间内,数据会有缺少的问题。相信大家对于这种方式解决全量与增量更新数据有所体会。

集群无缝扩容

数据量爆炸式的增加,导致我们ES集群最终还是遇到了容量不足的问题。在此背景下,同时结合ES本身提供的无缝扩容功能,我们最终决定对线上ES集群进行了 在线的无缝扩容,将从原来的3台机器扩容为5台,具体步骤如下

  • 扩容前准备
    • 目前我们线上已经有3台机器正在运行着,其中node1为master节点,node2和node3为data节点,节点通信采用单播的形式而非广播的方式。
    • 准备2台(node4与node5)机器,其中机器本身配置与ES配置参数需保持一致
  • 扩容中增加节点
    • 启动node4与node5(注意一个一个启动),启动完成之后,查看node1,2,3,4,5节点状态,正常情况下node1,2,3节点都已发现node4与node5,并且各节点之间状态应该是一致的
  • 重启master node
    • 修改node1,2,3节点配置与node4,5保持一致,然后顺序重启node2与node3,一定要优先重启data node,最后我们在重启node1(master node).到此为止,我们的线上ES集群就在线无缝的扩容完毕
沪江搜索平台化之路

image

部署优化

  • 查询与更新服务分离
    • 查询服务与更新服务在部署上进行物理隔离,这样可以隔离更新服务的不稳定对查询服务的影响
  • 预留一半内存
    • ES底层存储引擎是基于Lucene,Lucenede的倒排索引是先在内存中生成,然后定期以段的形式异步刷新到磁盘上,同时操作系统也会把这些段文件缓存起来,以便更快的访问。所以Lucene的性能取决于和OS的交互,如果你把所有的内存都分配给Elasticsearch,不留一点给Lucene,那你的全文检索性能会很差的。所有官方建议,预留一半以上内存给Lucene使用
  • 内存不要超过32G
    • 跨32G的时候,会出现一些现象使得内存使用率还不如低于32G,具体原因请参考官方提供的这篇文章 Don’t Cross 32 GB!
  • 尽量避免使用wildcard
    • 其实使用wildcard查询,有点类似于在数据库中使用左右通配符查询。(如:*foo*z这样的形式)
  • 设置合理的刷新时间
    • ES中默认index.refresh_interval参数为1s。对于大多数搜索场景来说,数据生效时间不需要这么及时,所以大家可以根据自己业务的容忍程度来调整

总结

本章主要介绍沪江搜索服务的整体架构,重点对全量更新中数据一致性的问题,ES在线扩容做了一定的阐述,同时列举了一些沪江在部署ES上做的一些优化。本文主要目,通过读过沪江搜索实践,能够给广大读者带来一些关于搭建一套通用搜索的建议。另外,关于搜索服务中排序以及打分的问题,会在后续的沪江技术学院中发布。

相关 [沪江 搜索 平台] 推荐:

沪江搜索平台化之路

- - 神刀安全网
本文为原创文章,转载请注明作者及出处. 随着沪江业务的高速发展以及数据爆炸式的增长,当前公司各产线都有关于搜索方面的需求,但是目前的搜索服务系统由于架构与业务上的设计,不能很好的满足各个业务线的期望,主要体现下面三个问题:. 不能支持对语句级别的搜索,大量业务相关的属性根本无法实现. 没有任何搜索相关的指标评价体系.

Solr平台化搜索实战必知场景

- - 淘宝网综合业务平台团队博客
这个page是个人汇总了maillist、自己在搜索平台化、通用化过程中遇到的种种需求,为了避开必要的“敬业竞争禁止等”,特地从外网搜罗并汇总代表性的需求. 构成基于solr搜索“策略”参考、搜索应用查询的方案参考,但是,性能问题特别是高级用法,在大数据量时,务必压测,做到心里有底. 这里面给出的方法绝大部分基于solr接口、配置.

学术分享搜索平台——中期报告

- - CSDN博客互联网推荐文章
学术分享搜索引擎主要基于爬取的学术数据,提供搜索,可视化,推荐三大块功能,并且支持用户分享感兴趣的学术资源,结合“众包”来打造一个更社交化的学术搜索平台. 相比于传统的学术搜索,可视化和用户的加入能让平台帮助用户发现更多的东西. 我的工作是整个平台的开发和搭建. 从数据上说,涵盖了数据爬取,数据处理,分布式存储,建立索引等工作;从功能上说,涵盖了网站搭建,搜索服务,可视化模块,推荐功能,以及用户的登录、注册、分享模块的实现.

开源分布式搜索平台ELK(Elasticsearch+Logstash+Kibana)+Redis+Syslog-ng实现日志实时搜索

- - C1G军火库
ElasticSearch是一个基于Lucene构建的开源,分布式,RESTful搜索引擎. 设计用于云计算中,能够达到实时搜索,稳定,可靠,快速,安装使用方便. 支持通过HTTP使用JSON进行数据索引. logstash是一个应用程序日志、事件的传输、处理、管理和搜索的平台. 你可以用它来统一对应用程序日志进行收集管理,提供 Web 接口用于查询和统计.

CloudMagic: 整合多平台数据 打造个人信息搜索引擎

- - 雷锋网
随着网络服务的迅速发展,人们已经习惯将各种各样的文件上传到云端存储,但是往往要用这些文件的时候却记不清楚到底在哪,相信很多人都遇到过这种情况吧. 那么有没有一种服务可以帮你快速的在不同云服务中检索你需要的信息呢. CloudMagic是一个跨平台的云搜索应用,这款服务可以追溯至2010年,当初是作为加速Gmail搜索的一个浏览器扩展,后来又推出了 iOS和 Android版本,还另外添加了其它服务如Google Docs, Google Contacts, Google Calendar, Microsoft Exchange和 Twitter等.

“先知”降临,网址缩略服务Bitly发布实时社交搜索平台

- Hopone - 36氪
著名网址缩略服务Bitly今天在官方博客发布消息,实时社交搜索平台正式上线并推出基于此平台的第一项服务“声誉监测”的Beta版. Bitly每天要缩略8000万个链接,积累了互联网上每天源源不断产生的各类链接的详细数据. 分析这些链接的内容,Bitly可以相当程度上掌控互联网上的热点和它们的发展趋势.

沪江网:在线教育的先行者

- - 爱范儿 · Beats of Bits
沪江网创始人阿诺对网络的首次“触电”非常具有代表性. 1998 年刚上大学后不久,阿诺第一次接触到电脑. 当时关于电脑的所有东西——系统、网络、浏览器——对他来说都异常新鲜. 刚买电脑后,他和一个刚得到新玩具的儿童没有区别,每天拿着软盘和同学相互交换文档和游戏. 但软盘的容量实在有限,稍微大点的文件需要反复拷贝,过程冗长而又麻烦.

Docker实践,来自沪江、滴滴、蘑菇街架构师的交流分享

- - 企业架构 - ITeye博客
架构师小组交流会:每期选一个时下最热门的技术话题进行实践经验分享. Docker 作为当前最具颠覆性的开源技术之一,其轻量虚拟化、可移植性是CI/CD,DevOps,微服务的重要实现技术. 但目前技术还不够成熟,在生产实践中会遇到不少坑. 本期参与小组交流的是国内较早采用 Docker 实践的公司.

深度搜索

- - 译言最新精选
译者: HorseHour 原文地址: streamhacker.com. 当我们准备发布 Weotta时,我们已经为如何描述它犯了难. 我们使用了机器学习和自然语言处理吗. 我们最终觉得“深度搜索”是对我们工作最贴切的描述,它是一个超越了基本文本搜索的复杂搜索系统的简洁描述. 无需赘言,不管怎么看,我们都不是这个领域唯一的一家公司;谷歌和很多其他公司都在对深度搜索的各个方面进行研究.

搜索的未来

- Levi - 月光博客
笔者认为,未来的搜索有两个趋势:个性化,社会化. (注:本文给出的很多链接需要特殊方式才可以访问,请自行解决).   从google诞生的那一天起,google的搜索本质上并没有什么变化,依旧是:一个大大的搜索框,你敲进去几个词,google给出一些相关的网页. 不同的人对于同一个关键词所期待的搜索结果可能有很大差别啊.