首先要感謝王超和胡耀華兩位研發(fā)經(jīng)理以嚴(yán)謹(jǐn)治學(xué)的研究精神和孜孜以求的工作態(tài)度給我們提供了高可用、可伸縮、高性能的ES方案。
一，曾經(jīng)的基于 MongoDB 的篩選+排序解決方案
電商的商品展示無非“List（列表頁）-Detail（詳情頁）”模式。生活服務(wù)電商更特殊一點(diǎn)，不同開站城市下的用戶看到的團(tuán)購/旅游/酒店/抽獎/電影訂座/外賣…等商品集合以及排序也不一樣。
起初窩窩的 List 需求比較簡單，所以用 memcached+mysql 也就解決了，但隨著在 List 頁做多級篩選，根據(jù)排序公式計(jì)算商品得分來做自動排序等需求的提出，我們把視線轉(zhuǎn)向了 MongoDB。
2012年，我們針對窩窩當(dāng)時(shí)的 MongoDB 實(shí)現(xiàn)方案進(jìn)一步提出，商品中心的改造思路為“持久化緩存模式，盡量減少接口調(diào)用”：
這樣，MongoDB 里不僅僅存儲了一份份 documents，還存儲了不同開站城市、不同頻道、不同排列組合下商品列表的 Goods IDs 清單。排序基本靠 MongoDB 排。ids 清單定時(shí)更新。
這之后，商品中心分拆為：泰山和 GoodsCenter 兩部分。
二，MongoDB 方案的缺陷
隨著網(wǎng)站業(yè)務(wù)的不斷發(fā)展，網(wǎng)站商品搜索篩選的粒度越來越細(xì)，維度也就越來越多，多維度的 count 和 select 查詢，業(yè)務(wù)上各種排序需求，使 MongoDB 集群壓力山大，以至于屢屢拖累商品中心和泰山的性能。
2012年下半年，我們意識到：
2012年時(shí)，不同篩選維度的組合篩選造成 MongoDB 的索引命中率不高，MongoDB一旦沒有命中索引，其查詢效率會直線下降，從而造成整個(gè)MongoDB的壓力增大響應(yīng)變慢（MongoDB 的索引策略基本和 MySQL 的差不多）。有段時(shí)間，我們不止一次遇到由于 MongoDB 的慢查，拖掛所有前臺工程的情況，焦頭爛額。
商品中心需要升級。技術(shù)選型主要集中在 solr 和 ES 這兩個(gè)均構(gòu)建于 Lucene 之上的搜索引擎。
這時(shí)，我們也注意到了外界對新生事物 Elastic Search 的各種溢美之辭，系統(tǒng)運(yùn)維部此前也用 Logstash+ElasticSearch+Kibana 方案替代了 Splunk，也算是對 ES 的搭建有了一定了解。
那時(shí)還看到了專門做 solr vs es 的網(wǎng)站：http:///
三，看中了搜索引擎的 facet 特性
借用騰訊一篇博文來講解 facet search：
facet 的字段必須被索引，無需分詞，無需存儲。無需分詞是因?yàn)樵撟侄蔚闹荡砹艘粋€(gè)整體概念，無需存儲是因?yàn)橐话愣杂脩羲P(guān)心的并不是該字段的具體值，而是作為對查詢結(jié)果進(jìn)行分組的一種手段，用戶一般會沿著這個(gè)分組進(jìn)一步深入搜索。
facet 特性對我們最大優(yōu)點(diǎn)是，查詢結(jié)果里自帶 count 信息，無需我們單獨(dú)計(jì)算不同排列組合的 count 信息，一舉掃清性能瓶頸。
solr 里 facet search 分為三種類型：
四，看中了 ES 的簡潔
2012年下半年不少人傾倒于 ES 的簡潔之美：
 圖3
 圖4
