海量挑戰(zhàn)：騰訊云ES可用性及性能優(yōu)化實(shí)踐

導(dǎo)語|騰訊云Elasticsearch在騰訊會(huì)議中有哪些應(yīng)用？在大規(guī)模海量應(yīng)用場(chǎng)景下，騰訊云Elasticsearch在高可用和性能方面做了哪些優(yōu)化？在低成本解決方案中又有哪些獨(dú)到之處？本文是對(duì)騰訊云專家工程師張彬老師在云+社區(qū)沙龍online的分享整理，希望與大家一同交流。

一、騰訊云ES在騰訊會(huì)議中的應(yīng)用

1.騰訊會(huì)議質(zhì)量分析系統(tǒng)

騰訊會(huì)議于2019年12月底上線，兩個(gè)月內(nèi)日活突破1000萬，被廣泛應(yīng)用于疫情防控會(huì)議、遠(yuǎn)程辦公、師生遠(yuǎn)程授課等場(chǎng)景，為疫情期間的復(fù)工復(fù)產(chǎn)提供了重要的遠(yuǎn)程溝通工具。極速增長(zhǎng)的會(huì)議需求，讓騰訊會(huì)議服務(wù)質(zhì)量分析系統(tǒng)經(jīng)受著巨大的考驗(yàn)。

在會(huì)議中偶然會(huì)存在會(huì)議實(shí)時(shí)音視頻卡頓、音視頻不同步等會(huì)議質(zhì)量問題，造成上述問題的可能因素比較多，當(dāng)前運(yùn)行的網(wǎng)絡(luò)有丟包或連接不穩(wěn)定的情況就是其中一種。

為了幫助會(huì)議質(zhì)量團(tuán)隊(duì)快速精準(zhǔn)地定位分析問題，需要大量運(yùn)行時(shí)的會(huì)議質(zhì)量數(shù)據(jù)支撐，如網(wǎng)絡(luò)相關(guān)的入網(wǎng)類型、碼率、丟包率、網(wǎng)絡(luò)切換、ip切換等數(shù)據(jù)，以及客戶端相關(guān)的CPU使用率、內(nèi)存使用率、操作系統(tǒng)版本、產(chǎn)品版本等數(shù)據(jù)信息。

除了數(shù)據(jù)的實(shí)時(shí)上報(bào)，另一方面，借助多維分析，我們還可以在實(shí)時(shí)數(shù)據(jù)中挖掘出異常情況。如某個(gè)地區(qū)大面積的卡頓，某個(gè)版本出現(xiàn)特定的問題等。通過dashboard或數(shù)據(jù)報(bào)表的形式，幫助會(huì)議質(zhì)量團(tuán)隊(duì)及時(shí)掌控全局情況，快速發(fā)現(xiàn)潛在問題。

2.痛點(diǎn)挑戰(zhàn)

隨著疫情爆發(fā)，騰訊會(huì)議快速增長(zhǎng)，在100天內(nèi)迭代了20多個(gè)版本，在8天內(nèi)主機(jī)數(shù)擴(kuò)容到了10w臺(tái)，這樣的急劇增長(zhǎng)量讓騰訊會(huì)議服務(wù)質(zhì)量分析系統(tǒng)經(jīng)受高壓力，給運(yùn)營(yíng)團(tuán)隊(duì)及時(shí)排查用戶問題帶來了巨大的挑戰(zhàn)。

深究根本原因，是因?yàn)榉?wù)質(zhì)量分析系統(tǒng)在如此高壓力、高吞吐的場(chǎng)景下，寫入性能嚴(yán)重不足導(dǎo)致。騰訊會(huì)議和質(zhì)量分析系統(tǒng)研發(fā)團(tuán)隊(duì)也一起對(duì)問題做了梳理。主要表現(xiàn)在以下四個(gè)方面：

下圖展示了整個(gè)系統(tǒng)的架構(gòu)圖，紅線上面部分是原先使用的質(zhì)量分析系統(tǒng)。騰訊會(huì)議的質(zhì)量數(shù)據(jù)，由上報(bào)接口機(jī)采集后到我們自研的接入服務(wù)，做數(shù)據(jù)清洗或轉(zhuǎn)換的ETL過程，最后把數(shù)據(jù)寫入到自研的lucene數(shù)據(jù)存儲(chǔ)引擎里，提供數(shù)據(jù)查詢和分析能力。

系統(tǒng)架構(gòu)圖

（1）可用性

原來的系統(tǒng)可能會(huì)遇到很多問題，首先在可用性方面，原來自研的lucene引擎是用Java寫的，內(nèi)存使用過多就會(huì)OOM，導(dǎo)致節(jié)點(diǎn)掛掉，進(jìn)而造成集群的雪崩。這樣SLA就難以保障，達(dá)不到4個(gè)9的要求，質(zhì)量團(tuán)隊(duì)經(jīng)常面臨系統(tǒng)崩潰之后用戶問題得不到及時(shí)跟進(jìn)和解決的困擾。

