基于 Elasticsearch 搜索平臺

背景

隨著公司業(yè)務的高速發(fā)展以及數(shù)據(jù)爆炸式的增長，當前公司各產(chǎn)線都有關于搜索方面的需求，但是以前的搜索服務系統(tǒng)由于架構與業(yè)務上的設計，不能很好的滿足各個業(yè)務線的期望，主要體現(xiàn)下面三個問題：

1. 不能支持對語句級別的搜索，大量業(yè)務相關的屬性根本無法實現(xiàn)
2. 沒有任何搜索相關的指標評價體系
3. 擴展性與維護性特別差

基于現(xiàn)狀，對行業(yè)內的搜索服務做出充分調研，確認使用 Elasticsearch 做底層索引存儲，同時重新設計現(xiàn)有搜索服務，使其滿足業(yè)務方對維護性、定制化搜索排序方面的需求。

整體技術架構

滬江搜索服務底層基于分布式搜索引擎 ElasticSearch，ElasticSearch 是一個基于 Lucene 構建的開源，分布式，Restful 搜索引擎；能夠達到近實時搜索，穩(wěn)定，可靠，快速響應的要求。

搜索服務整體分為5個子系統(tǒng)

• 搜索服務( Search Server ) : 提供搜索與查詢的功能
• 更新服務( Index Server ) : 提供增量更新與全量更新的功能
• Admin 控制臺 : 提供 UI 界面，方便索引相關的維護操作
• ElasticSearch 存儲系統(tǒng) : 底層索引數(shù)據(jù)存儲服務
• 監(jiān)控平臺: 提供基于 ELK 日志與 zabbix 的監(jiān)控

外部系統(tǒng)接口設計

• 查詢
  • 查詢接口提供 http 的調用方式，當出現(xiàn)跨機房訪問的時候，請使用http接口，其余都可以使用 dubbo RPC 調用
• 增量更新
  • 數(shù)據(jù)增量更新接口采用提供 MQ 的方式接入。當業(yè)務方出現(xiàn)數(shù)據(jù)更新的時候，只需將數(shù)據(jù)推送到對應的 MQ 通道中即可。更新服務會監(jiān)聽每個業(yè)務方通道，及時將數(shù)據(jù)更新到 Elasticsearch 中
• 全量索引
  • 更新服務會調用業(yè)務方提供的全量 Http 接口(該接口需提供分頁查詢等功能)

全量更新

眾所周知，全量更新的功能在搜索服務中是必不可少的一環(huán)。它主要能解決以下三個問題

• 業(yè)務方本身系統(tǒng)的故障，出現(xiàn)大量數(shù)據(jù)的丟失
• 業(yè)務高速發(fā)展產(chǎn)生增減字段或者修改分詞算法等相關的需求
• 業(yè)務冷啟動會有一次性導入大批量數(shù)據(jù)的需求

基于上面提到的問題，我們與業(yè)務方合作實現(xiàn)了全量索引。但是在這個過程中，我們也發(fā)現(xiàn)一個通用的問題。在進行全量更新的時候，其實增量更新也在同時進行，如果這兩種更新同時在進行的話，就會有遇到少量增量更新的數(shù)據(jù)丟失。比如說下面這個場景

1. 業(yè)務方發(fā)現(xiàn)自己搜索業(yè)務 alias_A 數(shù)據(jù)大量數(shù)據(jù)丟失，所以進行索引重建。其中 alias_A 是別名，就是我們通常說 alias ,但是底層真正的索引是index_201701011200 (建議:索引里面包含時間屬性，這樣就能知道是什么創(chuàng)建的)
2. 首先創(chuàng)建一個新的索引 index_201706011200，然后從數(shù)據(jù)中拉出數(shù)據(jù)并插入ES 中，并記錄時間戳T1，最后索引完成的時間戳為 T2 ，并切換搜索別名index_1 指向 index_201706011200。
3. 索引創(chuàng)建成功之后的最新數(shù)據(jù)為T1這個時刻的，但是 T1 到 T2 這段時間的數(shù)據(jù)，并沒有獲取出來。同時 index_201701011200 老索引還在繼續(xù)消費 MQ 中的數(shù)據(jù)，包括 T1 到 T2 時間內的缺少數(shù)據(jù)。
4. 所以每次索引重建的時候，都會缺少 T1 到 T2 時間內的數(shù)據(jù)。

