應用運維管理平臺（AOM）和 Cassandra 是兩個不可分割的組成部分，它們共同構成了一個高效的解決方案，可以幫助企業(yè)在應用運維業(yè)務上取得巨大的優(yōu)勢。在這篇文章中，我們將介紹 AOM 和 Cassandra 的優(yōu)勢和特點，揭曉它們如何為企業(yè)保持市場競爭力的秘密。

導讀

隨著容器技術的普及，越來越多的企業(yè)通過微服務框架開發(fā)應用，業(yè)務逐漸轉變?yōu)樵粕蠈崿F(xiàn)服務，運維也逐漸轉向云上運維服務。在此環(huán)境下，云上應用的運維也遭遇了新的挑戰(zhàn)：

1.運維人員技能要求高，需要同時維護多套系統(tǒng)，配置繁雜。分布式追蹤系統(tǒng)的學習和使用成本高，穩(wěn)定性差，性價比低。

2.云化場景下的分布式應用問題分析困難，主要表現(xiàn)在如何可視化微服務間的依賴關系，如何提高應用性能體驗，如何將散落的日志進行關聯(lián)分析，以及如何快速追蹤問題。

針對以上挑戰(zhàn)，AOM 應運而生。

AOM 是什么

AOM 是由華為云研發(fā)的云上應用一站式立體化運維管理平臺，由應用資源管理、監(jiān)控中心（可觀測性分析）、自動化運維、采集管理四個子服務構成，提供一站式可觀測性分析和自動化運維方案，支持快速從云端和本地采集指標、日志和性能等數(shù)據，幫助用戶及時發(fā)現(xiàn)故障，全面掌握應用、資源及業(yè)務的實時運行狀況，提升企業(yè)海量數(shù)據運維的自動化能力和效率。

AOM 優(yōu)勢眾多，功能強大，其背后離不開支撐其海量數(shù)據運轉的智能數(shù)據底座——華為云 GaussDB(forCassandra)。

為什么選擇 GaussDB(forCassandra)？

華為云 GaussDB(forCassandra)是一款兼容 Cassandra 生態(tài)的云原生 NoSQL 數(shù)據庫，支持類 SQL 語法 CQL。在華為云高性能、高可用、高可靠、高安全、可彈性伸縮的基礎上，提供了一鍵部署、快速備份恢復、計算存儲獨立擴容、監(jiān)控告警等服務能力，尤其適用于各種海量數(shù)據處理和高并發(fā)業(yè)務場景。

出現(xiàn)數(shù)據熱點的業(yè)務。例如：某新聞時事 APP 需要管理大量新聞時事數(shù)據，當出現(xiàn)社會熱點事件時，相關新聞數(shù)據請求量急劇升高，此時需要保障 APP 正常運作，以及保持請求成功率穩(wěn)定。

需要對時序數(shù)據建模的業(yè)務。例如：某氣象站需要每分鐘采集一次溫度，并存儲該次采集結果，同時需要保障數(shù)據的時效性，自動刪除過期數(shù)據。

需要對會話消息數(shù)據建模的業(yè)務。例如：某社交 APP 需要存儲大量的用戶及會話消息，需要保障用戶在不同會話消息間切換時耗時低、成功率高、響應時間短。

需要高速處理數(shù)據的業(yè)務。例如：某業(yè)務需要迅速處理來自不同設備或傳感器的數(shù)據。

需要實時監(jiān)測數(shù)據的業(yè)務。例如：某運維平臺需要實時監(jiān)測不同維度的數(shù)據，準確采集指標，快速完成運維。

需要使用社交媒體分析和推薦引擎的業(yè)務。例如：某電商 APP 需要分析用戶喜好商品，基于用戶喜好實現(xiàn)商品推薦，提升用戶體驗和產品競爭力。

……

此外，華為云 GaussDB(forCassandra)特性豐富，適用于廣泛業(yè)務場景。

大數(shù)據應用：GaussDB(forCassandra)可以處理海量數(shù)據，支持高吞吐量和低延遲的讀寫操作，因此適合大數(shù)據應用場景。

互聯(lián)網應用：GaussDB(forCassandra)可以處理高并發(fā)的讀寫請求，支持多數(shù)據中心部署，因此適合互聯(lián)網應用場景。

時間序列數(shù)據：GaussDB(forCassandra)支持時間序列數(shù)據的存儲和查詢，因此適合需要存儲和查詢時間序列數(shù)據的應用場景，如物聯(lián)網、日志分析等。

高可用性業(yè)務。GaussDB(forCassandra)采用多副本復制的方式來保證數(shù)據的可用性和可靠性。當一個節(jié)點出現(xiàn)故障時，系統(tǒng)可以自動將數(shù)據從其他節(jié)點中恢復，從而保證數(shù)據的完整性和一致性。