（2）性能

第二個(gè)問題在于性能。疫情爆發(fā)之后，峰值系統(tǒng)寫入量接近300w/s，這個(gè)量是非常大的。由此造成了系統(tǒng)數(shù)據(jù)同步延遲比較高，大量數(shù)據(jù)堆積在里面長(zhǎng)時(shí)間得不到消費(fèi)。比如我們?cè)谇岸瞬樵冇脩舻囊恍?shí)時(shí)質(zhì)量問題的時(shí)候，發(fā)現(xiàn)時(shí)延經(jīng)常在半小時(shí)以上，這肯定無法達(dá)到我們的質(zhì)量要求。

（3）拓展性

在出現(xiàn)如上問題的時(shí)候，大家通常做法可能就是去擴(kuò)容。由于系統(tǒng)最關(guān)鍵的部分，是一個(gè)基于lucene自研的搜索引擎，擴(kuò)容能力比較差，依賴于研發(fā)團(tuán)隊(duì)針對(duì)業(yè)務(wù)的優(yōu)化。在數(shù)據(jù)量暴漲的背景下，不能進(jìn)行快速擴(kuò)容以滿足需求。

（4）易用性

另外，在新系統(tǒng)選型切換的過程中，我們也要考慮易用性。用戶數(shù)暴增，留給系統(tǒng)驗(yàn)證切換的時(shí)間非常短，這要求我們必須使用一種簡(jiǎn)單快速的解決方案。需要在一周之內(nèi)輸出適用方案，并進(jìn)行線上數(shù)據(jù)的切換。

由于時(shí)間緊迫，新的方案需要盡量保留原有架構(gòu)的大部分基礎(chǔ)設(shè)施，并做盡量少的代碼開發(fā)改動(dòng)。

經(jīng)過討論，最終決定把原來這套架構(gòu)切換成Elasticsearch比較經(jīng)典的ELK架構(gòu)。通過logstash的易用性和強(qiáng)大的生態(tài)插件，可以快速替代原有的自研數(shù)據(jù)接入組件，進(jìn)行數(shù)據(jù)的清洗轉(zhuǎn)換等ETL過程。如原有架構(gòu)中使用的kafka，在logstash中就已經(jīng)包含了相應(yīng)的input插件。并且有大量數(shù)據(jù)格式的解析插件支持，對(duì)于數(shù)據(jù)的一些解析、過濾、清洗等操作可以直接在logstash的pipeline中進(jìn)行簡(jiǎn)單的配置即可，基本上是0開發(fā)量。

豐富的各語言SDK，方便快速的對(duì)服務(wù)質(zhì)量分析平臺(tái)前后臺(tái)進(jìn)行快速切換，實(shí)際從代碼修改到上線完成只用了一天的時(shí)間。

二、高可用及性能方向的優(yōu)化

1.高并發(fā)請(qǐng)求

騰訊會(huì)議服務(wù)質(zhì)量分析系統(tǒng)，從2月份進(jìn)行ES架構(gòu)的方案切換開始，寫入吞吐從5w/s不斷攀升，現(xiàn)已達(dá)到100w+/s。

業(yè)務(wù)的突發(fā)增長(zhǎng)有時(shí)候來的很突然，并不能在前期做有效的評(píng)估。社區(qū)中的很多用戶也遇到過類似的問題，由于沒有預(yù)估到業(yè)務(wù)突發(fā)的增長(zhǎng)，并且在業(yè)務(wù)層沒有做好服務(wù)降級(jí)等機(jī)制，導(dǎo)致突發(fā)的寫入查詢流量打崩了整個(gè)集群。

例如早期我們內(nèi)部一個(gè)日志集群，寫入量一天突增5倍，集群多個(gè)節(jié)點(diǎn)Old GC卡住脫離集群，集群RED，寫入停止，給我們帶來了不小的麻煩。

我們對(duì)掛掉的節(jié)點(diǎn)做了內(nèi)存分析，發(fā)現(xiàn)大部分內(nèi)存是被反序列化前后的寫入請(qǐng)求占用。我們對(duì)

掛掉集群的內(nèi)存鏡像做了一些梳理，發(fā)現(xiàn)大量的寫入請(qǐng)求其實(shí)都是用在反序列化這里，耗內(nèi)存比較多。

