騰訊健康碼 16 億亮碼背後的 Elasticsearch 系統調優實踐

騰訊技術工程發表於2020-03-11
Elasticsearch

Elasticsearch（以下簡稱 ES）是近年來炙手可熱的開源分散式搜尋分析引擎，通過簡單部署，就可以輕鬆實現日誌實時分析、全文檢索、結構化資料分析等多重訴求，並將挖掘資料價值的成本大幅降低。
本文將深入介紹騰訊雲  Elasticsearch Service（以下簡稱騰訊雲 ES）在“防疫健康碼”應用落地過程中，遇到的挑戰、優化思路、優化成果，希望能為開發者們提供參考。
2 月 9 日，騰訊聯合各方推出“防疫健康碼”，民眾只需要通過微信申請涵蓋自身健康資訊的二維碼，獲得電子出行憑證，就可以在疫情期間便捷地出入公共場所。目前，騰訊防疫健康碼已落地北京、廣東、四川、雲南、上海等 20 個省級行政區，覆蓋 300 多個市縣，累計亮碼超過 16 億人次，覆蓋超過 9 億人口，累計訪問量破 60 億。
作為防疫健康碼的架構和開發者，如何在種類繁多的儲存產品中選擇出最合適業務的一款，如何能在有限的時間內高效地支援系統的快速迭代開發，另外，在突發的全國疫情應急背景下，如何快速應對萬億級資料訪問挑戰，本文就為大家揭祕健康碼背後 Elasticsearch 的系統調優實踐。

1 選型 Elasticsearch 及技術考量

防疫健康碼涉及的應用場景繁多，包括社群互掃，卡口通行，居家隔離等等。因此，在資料型別方面，需要支援常見的如通行時間，車輛資訊等這樣的結構化資訊查詢，也有如街道/社群/小區名這樣的長文字資訊。另外，伴隨著疫情防控的需要的調整，還需具備快速調整增刪欄位的功能；在查詢方面，不僅需要支援傳統的結構化資訊的查詢，還需要支援關鍵字的搜尋技術、海量資料的聚合分析技術以及地理位置區域計算技術。
在資料儲存選型過程中，我們做了一些主流產品的對比和思考：
如傳統的關聯式資料庫 MySQL，在事務型應用及多業務多表關聯查詢方面有著出色的表現，但是面對健康碼系統複雜繁多的資料型別，特別是文字關鍵字搜尋能力時顯得捉襟見肘。騰訊雲 ES 基於 lucene 查詢引擎構建，通過倒排索引結構，可以快速的通過搜尋關鍵字找到所需要的記錄，在萬億級海量資料規模性，依然能達到毫秒級的查詢響應。相比於使用傳統關係型資料庫的 like 命令進行匹配查詢，搜尋查詢效率提升了近百倍。
騰訊健康碼 16 億亮碼背後的 Elasticsearch 系統調優實踐
倒排索引結構
對於比較熱門的 NoSQL 類產品 MongoDB，雖然和 ES 一樣，能滿足多樣化的資料型別的支援，且可以根據業務的需要隨時動態的增加欄位且不影響業務正常的查詢寫入，但是同樣缺少文字關鍵字的檢索能力。且相比於 ES 來說，缺少海量資料的分析聚合能力及圖形化的 UI 元件。騰訊雲 ES 通過 doc_value 列存結構及聚合框架，支援包括按關鍵字分桶、時間分桶、距離分桶、求平均值、求和、求地理位置邊界等等，多達 60 種聚合運算元。
騰訊健康碼 16 億亮碼背後的 Elasticsearch 系統調優實踐

配合 kibana 元件的 UI 能力，可以通過圖形化的方式進行海量資料的分析。同時，通過配置圖形報表等形式，簡化運營分析人員的開發複雜度，最終能使防疫相關的部門及人員，通過 ES 的資料分析能力，做到對於疫情防控的情況瞭如指掌。
在海量資料的儲存方面，雖然相當多的大資料產品，如 hive 數倉、Hbase 等，擁有海量的資料儲存能力，且具備一定的資料分析能力，但是相比於 ES 來說，不僅整個技術棧及架構比較重，需要維護的開源元件繁多，通常需要一支專門的運維團隊進行叢集的日常維護。對於開發人員來說，開發方法及介面較為複雜，對於初次接觸大資料平臺的開發者來說需要具備相當多的基礎知識後才能開始上手開發。
騰訊雲 ES 使用 Restful 風格的 API，在上手除錯方面要簡單很多，且提供了多達 10+的官方 SDK 及 20+的社群 SDK，基本覆蓋了市面上所有的主流開發語言。社群生態十分活躍，文件齊全，生態元件豐富。通過 SDK 及生態元件的整合，減少了大量的編碼工作，極大的加快了開發的流程，可以高效的應對緊急業務開發上線的需求。

2 業務資料極速增長，如何快速擴容