可伸縮性業(yè)務。GaussDB(forCassandra)可以輕松地擴展到數(shù)百個節(jié)點，處理 PB 級別的數(shù)據集，同時還支持動態(tài)添加和刪除節(jié)點，可以根據實際需求靈活地調整系統(tǒng)的規(guī)模和性能。

分布式存儲應用。GaussDB(forCassandra)采用分布式存儲的方式，將數(shù)據分散存儲在多個節(jié)點上，每個節(jié)點都可以獨立地處理讀寫請求。這種方式可以有效地提高數(shù)據的可用性和可靠性，同時也可以提高系統(tǒng)的吞吐量和擴展性。

分布式查詢應用：GaussDB(forCassandra)支持分布式查詢，可以將查詢請求分發(fā)到多個節(jié)點上并行處理，從而提高查詢的效率和響應速度。

……

綜上所述，GaussDB(forCassandra)非常適合大數(shù)據分析、實時數(shù)據處理、社交網絡、物聯(lián)網、分布式存儲和查詢等應用場景。

真實場景解讀——數(shù)據熱點問題

AOM 功能強大，涉及多種典型業(yè)務場景，如數(shù)據熱點、時序數(shù)據、實時監(jiān)測等，因此選擇 GaussDB(forCassandra)作為底層數(shù)據支撐引擎。接下來就數(shù)據熱點問題作為切入點，揭秘 GaussDB(forCassandra)如何保障 AOM 在發(fā)生數(shù)據熱點時穩(wěn)定運行。

場景復現(xiàn)：

監(jiān)控運維海量數(shù)據時，表中特定數(shù)據訪問頻率驟升，部分分區(qū)產生熱點流量。表中主鍵設置不合理，某個分區(qū)下的業(yè)務量驟增，流量沖擊會集中在一個分區(qū)上，導致該分區(qū)對應的 token 所在節(jié)點的 CPU 持續(xù)居高不下。

問題根因：

GaussDB(forCassandra)是一個面向大數(shù)據場景的高度可擴展的高性能分布式數(shù)據庫，可用于管理海量的結構化數(shù)據。在業(yè)務使用的過程中，隨著業(yè)務量和數(shù)據流量的持續(xù)增長，一些業(yè)務的設計弊端逐漸暴露出來，降低了集群的穩(wěn)定性和可用性。例如主鍵設計不合理、單個分區(qū)的記錄數(shù)或數(shù)據量過大、出現(xiàn)超大分區(qū)鍵等問題，導致了節(jié)點負載不均衡、集群穩(wěn)定性下降等現(xiàn)象，這一類問題統(tǒng)稱為大 key 問題。產生大 key 的最主要原因是主鍵設計不合理，導致單個分區(qū)的記錄數(shù)或數(shù)據量過大。一旦某個分區(qū)存在海量數(shù)據時，對該分區(qū)的訪問會導致分區(qū)所在 server 的負載變高，嚴重時甚至會導致節(jié)點 OOM 等后果。

在日常生活中，經常會發(fā)生各種熱門事件，例如應用中對某熱點新聞進行上萬次的點擊瀏覽和評論時，會形成一個較大的請求量，這種情況下會在短時間內對同一個 key 頻繁操作，導致該 key 所在節(jié)點的 CPU 負載飆高，從而影響該節(jié)點上的其他請求，導致業(yè)務成功率下降。諸如此類的還有熱門商品促銷，網紅直播等場景，這些典型的讀多寫少的場景也會產生數(shù)據熱點問題。當某個 key 的請求在某一主機上的訪問超過 server 極限時，會導致熱 key 問題的產生。大 key 往往是熱 key 問題的間接原因。熱 key 會造成以下危害：流量集中，達到物理網卡上限；請求過多，緩存分片服務被擊垮；數(shù)據庫擊穿，引起業(yè)務雪崩等。

在上述場景中，主要是表中主鍵結構不合理，從而導致大 key 和熱 key 的產生，表結構如下所示。movie 表保存了短視頻的相關信息，分區(qū)鍵為 movieid，并且保存了用戶信息（uid）。如果 movieid 對應的視頻是一個熱門短視頻，有幾千萬甚至上億用戶點贊此短視頻，則該熱門短視頻所在的分區(qū)非常大。

CREATETABLEmovie(

movieidtext,

appidint,

uidbigint,

accessstringtext,

movienametext,

access_timetimestamp,

PRIMARYKEY(movieid,appid,uid,accessstring,moviename)

)

解決方案：