上圖展示了ES high level的寫入流程，用戶的寫入請(qǐng)求先到達(dá)其中一個(gè)數(shù)據(jù)節(jié)點(diǎn)，我們稱之為數(shù)據(jù)節(jié)點(diǎn)。然后由該協(xié)調(diào)節(jié)點(diǎn)將請(qǐng)求轉(zhuǎn)發(fā)給主分片所在節(jié)點(diǎn)進(jìn)行寫入，主分片寫入完畢再由主分片轉(zhuǎn)發(fā)給從分片寫入，最后返回給客戶端寫入結(jié)果。

右邊是更細(xì)節(jié)的寫入流程，而我們從堆棧中看到的寫入請(qǐng)求堆積的位置就是在紅色框中的接入層，節(jié)點(diǎn)掛掉的根因是協(xié)調(diào)節(jié)點(diǎn)的接入層內(nèi)存被打爆。

針對(duì)這種高并發(fā)場(chǎng)景，我們的優(yōu)化方案是服務(wù)限流。除了要能控制并發(fā)請(qǐng)求數(shù)量，還要能精準(zhǔn)地控制內(nèi)存資源，因?yàn)閮?nèi)存資源不足是主要的矛盾。另外通用性要強(qiáng)，能作用于各個(gè)層級(jí)實(shí)現(xiàn)全鏈限流。

在很多數(shù)據(jù)庫使用場(chǎng)景，會(huì)采用從業(yè)務(wù)端或者獨(dú)立的proxy層配置相關(guān)的業(yè)務(wù)規(guī)則的限流方案，通過資源預(yù)估等方式進(jìn)行限流。這種方式適應(yīng)能力弱，運(yùn)維成本高，而且業(yè)務(wù)端很難準(zhǔn)確預(yù)估資源消耗。

ES原生版本本身有限流策略，是基于請(qǐng)求數(shù)的漏桶策略，通過隊(duì)列加線程池的方式實(shí)現(xiàn)。線程池大小決定了處理并發(fā)度，處理不完放到隊(duì)列，隊(duì)列放不下則拒絕請(qǐng)求。但是單純地基于請(qǐng)求數(shù)的限流不能控制資源使用量，而且只作用于分片級(jí)子請(qǐng)求的傳輸層，對(duì)于我們前面分析的接入層無法起到有效的保護(hù)作用。原生版本也有內(nèi)存熔斷策略，但是在協(xié)調(diào)節(jié)點(diǎn)接入層并沒有做限制。

我們的優(yōu)化方案是基于內(nèi)存資源的漏桶策略。我們將節(jié)點(diǎn)JVM內(nèi)存作為漏桶的資源，當(dāng)內(nèi)存資源足夠的時(shí)候，請(qǐng)求可以正常處理；當(dāng)內(nèi)存使用量到達(dá)一定閾值的時(shí)候分區(qū)間階梯式平滑限流。例如上圖中淺黃色的區(qū)間限制寫入，深黃色的區(qū)間限制查詢，底部紅色部分作為預(yù)留buffer，預(yù)留給處理中的請(qǐng)求、merge等操作，以保證節(jié)點(diǎn)內(nèi)存的安全性。

2.大聚合查詢

對(duì)于大聚合的場(chǎng)景，因?yàn)橄到y(tǒng)收攏進(jìn)來的數(shù)據(jù)也是有價(jià)值的，我們也會(huì)經(jīng)常在上面做一些分析和查詢，比如做騰訊會(huì)議在全世界各個(gè)地區(qū)會(huì)議質(zhì)量情況的展示等。在這樣聚合的過程當(dāng)中，有的指標(biāo)它的分桶數(shù)量是比較多的，可能出現(xiàn)上萬甚至十萬、百萬級(jí)別。

結(jié)合整個(gè)查詢流程會(huì)發(fā)現(xiàn)，在協(xié)調(diào)節(jié)點(diǎn)內(nèi)會(huì)把數(shù)據(jù)節(jié)點(diǎn)匯聚到的分析數(shù)據(jù)再做一次二次匯聚，對(duì)分桶分析過濾，包括做一些排序等，在分桶數(shù)量比較多的情況下，協(xié)調(diào)節(jié)點(diǎn)的內(nèi)存使用壓力是比較大的，當(dāng)一個(gè)比較大的查詢過來時(shí)，這個(gè)節(jié)點(diǎn)可能就會(huì)掛掉。

原生ES對(duì)查詢方面的限制也是比較死的，限制最大返回結(jié)果桶數(shù)，默認(rèn)是一萬，如果超過這個(gè)限制則直接拒絕。但分析場(chǎng)景結(jié)果桶數(shù)十萬、百萬是常態(tài)，默認(rèn)1萬是不夠的。另外這個(gè)值也是很難精確設(shè)置的，調(diào)整不靈活，大了內(nèi)存會(huì)崩掉，小了滿足不了業(yè)務(wù)需求，所以我們也要對(duì)它進(jìn)行優(yōu)化。