ES 的優(yōu)點(diǎn)：
五，看中了 ES 的天生分布式
ES 畢竟是后來者，所以可以說為分布式而生。它的處理能力上，支持橫向擴(kuò)展，理論上無限制；存儲能力上，取決于磁盤空間（根據(jù)提取字段的數(shù)量，索引后的數(shù)據(jù)量 是原始數(shù)據(jù)量的幾倍，譬如我們的 Logstash+ES 方案中對 nginx 訪問日志提取了17個(gè)字段（都建立了索引），存儲數(shù)據(jù)量8倍于原始日志）。
比如在高峰期，我們可以采用調(diào)配臨時(shí)節(jié)點(diǎn)的方式，來分解壓力，在不需要的時(shí)候我們可以停掉多余的節(jié)點(diǎn)來節(jié)省資源。
還有ES的高可用性，在集群節(jié)點(diǎn)出現(xiàn)一個(gè)節(jié)點(diǎn)或者多個(gè)節(jié)點(diǎn)出現(xiàn)故障時(shí)，主要數(shù)據(jù)完整，依然可以正常提供服務(wù)。
這里有一個(gè)數(shù)據(jù)，大概是2013年時(shí)，有一個(gè)訪談提及 Github 是如何使用 ES：1， 用了 40～50 個(gè)索引，包括庫、用戶、問題、pull請求、代碼、用戶安全日志、系統(tǒng)異常日志等等；2，44臺 EC2 主機(jī)處理 30T 的數(shù)據(jù)，每臺機(jī)器配備 2T SSD 存儲；3，8臺機(jī)器僅僅用于搜索，不保存數(shù)據(jù)。當(dāng)然，Github 也曾經(jīng)在 ES 升級上栽過大跟頭，那是2013年1月17日的事兒了，參考《2013，GitHub使用elasticsearch遇到的一些問題及解決方法，中文譯稿，英文原文》。
六，窩窩的 ES 方案
6.1>架出一層 SearchHub
所有數(shù)據(jù)查詢均通過 SearchHub 工程完成，如下圖所示：
 圖5 SearchHub