調整表結構。GaussDB(forCassandra)與其他數(shù)據庫相比，具有更加靈活的數(shù)據結構，支持主鍵和分區(qū)鍵的靈活設置，通過合理設置主鍵和分區(qū)鍵，調整表結構與查詢語句，對表中數(shù)據進行劃分，能夠有效優(yōu)化查詢速度，提升運維效率。在上述場景中，movie 表的主鍵設置不合理，查詢數(shù)據量十分龐大，耗時久。創(chuàng)建新表為如下所示表結構時，表中數(shù)據量顯著減少。新表用于保存熱門短視頻信息，只保留短視頻公共信息，不包含用戶信息，確保該表不會產生大的分區(qū)鍵。

CREATETABLEhotmovieaccess(

movieidtext,

appidint,

accessstringtext,

accesstimetimestamp,

PRIMARYKEY(movieid,appid)

)

使用緩存。緩存可以提高讀操作的響應性，需要使用額外的內存來存儲數(shù)據，從而盡可能減少必須完成的磁盤讀。隨著緩存大小的增加，可以從內存提供服務的“命中”數(shù)也會增加。GaussDB(forCassandra)內置的緩存包括鍵緩存和行緩存等類型。鍵緩存存儲了分區(qū)鍵與行索引之間的一個映射，以便于更快地訪問存儲在磁盤上的 SSTable；行緩存可以為每個分區(qū)緩存一定的行，提高頻繁訪問的行的讀取速度。

在上述場景中，可以使用緩存來緩解流量沖擊。業(yè)務應用先從緩存中讀取熱點信息，沒有查詢到則從數(shù)據庫中查詢，減少數(shù)據庫查詢次數(shù)。整體邏輯流程如下所示。

數(shù)據熱點檢測工具：

數(shù)據熱點會給業(yè)務帶來壓力，影響業(yè)務正常運行。出現(xiàn)數(shù)據熱點后再去解決為時已晚，因此需要預知數(shù)據熱點問題，提前設計解決方法，保證業(yè)務正常運行。為此，GaussDB(forCassandra)為業(yè)務提供了大 key 和熱 key 的檢測和預警工具。

大 key 檢測。通過大規(guī)模業(yè)務觀察學習，GaussDB(forCassandra)定義超過以下任意閾值的 key 即為大 key：1.單個分區(qū)鍵的行數(shù)不能超過 10 萬行；2.單個分區(qū)的大小不超過 100MB。

熱 key 檢測。通過大規(guī)模業(yè)務觀察學習，GaussDB(forCassandra)定義訪問頻率大于 100000 次/min 的 key 即為熱 key。

GaussDB(forCassandra)支持大 key 和熱 key 的檢測和告警工具，客戶可根據實際業(yè)務需求，在產品界面配置實例的大 key 和熱 key 告警。同時，在發(fā)生大 key 和熱 key 事件時，系統(tǒng)會第一時間發(fā)送預警通知，客戶可在產品界面查看監(jiān)控事件數(shù)據，及時處理相關告警，避免業(yè)務波動。

總結：

針對數(shù)據熱點問題，GaussDB(forCassandra)提供了大 key 和熱 key 的實時檢測，以幫助業(yè)務進行合理的方案設計，規(guī)避業(yè)務穩(wěn)定性風險；提供了大 key 和熱 key 的實時監(jiān)控，確保第一時間感知業(yè)務風險；提供了大 key 和熱 key 的解決方案，在面對大數(shù)據量洪峰場景時，增強了集群的穩(wěn)定性與可用性，為客戶業(yè)務持續(xù)穩(wěn)定運行保駕護航。

綜上所述，在線業(yè)務在使用 GaussDB(forCassandra)時，必須執(zhí)行相關的開發(fā)規(guī)則和使用規(guī)范，在開發(fā)設計階段就降低使用風險。一般按照“制定規(guī)范”→“接入評審”→“定期巡檢”→“優(yōu)化規(guī)則”的治理流程進行。合理的設計一般會降低大部分風險發(fā)生的概率，對于業(yè)務來說，任何表的設計都要考慮是否會導致大 key 和熱 key 的產生、是否會造成負載傾斜的問題。另外需要建立數(shù)據老化機制，表中的數(shù)據不能無限制的增長而不刪除或者老化。針對讀多寫少的場景，要增加緩存機制，來應對讀熱點問題，提升查詢性能；針對每個分區(qū)鍵以及每行數(shù)據，要控制其大小，超出限制后要及時優(yōu)化，否則將影響性能和穩(wěn)定性。

結論

AOM 和 GaussDB(forCassandra)的組合成功打造了一套高效、可擴展、高性能、靈活和可定制的海量數(shù)據監(jiān)控運維平臺，可以幫助企業(yè)更好地管理和利用監(jiān)控數(shù)據，提高運維效率，助力企業(yè)在不斷變化的市場環(huán)境中保持競爭優(yōu)勢。

審核編輯黃宇