第一階段我們根據(jù)當(dāng)前JVM的內(nèi)存使用情況做查詢的預(yù)估，通過內(nèi)存膨脹系數(shù)預(yù)估在反序列過程當(dāng)中所要消耗的內(nèi)存數(shù)量，一旦超過閾值則直接熔斷。

第二階段，reduce過程中流式檢查桶數(shù)，每增加固定數(shù)量的桶就檢查一次內(nèi)存，如果發(fā)現(xiàn)超限則直接熔斷。比如總量一萬桶，每新增1024個(gè)桶就需要再檢查一次內(nèi)存，如果超過限制，就直接把這個(gè)比較大的聚合查詢殺掉。

雖然殺掉當(dāng)前這個(gè)大查詢可能會(huì)犧牲一定的用戶體驗(yàn)，但卻能保證整個(gè)集群的穩(wěn)定性。我們的這項(xiàng)優(yōu)化也已經(jīng)提交給ES官方社區(qū)，并且已經(jīng)在7.7.0這個(gè)版本發(fā)布了。

3.多可用區(qū)部署

在更基礎(chǔ)的場(chǎng)景下，比如我們的機(jī)器、集群，甚至整個(gè)機(jī)房掛掉，這種情況下的可用性光靠?jī)?yōu)化是難以徹底解決的。所以為了達(dá)到某些客戶，比如電商或者金融客戶對(duì)關(guān)鍵業(yè)務(wù)的可用性要求，騰訊云ES提供了集群的多可用區(qū)部署方案。

一個(gè)集群可以選擇在兩個(gè)或三個(gè)可用區(qū)上部署，這樣的話每個(gè)節(jié)點(diǎn)都能被標(biāo)記可用性屬性，當(dāng)我們開啟分片分配可用區(qū)的感知之后，一個(gè)索引多個(gè)分片的副本可以平均分配到各可用區(qū)，這樣就能保證一個(gè)可用區(qū)掛掉以后不影響整個(gè)集群的數(shù)據(jù)完整性，可以穩(wěn)定給業(yè)務(wù)提供寫入讀取的能力。并且切換是透明的，業(yè)務(wù)方面無感知。

4.合并策略

在性能方面的優(yōu)化，首先在數(shù)據(jù)合并方面。ES的底層Lucene基于LSM Tree的數(shù)據(jù)文件。合并策略業(yè)內(nèi)有幾種典型方案，比如按時(shí)間序進(jìn)行合并，比如把當(dāng)前一小時(shí)內(nèi)的數(shù)據(jù)進(jìn)行合并，典型產(chǎn)品有Cassandra、HBase等。但是它只適合時(shí)序場(chǎng)景，而且因?yàn)槊總€(gè)小時(shí)數(shù)據(jù)寫入量不太一樣，導(dǎo)致文件合并的大小不太一致，會(huì)影響合并的效率。

另外一些產(chǎn)品如LevenIDB、RocksDB選擇的是分層合并，優(yōu)點(diǎn)是查詢高效，但是寫放大較嚴(yán)重，影響TPS。

所以我們?cè)谠桨富A(chǔ)上，同時(shí)調(diào)研了大量開源社區(qū)的方案做了新的優(yōu)化。因?yàn)槲募g按創(chuàng)建時(shí)間來看是有序的，這里可以取個(gè)巧，并不需要真的關(guān)注文件的創(chuàng)建時(shí)間，而只需要關(guān)注這個(gè)文件的時(shí)間序就行。

在L0層我們會(huì)通過文件的創(chuàng)建時(shí)間對(duì)文件進(jìn)行排序。在分層合并的時(shí)候，再按目標(biāo)文件大小進(jìn)行合并，比如在L1層設(shè)置文件大小是20M，每攢20個(gè)小文件就做一次合并，這樣既保證了數(shù)據(jù)的連續(xù)性，又將文件數(shù)量得到了收斂，最終提升了寫入場(chǎng)景查詢性能。

我們根據(jù)目標(biāo)文件大小這個(gè)維度進(jìn)行合并，可能會(huì)漏掉一些比較小的文件。不過沒關(guān)系，因?yàn)槲覀兒竺孢€做了一個(gè)冷分片的持續(xù)合并，有一些小的分片因?yàn)殚L(zhǎng)期沒有寫入，始終達(dá)不到合并目標(biāo)的要求，這時(shí)會(huì)有一個(gè)冷分片的持續(xù)合并策略，發(fā)現(xiàn)有一些小的分片超過五分鐘沒有被更新，就會(huì)強(qiáng)制觸發(fā)它向上合并。

5.大吞吐寫入