6.2>通過 NotifyServer 來異步更新各個(gè)系統(tǒng)
窩窩的數(shù)據(jù)更新基本都是通過 notify （基于中間件 NotifyServer）的形式來保證各個(gè)系統(tǒng)的數(shù)據(jù)一致性。
6.3>索引設(shè)計(jì)方案
6.3.1>商品索引設(shè)計(jì)
商品維度是我們主要的查詢維度，其業(yè)務(wù)復(fù)雜度也比較高。針對網(wǎng)站查詢特性，我們的商品主索引方案為：每個(gè)城市建立一個(gè) index，所以一共有400多個(gè) index，每個(gè)城市僅有1個(gè)主 shard（不分片）。這樣做的好處是以后我們根據(jù)熱點(diǎn)城市和非熱點(diǎn)城市，可以將各個(gè) index 手工分配到不同的 node 上，可以做很多優(yōu)化。 其結(jié)構(gòu)為：
圖7 goodsinfo 為了減少索引量和功能拆分，減少商品索引的內(nèi)存占用，所以我們把全文檢索單獨(dú)建為一個(gè)索引。 每個(gè)城市索引或者商品索引按頻道分為幾個(gè)type，如下圖所示。
圖9 type 商品頻道映射到es的type是很容易理解的，因?yàn)槊總€(gè)頻道的模型不同：有的頻道特有“用餐人數(shù)”屬性，有的頻道特有“出發(fā)城市”和“目的地城市”屬性 所以每個(gè)頻道對應(yīng)一個(gè)es的type，每個(gè)type綁定一種特定的mapping（這個(gè)mapping里面可以指定該頻道各自的特殊屬性如何儲存到ES）。 6.3.2>門店索引設(shè)計(jì)
門店索引方案，采用了默認(rèn)的形式，就是一個(gè)索引叫做 shop_index, 5 shard 的形式。
6.4>集群節(jié)點(diǎn)設(shè)計(jì)方案
按照業(yè)務(wù)拆分，我們將ES拆分為兩大集群：商品索引集群（商品分城市索引和全文檢索索引）和非商品索引集群（或叫通用集群，目前主要是門店索引和關(guān)鍵詞提示索引）。這樣分的主要原因是，商品索引數(shù)據(jù)量較大，而且它是主站主要業(yè)務(wù)邏輯，所以將其單獨(dú)設(shè)立集群。
網(wǎng)絡(luò)拓?fù)淙缦聢D所示：
圖10 集群網(wǎng)絡(luò)拓?fù)?/div>
6.5>分詞設(shè)計(jì)
中文檢索最主要的問題是分詞，但是分詞有一個(gè)很大的弊端：當(dāng)我增加一個(gè)新的詞庫后，需要重新索引現(xiàn)有數(shù)據(jù)，導(dǎo)致我們重建索引代價(jià)較大。所以在犧牲一些查詢效率的情況下，窩窩采取了在建立索引時(shí)做單字索引，在查詢時(shí)控制分詞索引的方案。
具體方案如下所示：
圖11 分詞設(shè)計(jì)
6.6>高可用和可伸縮方案
看一下窩窩商品索引，窩窩采用的方案是一個(gè)城市一個(gè)索引，所有索引的“副本（replicas）”都設(shè)為 1， 這樣比如 shop_index，它有 5 個(gè) shard，每個(gè) shard （只）有一個(gè)副本。（注：1個(gè)副本一方面可以省空間，另一方面是為了效率，在 ES 0.90版本下，ES 的副本更新是全量備份的方案，多個(gè)副本就會有更新效率的問題。ES 1.0 后有改進(jìn)，王超認(rèn)為在增加服務(wù)器后，可以考慮多增加副本。）
ES 會保證所有 shard 的主副本不在同一個(gè) node 上面，但我們是 ES 服務(wù)器集群，每臺服務(wù)器上有多個(gè) node，一個(gè) shard 的主副本不在同一個(gè)節(jié)點(diǎn)還是不夠的，我們還需要一個(gè) shard 的主副本不在同一臺服務(wù)器，甚至在多臺物理機(jī)的情況下保證要保證不在同一個(gè)機(jī)架上，才可以保證系統(tǒng)的高可用性。 所以ES提供了一個(gè)配置：cluster.routing.allocation.awareness.attributes: rack_id。 這個(gè)屬性保證了主副 shard 會分配到名稱不同的 rack_id 上面。
當(dāng)我們停止一個(gè)節(jié)點(diǎn)時(shí)，如停止 174_node_2，則 ES 會自動重新平衡數(shù)據(jù)，如下圖所示：
圖13 重新分布 即使一臺物理機(jī)完全 down 掉，我們可以看到其他物理機(jī)上的數(shù)據(jù)是完整的，ES 依然可以保證服務(wù)正常。 七，ES 的幾次事故和教訓(xùn)
7.1>誤刪數(shù)據(jù)
ES 的 Web 控制臺權(quán)限很大，可以刪數(shù)據(jù)。
有一天，一個(gè)開發(fā)者需要查詢索引 mapping，他用 firefox 的插件訪問，結(jié)果 Method 默認(rèn)居然為 DELETE，如下圖所示：
 圖14 delete