隨著疫情防控在全國範圍內的鋪開，接入健康碼的省市自治區快速的增加，截止目前已掃碼次數達 16 億次，覆蓋 9 億使用者。如何應對業務急速的資料查詢增長，對資料儲存系統構成了極大的挑戰。
騰訊健康碼 16 億亮碼背後的 Elasticsearch 系統調優實踐
騰訊雲 ES 採用分散式架構，索引資料通過分割槽演算法，分割為多個資料分片（shard），平均的分佈在叢集的多個節點上。通過節點和資料分片的能力，可以線性的擴充套件索引資料寫入查詢的吞吐，這個是傳統的單例項資料庫所不具備的。
由於健康碼系統內部的資料，隨著疫情的進展會持續的增長且很難預測資料的最終量級，需要能比較靈活的增加 ES 的儲存空間。在使用者自建的叢集上，如果需要節點的配置升級，通常需要採購插拔新的儲存裝置，或者需要將新的節點加入到叢集中，等待資料從老的節點上進行遷移。這個過程通常會持續小時到天之久，通常由叢集的資料規模所決定。
騰訊雲 ES 構建於基礎 IaaS 層之上，使用 CVM 及 CBS 雲硬碟，具有一定的儲存計算分離能力。儲存空間可以動態的擴充套件，對於 ES 節點來說完全是透明的，無感知的。類似健康碼這樣的資料規模不斷增長的需求，一次儲存空間的擴充套件操作從過去的小時或天的級別降低到了秒級，且所有的叢集變更操作都可以在騰訊雲控制檯上進行，極大的降低了叢集配置變更的運維複雜度，把後臺業務人員從繁重的運維工作中解脫出來。

3 騰訊雲 ES 服務高可用技術架構

在疫情防控任務面前，任何環節不容有失，需要儲存系統能 7*24 小時不間斷的提供服務，提高服務可用性，保證整個健康碼系統的穩定性。

騰訊健康碼 16 億亮碼背後的 Elasticsearch 系統調優實踐

騰訊雲ES支援多可用區叢集容災功能

騰訊雲 ES 服務支援多可用區容災的功能，當一個可用區因為機房電力、網路等故障的原因導致不可用時，另外一個可用區的節點仍然能穩定、不間斷的提供服務，保障客戶業務的可靠性。
這也是基於 ES 的分散式原理，當使用者選擇使用支援多可用區容災的騰訊雲 ES 叢集后，系統會為使用者在多個可用區部署節點，且節點會平均的部署到各個可用區機房中。由於索引資料是可以進行分片，且設定副本。根據 ES 的分片分配原理，所有的分片及副本會平均的分佈在所有的節點之上。這就保證了，如果設定的副本數和可用區數目一致，當有一個節點乃至一個可用區機房不可用，剩餘節點中的分片仍是一份完整的資料，且主從分片可以自動切換，叢集仍然可以持續的對外提供寫入查詢服務。
防疫工作機構及人員需要每天及時掌握疫情的防控情況，需要不定時的對資料進行彙總分析查詢。然而，在全國海量的防疫資料場景下，叢集很容易由於不嚴謹的聚合分析語句導致大量的資料在節點記憶體中進行分桶，排序等計算，從而使節點發生 OOM 的問題，造成節點乃至整個叢集的雪崩。
為了防止此類情況發生導致的叢集不可用，騰訊雲 ES 在儲存核心上開發了基於實際記憶體的熔斷限流機制。當叢集發現部分節點的 JVM 使用率超過設定的熔斷閥值，會進行服務降級，梯度的攔截部分查詢的請求，直至 JVM 使用率超過 95%會最終熔斷，阻止所有的查詢請求。這個熔斷的請求攔截機制會覆蓋 Rest 層及 Transport 層，通過將熔斷提前至 Rest 層，可以儘早的將請求進行攔截，降低叢集在熔斷狀態下的查詢壓力。通過這些措施，保證了健康碼小程式海量查詢下的服務可用性及查詢效能。

4、資料安全，萬無一失

近年來，海內外資料洩露事件頻出。健康碼系統使用的騰訊雲 ES 在安全方面做了最高階別的優化，包括支援配置內外網訪問黑白名單，支援叢集許可權認證功能。極大的提高了資料的安全性。並且，不同使用者叢集之間通過 VPC 進行網路隔離，杜絕了潛在的黑客入侵的風險。
騰訊健康碼 16 億亮碼背後的 Elasticsearch 系統調優實踐

騰訊雲 ES 支援基於 COS 的增量資料備份功能，使用者可以通過 ES 原生的索引生命週期管理功能，定時增量的備份底層的資料檔案到騰訊雲物件儲存 COS。當需要的時候，可以隨時將資料備份恢復至任意的叢集，保證了資料的安全可靠性，做到資料的萬無一失。
結語：
騰訊防疫健康碼目前已廣泛應用於機場、火車站、高速公路、商業區、小區等防疫檢查卡口，有效幫助衛生防疫部門全面排查疑似患者，阻擊疫情的快速傳播。健康碼能如此穩定安全的支撐 10 億級別的資料訪問，騰訊雲 ES 在資料搜尋查詢、高併發、彈性擴充套件以及安全領域的技術功不可沒，後續騰訊雲將繼續針對使用者需求，不推打磨技術和產品，為更多使用者提供穩定安全可靠的 Elasticsearch 服務。


來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559354/viewspace-2679674/，如需轉載，請註明出處，否則將追究法律責任。

相關文章