第二個(gè)性能方面的優(yōu)化是在大吞吐寫入方面，以騰訊某金融業(yè)務(wù)的人群畫像分析系統(tǒng)為例，這個(gè)系統(tǒng)每天晚上執(zhí)行一次全鏈導(dǎo)入任務(wù)，在白天只有小批量的更新。對(duì)于一些體量比較大的客戶，每天晚上全量導(dǎo)入數(shù)據(jù)量是非常大的，甚至高達(dá)十幾億，并且需要在夜間那幾個(gè)小時(shí)導(dǎo)入完成，因?yàn)榈诙炀蜁?huì)對(duì)這些數(shù)據(jù)進(jìn)行量化分析了。

在使用過程中，業(yè)務(wù)部門經(jīng)常會(huì)發(fā)現(xiàn)寫入性能不高，且CPU使用率不穩(wěn)定的問題，資源利用率嚴(yán)重不足。

騰訊云ES內(nèi)核團(tuán)隊(duì)對(duì)類似的高壓力寫入場(chǎng)景進(jìn)行了追蹤及分析，并在同樣的場(chǎng)景下進(jìn)行了多個(gè)方案的壓力測(cè)試，發(fā)現(xiàn)ES單節(jié)點(diǎn)的壓力寫入測(cè)試與lucene基準(zhǔn)的寫壓力測(cè)試有較大的差距：如果這個(gè)數(shù)據(jù)不通過ES而是直接通過Lucene寫入，性能會(huì)提升一倍。

所以我們就對(duì)騰訊云ES的各種寫入流程做了一個(gè)分析，發(fā)現(xiàn)Lucene寫入就是單純地寫入數(shù)據(jù)，但ES是一個(gè)分布式的系統(tǒng)，為了防止內(nèi)存里面的數(shù)據(jù)沒有及時(shí)刷盤，我們會(huì)寫一個(gè)translog，對(duì)應(yīng)數(shù)據(jù)庫里面的binlog機(jī)制。

因?yàn)椴豢赡茉谝粋€(gè)文件上面一直持續(xù)寫，就需要對(duì)大量的文件做管理，因?yàn)楹芏嘁呀?jīng)刷盤的數(shù)據(jù)是不需要保留的，所以會(huì)有一些輪轉(zhuǎn)的機(jī)制。我們會(huì)不斷地去生成新的文件，然后不斷地淘汰小的文件。

在這里面就出現(xiàn)了一個(gè)問題：因?yàn)镋S一個(gè)節(jié)點(diǎn)的寫入是并發(fā)的，可能有很多寫入的限制都在持續(xù)地對(duì)同一個(gè)數(shù)據(jù)文件做寫入，但是當(dāng)前文件只允許一個(gè)線程進(jìn)入臨界區(qū)，所以這個(gè)鎖的同步效率是非常低的，因?yàn)椴还苡卸嗌賯€(gè)寫入限制，一旦到了切換的時(shí)候這個(gè)鎖會(huì)把所有的寫入限制都鎖住。

所以這里我們也做了兩套優(yōu)化的方案。第一種方案，我們首先想到了把rollGeneration做成異步的，兩個(gè)流程互相不影響，但是改造量是比較大的。通過社區(qū)討論，我們最終確立了一個(gè)非常精簡(jiǎn)的方案，就是每次rollGeneration前做一次刷盤，后面每次寫入的時(shí)候不需要都去做這個(gè)鎖的同步。這個(gè)方案對(duì)流程的改造最輕量?jī)?yōu)雅，且優(yōu)化后的寫入性能提高了20%以上。

這部分優(yōu)化的代碼經(jīng)騰訊內(nèi)部的業(yè)務(wù)驗(yàn)證后，最終整理提交回饋給了社區(qū)。由于這個(gè)優(yōu)化在ES寫入的所有場(chǎng)景下均適用，且對(duì)性能的提升非常顯著，Elastic的創(chuàng)始人對(duì)該P(yáng)R高度贊揚(yáng)，并給騰訊云總裁發(fā)來了公開感謝信。

騰訊云ES在社區(qū)開源的內(nèi)核之上，根據(jù)云上的內(nèi)外部業(yè)務(wù)的場(chǎng)景案例積累，做了大量的內(nèi)核優(yōu)化。除了上面介紹的translog的優(yōu)化，還有帶“_id”的寫入操作剪枝優(yōu)化、查詢計(jì)劃優(yōu)化等等，滿足了客戶在性能方面的需要，并積極將一些通用的優(yōu)化提交至社區(qū)，截至目前為止，騰訊云提交的pr約有50+被合并到了主干。

三、低成本解決方案上的優(yōu)化

1.存儲(chǔ)成本優(yōu)化