沒有注意，于是悲劇發(fā)生了。
教訓(xùn)：
1）后來耀華咨詢了長期運(yùn)維ES的一些人，大部分都建議前置一個(gè) ngnix，通過 ngnix 禁用 delete 和 put 的 HTTP 請求，借此來限制開放的ES接口服務(wù)。
2）這次的誤操作，實(shí)際上是在沒有給定索引的情況下，誤執(zhí)行了DELETE 操作，結(jié)果刪除了全部索引。其實(shí)配一下 ES 是可以避免的，加入這個(gè)配置：
action.disable_delete_all_indices=true
這樣會禁止刪除所有索引的命令，刪除索引的話，必須要給定一個(gè)索引 ，稍微安全一些。
7.2>mvel 腳本引發(fā)的ES事故
ES集群表象：
一天，ES 各個(gè)節(jié)點(diǎn)負(fù)載升高，JVM Full GC 頻繁。
查看其內(nèi)存使用狀況發(fā)現(xiàn)，ES 各個(gè)節(jié)點(diǎn)的 JVM perm 區(qū)均處于滿或者將要滿的狀態(tài)，如下圖所示：
圖15 當(dāng)時(shí)perm的容量 注1：jstat -gc <pid>命令返回結(jié)果集中，上圖紅色方框中字段的含義為： PC Current permanent space capacity (KB). 當(dāng)前perm的容量 ； PU Permanent space utilization (KB). perm的使用。 大家可以看到圖1中的PU值基本等于PC值了。
問題原因：
頭一天上線了商品搜索的一個(gè)動態(tài)排序功能，它采用 ES 的 mvel 腳本 來動態(tài)計(jì)算商品的排序分值。而 mvel 的原理是基于 JIT，動態(tài)字節(jié)碼生成的，于是很有可能造成 perm 區(qū)持續(xù)升高，原因是它不斷地加載和生成動態(tài) class。
由于 ES 各個(gè)節(jié)點(diǎn)的 perm 區(qū)接近飽和狀態(tài)，所以造成了服務(wù)器負(fù)載升高，GC 頻繁，并進(jìn)一步造成 ES 集群出現(xiàn)了類似于“腦裂”的狀態(tài)。 經(jīng)驗(yàn)教訓(xùn)：
7.3>mark shard as failed 的 ES事故
問題現(xiàn)象：
一天，打算對 JVM 參數(shù)和 ES 配置做了小幅度的謹(jǐn)慎調(diào)整。
凌晨 00:10 左右，維護(hù)者開始按照計(jì)劃對 ES 集群的各個(gè) node 依次進(jìn)行重啟操作，以便使新配置的參數(shù)生效（這類操作之前進(jìn)行過很多次，比較熟練）。
1， 使用 http 正常的關(guān)閉接口，通知 174_0 節(jié)點(diǎn)進(jìn)行關(guān)閉，成功。
2， 觀察其余 node 的狀態(tài)，幾十秒后，ES 剩余的9個(gè)節(jié)點(diǎn)恢復(fù)了 green 狀態(tài)。
3， 啟動 174_0 節(jié)點(diǎn)。
——至此僅僅完成了 174_0 節(jié)點(diǎn)的重啟工作，但緊接著就發(fā)現(xiàn)了問題：174_0 節(jié)點(diǎn)無法加入集群！
此時(shí)的狀態(tài)是：174_0 報(bào)告自己找不到 master，剩余9個(gè)節(jié)點(diǎn)的集群依然運(yùn)行良好。
于是用 jstat 查看了 174_0 的內(nèi)存占用情況，發(fā)現(xiàn)其 ParNew 區(qū)在正常增長，所以他認(rèn)為這次重啟只是比往常稍慢而已，決定等待。
但是在 00:16 左右，主節(jié)點(diǎn) 174_4 被踢出集群，174_3 被選舉為主節(jié)點(diǎn)。
之后，日志出現(xiàn)了 shard 損壞的情況：
[WARN ][cluster.action.shard ] [174_node_2] sending failed shard for [goods_city_188][0], node[eVxRF1mzRc-ekLi_4GvoeA], [R], s[STARTED], reason [master [174_node_4][6s7o-Yr-QXayxeXRROnFPg][inet[/174:9354]]{rack_id=rack_e_14} marked shard as started, but shard has not been created, mark shard as failed]
更糟的是，不但損壞的 shard 無法自動回復(fù)，而且損壞的 shard 數(shù)量越來越多，最終在將近 01:00 的時(shí)候，集群由 yellow 狀態(tài)轉(zhuǎn)為 red 狀態(tài)，數(shù)據(jù)不再完整（此時(shí)損壞的主 shard 不到 20%，大部分城市還是可以訪問的）。
臨時(shí)解決辦法：
首先對主站做業(yè)務(wù)降級，關(guān)閉了來自前端工程的流量。
維護(hù)者開始采用第一套方案：依次關(guān)閉所有 node，然后再依次啟動所有 node。此時(shí)上面新增的 gateway 系列參數(shù)開始起作用，集群在達(dá)到 6 個(gè) node 以上才開始自動恢復(fù)，并且在幾分鐘后自動恢復(fù)了所有的 shard，集群狀態(tài)恢復(fù) green。
隨后打開了前端流量，主站恢復(fù)正常。
接著補(bǔ)刷了過去2小時(shí)的數(shù)據(jù)到 ES 中。
至此，故障完全恢復(fù)。
經(jīng)驗(yàn)教訓(xùn)：
1， 此次事故發(fā)生時(shí)，出問題的 nodes 都是老配置；而事故修復(fù)之后的所有 nodes 都是采用的新配置，所以可以確定此次問題并不是新配置導(dǎo)致的。
2， ES 自身的集群狀態(tài)管理（至少在 0.90.2 這個(gè)版本上）是有問題的——先是從正常狀態(tài)逐漸變?yōu)椤霸絹碓蕉嗟?shard 損壞”，重啟之后數(shù)據(jù)又完全恢復(fù)，所有 shard 都沒有損壞。
3， 由于是深夜且很短時(shí)間就恢復(fù)了服務(wù)，所幸影響范圍較小。
4， 故障原因不明，所以隨后安排 ES 從 0.90 版本升級到 1.3 版本。
八，ES 存在的問題以及改進(jìn)
Elastic Search 在窩窩運(yùn)行幾年來基本穩(wěn)定，可靠性和可用性也比較高，但是也暴露了一些問題：
——END—— 附錄A：
es術(shù)語介紹：cluster：代表一個(gè)集群，集群中有多個(gè)節(jié)點(diǎn)，其中有一個(gè)為主節(jié)點(diǎn)。這個(gè)主節(jié)點(diǎn)是可以通過選舉產(chǎn)生的。注意，主從節(jié)點(diǎn)是對于集群內(nèi)部來說的。es的一個(gè)概念就是去中心化，字面上理解就是無中心節(jié)點(diǎn)，這是對于集群外部來說的，因?yàn)閺耐獠縼砜磂s集群，在邏輯上是個(gè)整體，你與任何一個(gè)節(jié)點(diǎn)的通信和與整個(gè)es集群通信是等價(jià)的。 shards代表索引分片。es可以把一個(gè)完整的索引分成多個(gè)分片，這樣的好處是可以把一個(gè)大的索引拆分成多個(gè)，分布到不同的節(jié)點(diǎn)上。構(gòu)成分布式搜索。分片的數(shù)量只能在索引創(chuàng)建前指定，并且索引創(chuàng)建后不能更改。 replicas代表索引副本，es可以設(shè)置多個(gè)索引的副本。副本的作用，一是提高系統(tǒng)的容錯性，當(dāng)某個(gè)節(jié)點(diǎn)的某個(gè)分片損壞或丟失時(shí)可以從副本中恢復(fù)，二是提高es的查詢效率，es會自動對搜索請求進(jìn)行負(fù)載均衡。 recovery代表數(shù)據(jù)恢復(fù)或叫數(shù)據(jù)重新分布，es在有節(jié)點(diǎn)加入或退出時(shí)會根據(jù)機(jī)器的負(fù)載對索引分片進(jìn)行重新分配，掛掉的節(jié)點(diǎn)重新啟動時(shí)也會進(jìn)行數(shù)據(jù)恢復(fù)。 river代表es的一個(gè)數(shù)據(jù)源，也是其他存儲方式（如：數(shù)據(jù)庫）同步數(shù)據(jù)到es的一個(gè)方法。它是以插件方式存在的一個(gè)es服務(wù)，通過讀取river中的數(shù)據(jù)并把它索引到es中，官方的river有couchDB的，RabbitMQ的，Twitter的，Wikipedia的。 gateway代表es索引快照的存儲方式。es默認(rèn)是先把索引存放到內(nèi)存中，當(dāng)內(nèi)存滿了時(shí)再持久化到本地硬盤。gateway對索引快照進(jìn)行存儲，當(dāng)這個(gè)es集群關(guān)閉再重新啟動時(shí)，就會從gateway中讀取索引備份數(shù)據(jù)。es支持多種類型的gateway，有本地文件系統(tǒng)（默認(rèn)），分布式文件系統(tǒng)，Hadoop的HDFS和amazon的s3云存儲服務(wù)。 discovery.zen代表es的自動發(fā)現(xiàn)節(jié)點(diǎn)機(jī)制。es是一個(gè)基于p2p的系統(tǒng)，它先通過廣播尋找存在的節(jié)點(diǎn)，再通過多播協(xié)議來進(jìn)行節(jié)點(diǎn)之間的通信，同時(shí)也支持點(diǎn)對點(diǎn)的交互。 Transport |
|
|