最后，針對上面這個場景，我們提出通過 zookeeper 分布式鎖來暫停 index consumer 的消費,具體步驟如下

1. 創(chuàng)建 new_index
2. 獲取該 index 對應的別名，來修改分布式鎖的狀態(tài)為 stop
3. index consumer 監(jiān)控 stop 狀態(tài)，暫停索引數(shù)據(jù)的更新
4. new_index 索引數(shù)據(jù)創(chuàng)建完畢，更新分布式鎖狀態(tài)為start
5. index consumer 監(jiān)控 start 狀態(tài)，繼續(xù)索引數(shù)據(jù)的更新

這樣的話，我們就不用擔心在創(chuàng)建索引的這段時間內，數(shù)據(jù)會有缺少的問題。相信大家對于這種方式解決全量與增量更新數(shù)據(jù)有所體會。

集群無縫擴容

數(shù)據(jù)量爆炸式的增加，導致我們 ES 集群最終還是遇到了容量不足的問題。在此背景下，同時結合 ES 本身提供的無縫擴容功能，我們最終決定對線上ES集群進行了在線的無縫擴容，將從原來的 3 臺機器擴容為 5 臺，具體步驟如下

• 擴容前準備
  • 目前我們線上已經(jīng)有 3 臺機器正在運行著，其中 node1 為 master 節(jié)點，node2 和 node3 為data節(jié)點，節(jié)點通信采用單播的形式而非廣播的方式。
  • 準備 2 臺( node4 與 node5 )機器，其中機器本身配置與 ES 配置參數(shù)需保持一致
• 擴容中增加節(jié)點
  • 啟動 node4 與 node5 (注意一個一個啟動),啟動完成之后，查看node1,2,3,4,5 節(jié)點狀態(tài)，正常情況下 node1,2,3 節(jié)點都已發(fā)現(xiàn) node4 與 node5，并且各節(jié)點之間狀態(tài)應該是一致的
• 重啟 master node
  • 修改 node1,2,3節(jié)點配置與 node4,5保持一致，然后順序重啟 node2與 node3 ，一定要優(yōu)先重啟 data node，最后我們在重啟 node1( master node).到此為止，我們的線上 ES 集群就在線無縫的擴容完畢

部署優(yōu)化

• 查詢與更新服務分離
  • 查詢服務與更新服務在部署上進行物理隔離，這樣可以隔離更新服務的不穩(wěn)定對查詢服務的影響
• 預留一半內存
  • ES 底層存儲引擎是基于 Lucene ,Lucene 的倒排索引是先在內存中生成，然后定期以段的形式異步刷新到磁盤上，同時操作系統(tǒng)也會把這些段文件緩存起來，以便更快的訪問。所以Lucene的性能取決于和OS的交互，如果你把所有的內存都分配給 Elasticsearch，不留一點給 Lucene，那你的全文檢索性能會很差的。所有官方建議，預留一半以上內存給 Lucene 使用
• 內存不要超過 32G
  • 跨 32G 的時候，會出現(xiàn)一些現(xiàn)象使得內存使用率還不如低于 32G，具體原因請參考官方提供的這篇文章 Don’t Cross 32 GB!
• 盡量避免使用 wildcard
  • 其實使用 wildcard 查詢，有點類似于在數(shù)據(jù)庫中使用左右通配符查詢。(如：*foo*z這樣的形式)
• 設置合理的刷新時間
  • ES 中默認 index.refresh_interval 參數(shù)為1s。對于大多數(shù)搜索場景來說，數(shù)據(jù)生效時間不需要這么及時，所以大家可以根據(jù)自己業(yè)務的容忍程度來調整

總結

本章主要介紹公司搜索服務的整體架構，重點對全量更新中數(shù)據(jù)一致性的問題， ES 在線擴容做了一定的闡述，同時列舉了一些公司在部署 ES 上做的一些優(yōu)化。本文主要目的，希望大家通過閱讀滬江搜索實踐，能夠給廣大讀者帶來一些關于搭建一套通用搜索的建議