騰訊云自身的監(jiān)控系統(tǒng)也是基于ES來做的，特別對(duì)于一些大的地域的集群，它的寫入速度甚至達(dá)到了千萬級(jí)每秒。面對(duì)這樣的吞吐量，并且數(shù)據(jù)量至少要保留半年時(shí)間的可空查詢，預(yù)估整個(gè)集群大概需要能承載14PB的數(shù)據(jù)，按照我們內(nèi)部用的物理機(jī)磁盤的規(guī)格，需要1500臺(tái)物理機(jī)，遠(yuǎn)遠(yuǎn)超出成本預(yù)算。

我們對(duì)監(jiān)控系統(tǒng)的業(yè)務(wù)日志做了分析，發(fā)現(xiàn)這類數(shù)據(jù)都是有時(shí)序性的，隨著時(shí)間的推移它的訪問頻率越來越低。

（1）冷熱分離

所以我們首先給用戶推出的解決方案就是冷熱分離，在一個(gè)集群里我們會(huì)給用戶提供兩種不同屬性的機(jī)型，用戶新寫入的數(shù)據(jù)，或者近期頻繁訪問的數(shù)據(jù)可以寫入到高配置、高IO的機(jī)型，比如64核甚至更高核數(shù)，帶云盤或者本地盤的機(jī)型，可以保證一天之內(nèi)或者幾個(gè)小時(shí)之內(nèi)這種熱數(shù)據(jù)的寫入性能。

對(duì)于一天以后甚至一周以后才訪問的冷數(shù)據(jù)，可以寫入到低配置的機(jī)型，比如12核甚至4核的機(jī)型以降低成本。

（2）生命周期管理

原生ES提供了生命周期管理功能，把數(shù)據(jù)分為3個(gè)階段：Hot phrase、Warm phrase、Cold phrase，在每個(gè)階段都可以對(duì)數(shù)據(jù)做管理，比如熱階段可以按天、小時(shí)或者我們自己設(shè)置的大小來分索引。

大多數(shù)查詢或者分析都是按小時(shí)、天，而在Warm階段我們可以按秒級(jí)采集數(shù)據(jù)，通過降低數(shù)據(jù)的精度，極大減少數(shù)據(jù)的總量，并且提升數(shù)據(jù)查詢的效率。

在冷階段很多數(shù)據(jù)可能是作為備份，幾乎很少被查詢，我們可以關(guān)閉一些索引，或者做一些數(shù)據(jù)的備份，甚至如果數(shù)據(jù)沒有必要還可以刪掉。

（3）多盤策略

在存儲(chǔ)方面，現(xiàn)在包括騰訊云在內(nèi)的很多云廠商為用戶提供的主要還是CBS云盤，但是CBS云盤在單盤IO能力上有限制，最大不超過260M/S，所以我們?yōu)榭蛻籼峁┝硕啾P策略。

原來一個(gè)節(jié)點(diǎn)只能帶一塊硬盤，現(xiàn)在一個(gè)節(jié)點(diǎn)可以掛多塊盤，這樣的話一方面能突破CBS IO能力限制，原來單盤的260MB/S，通過掛4~5塊盤將能力擴(kuò)充數(shù)倍。另外單節(jié)點(diǎn)的IO提升之后我們就不需要那么多的節(jié)點(diǎn)，能夠節(jié)約大量成本。

（4）COS冷備

ES的索引數(shù)據(jù)每個(gè)上面其實(shí)分了很多的小文件，所以我們做了一個(gè)COS上傳下載的插件，可以在控制臺(tái)自動(dòng)觸發(fā)或者在ILM配置觸發(fā)，把這些底層數(shù)據(jù)文件直接備份到成本非常低的COS上。如果真的某一天系統(tǒng)數(shù)據(jù)出現(xiàn)了問題，也可以很方便恢復(fù)過來。

以上就是我們?cè)诖鎯?chǔ)成本上的優(yōu)化，騰訊云監(jiān)控的集群優(yōu)化之后只需要兩三百臺(tái)機(jī)器就可以扛住原來1500臺(tái)機(jī)器做的事情，極大降低了我們的成本。

2.計(jì)算成本優(yōu)化

其次是計(jì)算成本上的優(yōu)化，主要是在內(nèi)存使用率方面。其實(shí)我們磁盤使用率并不高，只有30%~40%，但是我們的堆內(nèi)存使用率長(zhǎng)期處于70%-80%，甚至有時(shí)候達(dá)到90%這一比較危險(xiǎn)的狀態(tài)。

原因主要在于索引里面的FST占用了大量?jī)?nèi)存，基本維持在50%-70%，而且需要常駐內(nèi)存不能釋放。計(jì)算發(fā)現(xiàn)，大概每10TP的磁盤就需要10G-15G來存FST緩存。

ES社區(qū)對(duì)于這個(gè)問題也有一些優(yōu)化方案，比如因?yàn)镕ST對(duì)內(nèi)存占用比較多，類似很多這種大數(shù)據(jù)的組件就把它移到堆外，這里的優(yōu)化方案其實(shí)很簡(jiǎn)單，就是通過系統(tǒng)MMmap的方式，通過linux操作系統(tǒng)數(shù)據(jù)頁的淘汰，如果長(zhǎng)時(shí)間沒有訪問就淘汰出去。

這種方案優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，但是這種淘汰策略比較粗糙，對(duì)于一些海量數(shù)據(jù)場(chǎng)景，可能一個(gè)查詢過來，原來那些在Cache里面的數(shù)據(jù)就被淘汰掉了，又要重新?lián)Q一批，而實(shí)際上淘汰的那批數(shù)據(jù)可能是經(jīng)常要使用的。

所以，我們也對(duì)原生方案做了一些優(yōu)化，做了兩層的Cache，借助堆外內(nèi)存，釋放堆內(nèi)存。在GC之前不會(huì)過快的釋放，在堆外我們也不推薦通過操作系統(tǒng)方式進(jìn)行管理，因?yàn)楫吘箍刂频牧６缺容^粗，我們會(huì)通過一些LRU或者LFU的策略，加上通過Cache的訪問頻次進(jìn)行一些淘汰。

四、未來展望

未來在可用性方面，我們會(huì)加強(qiáng)智能診斷的功能，因?yàn)镋S在很多方面都需要用戶來操心。比如索引設(shè)置不太好，可能會(huì)導(dǎo)致并發(fā)性能不高等等。對(duì)于ES使用不是特別熟的用戶可能會(huì)有這樣的苦惱，感覺集群經(jīng)常莫名其妙會(huì)出現(xiàn)一些問題，當(dāng)然也可能是自己使用上沒有注意。

通過智能診斷功能，它能持續(xù)不斷幫助用戶去做使用方面的監(jiān)控，比如索引方面分配的策略等，給客戶做一些預(yù)先的提醒和預(yù)警，在業(yè)務(wù)受到影響之前，把這個(gè)問題扼殺在萌芽之中。

另外我們也會(huì)提供節(jié)點(diǎn)自愈的能力。在性能方面我們會(huì)著重于擴(kuò)展多維分析的能力，因?yàn)楝F(xiàn)在多維分析的場(chǎng)景在ES里應(yīng)用也比較多，包括前文提到的騰訊會(huì)議質(zhì)量數(shù)據(jù)的這種多維分析，騰訊云一些金融業(yè)務(wù)的畫像分析等等。

成本方面，基于前文提到的備份策略，我們?cè)瓉韨浞莸紺OS上面的數(shù)據(jù)其實(shí)就是一份冷數(shù)據(jù)，寫入不了也查詢不了，萬一哪天我們真的有這樣的查詢需求，還需要把它重新恢復(fù)到集群上面，比較麻煩。

所以我們后面會(huì)和社區(qū)一起完善推出一種可搜索的備份，我們可以容忍這種搜索的延時(shí)，比如一分鐘甚至五分鐘才把結(jié)果返回，但是數(shù)據(jù)仍是可以放到COS上，從而節(jié)省大量的成本開支。

我們會(huì)比較快推出存儲(chǔ)資源分配的功能，相當(dāng)于節(jié)點(diǎn)是可以無限擴(kuò)充，這樣對(duì)于某一些經(jīng)常做活動(dòng)的用戶，活動(dòng)期間流量非常大，需要瞬間擴(kuò)容節(jié)點(diǎn)來扛住這樣比較大的查詢請(qǐng)求。當(dāng)做完活動(dòng)之后很多節(jié)點(diǎn)沒有用了，可以把它縮掉，但是數(shù)據(jù)仍然保留，所以這種存儲(chǔ)計(jì)算分離的成本優(yōu)化對(duì)于這一類用戶是非常需要的。

另外我們會(huì)完善數(shù)據(jù)集成的通道，會(huì)支持很多導(dǎo)入導(dǎo)出、數(shù)據(jù)遷徙的插件，我們計(jì)劃在Q3把它引入到騰訊云，作為一個(gè)子產(chǎn)品提供給用戶這個(gè)功能。在2020年Q4我們也會(huì)結(jié)合騰訊云數(shù)據(jù)庫DBS、Kafka組件做這種數(shù)據(jù)通道，讓用戶通過控制臺(tái)的簡(jiǎn)單配置就可以把數(shù)據(jù)接入進(jìn)來。其實(shí)ES和大數(shù)據(jù)的組件是可以做一些天然融合的，后面我們也會(huì)更多的在大數(shù)據(jù)平臺(tái)上做一些融合化的研究和演進(jìn)。

Q&A;

Q：1000 w/s的索引有幾個(gè)節(jié)點(diǎn)？

A：上文提到的騰訊云監(jiān)控系統(tǒng)，會(huì)有千萬級(jí)每秒的高壓力寫入場(chǎng)景。經(jīng)過優(yōu)化了之后，只需要兩三百個(gè)節(jié)點(diǎn)左右就能扛住壓力。

Q：ILM可以針對(duì)索引么？

A：ILM是索引生命周期管理，其實(shí)就是針對(duì)索引的。前文提到成本優(yōu)化的時(shí)候，我們發(fā)現(xiàn)數(shù)據(jù)有時(shí)間上冷熱的屬性，在數(shù)據(jù)熱階段我們可以通過ILM做索引的切分管理，比如一天切一個(gè)索引，或者按數(shù)據(jù)量1G切一個(gè)索引等等，其它如溫場(chǎng)景、冷場(chǎng)景也可以針對(duì)索引維度做逐級(jí)的數(shù)據(jù)壓縮、刪除、備份等操作。

Q：COS冷備份能再詳細(xì)展開嗎？

A：關(guān)于這一塊，我推薦大家去閱讀騰訊云ES官網(wǎng)上的文檔，上面有比較詳細(xì)的解釋，包括API在ES里面的COS冷備，API怎么使用，倉庫怎么建立等等。會(huì)有ES相關(guān)文檔給出比較詳細(xì)的介紹，大家可以通過我們提供的免費(fèi)集群實(shí)際操作一下。它的成本是比較低的，效率也比較高，使用起來也方便，大概兩三條API就可以搞定。另外前文提到的ILM功能也支持COS冷備，直接可以在ILM上進(jìn)行設(shè)置。

Q：一個(gè)ES集群最大節(jié)點(diǎn)數(shù)能到多少，會(huì)有瓶頸么？

A：目前不推薦用戶超過一千個(gè)節(jié)點(diǎn)。在一個(gè)集群中存在過多的節(jié)點(diǎn)，因每個(gè)節(jié)點(diǎn)都會(huì)需要和其他節(jié)點(diǎn)進(jìn)行通信及保持心跳，節(jié)點(diǎn)規(guī)模持續(xù)的擴(kuò)大會(huì)造成很多問題，建議利用業(yè)務(wù)做拆分

Q：第三方ES如何遷移至騰訊云ES?

A：有很多方案，比較簡(jiǎn)單可以通過COS，COS不僅可以做冷備，也可以做數(shù)據(jù)遷移。因?yàn)槲覀兊腃OS插件是開源，可以下載一個(gè)到自建的ES系統(tǒng)上，把你的數(shù)據(jù)全量或者增量備份到COS上面，再把它恢復(fù)到騰訊云ES上是比較快的。另外在架構(gòu)設(shè)計(jì)層面也會(huì)有一些不停服遷移方案，也可以咨詢一下你的架構(gòu)師。

Q：堆外內(nèi)存是怎么用MMmap方式做的，騰訊云這里是直接改了Lucene了嗎？

A：我們?cè)趦?nèi)核方面做了大量的修改，有一部分是對(duì)ES的修改，另外大量的底層數(shù)據(jù)存儲(chǔ)設(shè)計(jì)更多是對(duì)Lucene的修改，這些修改基本上都已經(jīng)回饋給社區(qū)。

Q：ELK日志延遲過大，是如何追平的？

A：前文提到的騰訊會(huì)議延遲過大主要就在于寫入性能比較慢，所以一直追不上。我們?nèi)胧值狞c(diǎn)也是提升集群的寫入能力，一方面我們做了一些擴(kuò)容類的工作，另外在拷貝方面也做了大量寫入查詢優(yōu)化，最后推薦大家盡量使用最新版本，比如騰訊云支持的7.5.1版本，或者官方的7.7版本，最新版本有大量的寫入查詢優(yōu)化。

Q：集群的服務(wù)器參數(shù)，是要定制化調(diào)試么，有成型的解決方案么？

A：這個(gè)問題很好，對(duì)于服務(wù)器我們需要做很多操作系統(tǒng)上的調(diào)節(jié)，我們的ES服務(wù)器上也做了大量偏向于ES應(yīng)用的調(diào)用，我們?cè)?社區(qū)專欄也有一篇文章叫做ES調(diào)用實(shí)踐，感興趣的同學(xué)可以搜索了解一下。對(duì)這些參數(shù)的調(diào)試?yán)斫馄饋砜赡軙?huì)有一些技術(shù)難度，并且在運(yùn)維起來如果有一些參數(shù)忘了就會(huì)對(duì)性能產(chǎn)生影響，所以如果有興趣可以去云+社區(qū)的ES專欄或者去社區(qū)看相關(guān)的一些文章。另外如果不想調(diào)試的話可以直接使用一些成熟的云產(chǎn)品。