OpenFalcon在高并發(fā)場(chǎng)景的應(yīng)對(duì)手段有哪些

本篇內(nèi)容介紹了“OpenFalcon在高并發(fā)場(chǎng)景的應(yīng)對(duì)手段有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

府谷ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場(chǎng)景，ssl證書(shū)未來(lái)市場(chǎng)廣闊！成為創(chuàng)新互聯(lián)的ssl證書(shū)銷(xiāo)售渠道，可以享受市場(chǎng)價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話(huà)聯(lián)系或者加微信：028-86922220（備注：SSL證書(shū)合作）期待與您的合作！

OpenFalcon 在高并發(fā)場(chǎng)景的 7 種應(yīng)對(duì)手段

1. 數(shù)據(jù)采集推拉抉擇

對(duì)于監(jiān)控系統(tǒng)來(lái)說(shuō)，包含幾個(gè)核心功能：數(shù)據(jù)采集、歷史數(shù)據(jù)存儲(chǔ)、報(bào)警，最后是繪圖展示及數(shù)據(jù)挖掘。

數(shù)據(jù)采集

這一塊我們希望做一個(gè)大一統(tǒng)的東西，因此要采集很多監(jiān)控指標(biāo)，比如 Linux 本身的監(jiān)控指標(biāo)，像 CPU、內(nèi)存、網(wǎng)卡、IO 等，一些硬件指標(biāo)，比如風(fēng)扇的轉(zhuǎn)速、溫度等等，再加上一些開(kāi)源軟件如 MySQL，Nginx，OpenStack，HBase 等監(jiān)控指標(biāo)。

公司內(nèi)部有很多產(chǎn)品線(xiàn)，每一個(gè)服務(wù)運(yùn)行狀況都希望采集到，比如中間層服務(wù)開(kāi)了一些 RPC 端口，每一個(gè) RPC 端口在服務(wù)過(guò)程中，latency 是多少，QPS 是多少，我們都希望了解到。

所以需要覆蓋很多監(jiān)控指標(biāo)，監(jiān)控團(tuán)隊(duì)剛開(kāi)始只有兩個(gè)人，不可能把所有監(jiān)控指標(biāo)都采集到——人力不行、技術(shù)水平也達(dá)不到。

所以我們需要共建監(jiān)控?cái)?shù)據(jù)，讓專(zhuān)業(yè)的人干專(zhuān)業(yè)的事。

DBA 同學(xué)對(duì) MySQL 比較熟，那他們?nèi)ゲ杉?MySQL 相關(guān)指標(biāo)，分布式團(tuán)隊(duì)同學(xué)去采集 HBase 或 Hadoop 等指標(biāo)，網(wǎng)絡(luò)組同學(xué)去采集交換機(jī)路由器指標(biāo)。

而作為監(jiān)控團(tuán)隊(duì)要做的，就是制訂一個(gè)規(guī)范。制定一個(gè)數(shù)據(jù)進(jìn)來(lái)的機(jī)制，然后公司開(kāi)發(fā)人員和運(yùn)維人員按照規(guī)范去推送數(shù)據(jù)。

數(shù)據(jù)收集沒(méi)有采用拉的方式，因?yàn)樘鄶?shù)據(jù)源，作為一個(gè) Client 去連接源端，采集數(shù)據(jù)，再關(guān)閉連接，會(huì)產(chǎn)生很多 time_wait 狀態(tài)連接，其吞吐必然是不高，所以要把自己做成 Server 端。現(xiàn)在每個(gè)周期有 1 億多條數(shù)據(jù)。

這個(gè)周期簡(jiǎn)單解釋一下，監(jiān)控?cái)?shù)據(jù)是一個(gè)持續(xù)上報(bào)，比如 Linux 一些基本監(jiān)控項(xiàng)一分鐘一次采集之后上報(bào)，下一分鐘再采集再上報(bào)。一些像業(yè)務(wù)監(jiān)控有 3 分鐘的，有 5 分鐘的。

因此周期是指數(shù)據(jù)量是 5 分鐘以?xún)?nèi)，有上報(bào)動(dòng)作的數(shù)據(jù)。

2. 中間節(jié)點(diǎn)快速轉(zhuǎn)發(fā)與容錯(cuò)

數(shù)據(jù)有很多要 Push 到 Server 端，Server 端最前端組件是 Transfer，Transfer 接收到數(shù)據(jù)后要把它轉(zhuǎn)發(fā)給后面兩個(gè)組件，一個(gè)是 Graph（用來(lái)做繪圖），一個(gè)是 Judge（用來(lái)做報(bào)警判斷）。

首先對(duì)每一個(gè)后端實(shí)例創(chuàng)建一個(gè) Queue 出來(lái)，比如 20 個(gè) Graph 實(shí)例，60 個(gè) Judge 實(shí)例，為每個(gè)實(shí)例創(chuàng)建一個(gè) Queue，每個(gè) Transfer 內(nèi)存中有 80 個(gè) Queue，

當(dāng)一條監(jiān)控?cái)?shù)據(jù)過(guò)來(lái)之后，需要判斷數(shù)據(jù)發(fā)到哪一個(gè)實(shí)例，然后放到這個(gè)實(shí)例對(duì)應(yīng) Queue。Transfer 接收數(shù)據(jù) RPC 邏輯非常簡(jiǎn)單，數(shù)據(jù)拿到后放到 Queue 就立馬返回。

Agent 到 transfer，transfer 到 judge，judge 到 redis，Redis 到 alarm，報(bào)警鏈路比較長(zhǎng)，如果希望盡快觸發(fā)報(bào)警，鏈路每一個(gè)環(huán)節(jié)都希望比較快速處理，用 Queue 方式，Transfer 吞吐特別大，不會(huì)拖慢整個(gè)鏈路。

數(shù)據(jù)放在 Queue 中有一個(gè)問(wèn)題，如果不及時(shí)轉(zhuǎn)發(fā)，比如后端 load 比較高或者掛了，Queue 數(shù)據(jù)就會(huì)堆積，超過(guò)內(nèi)存就會(huì) crash，所以做了一個(gè)簡(jiǎn)單保護(hù)措施，將 Queue 設(shè)成定長(zhǎng)，超過(guò) Queue 長(zhǎng)度，數(shù)據(jù)就放不進(jìn)來(lái)。

數(shù)據(jù) Push 到 Queue 后，有一個(gè)專(zhuān)門(mén)對(duì) Queue 讀入 worker，讀到了之后轉(zhuǎn)發(fā)。轉(zhuǎn)發(fā)這個(gè)動(dòng)作由一堆寫(xiě) worker 完成，這里 worker 是指 goroutine，如此這般，一堆 goroutine 協(xié)同工作，來(lái)提高轉(zhuǎn)發(fā)性能。

3. 一致性哈希分片提高吞吐容量

一致性哈希分片

這么多數(shù)據(jù)上來(lái)不可能由一臺(tái)機(jī)器處理，因此做了一個(gè)數(shù)據(jù)分片，即一個(gè)機(jī)器只處理一部分?jǐn)?shù)據(jù)，報(bào)警數(shù)據(jù)是由 Judge 做分片，繪圖數(shù)據(jù)由 Graph 做分片，這兩個(gè)都是使用一致性哈希。

一致性哈希分片有一個(gè)問(wèn)題，就是擴(kuò)縮容比較麻煩，數(shù)據(jù)打到某個(gè) judge 之后，就會(huì)一直打到這個(gè) judge。

當(dāng)列表發(fā)生變化時(shí)候，由于一致性哈希算法，原來(lái)打到一臺(tái) judge 實(shí)例的數(shù)據(jù)就會(huì)打到另外一個(gè) Judge 實(shí)例，所以 Judge 一定要保證沒(méi)有狀態(tài)，這樣才能方便擴(kuò)縮容。

狀態(tài)標(biāo)記

其實(shí)說(shuō)它沒(méi)有狀態(tài)也不太合適，judge 內(nèi)存里也存了幾個(gè)點(diǎn)。比如某一臺(tái)機(jī)器 cpu.idle 數(shù)據(jù)上來(lái)之后，連續(xù) 3 ~ 5 次達(dá)到一個(gè)特定閥值才去報(bào)警，而不是達(dá)到閥值立馬報(bào)警。像 CPU，是一直都忙碌狀態(tài)才去報(bào)警，Judge 判斷的時(shí)候它是判斷多個(gè)點(diǎn)。

產(chǎn)生報(bào)警之后，還有一些后續(xù)處理，比如對(duì)這個(gè)報(bào)警事件做一個(gè)判斷，上次產(chǎn)生事件是什么狀態(tài)，他是第幾次報(bào)警，是不是達(dá)到了最大報(bào)警次數(shù)不能再報(bào)了，避免重復(fù)報(bào)警給處理人員造成干擾。一般大家都設(shè)置報(bào)警 3 次。

因此報(bào)警事件需要記錄一個(gè)狀態(tài)，標(biāo)記是否健康，如果有問(wèn)題，記錄當(dāng)前是第幾次。Judge 狀態(tài)存在數(shù)據(jù)庫(kù)，雖然 1 億條數(shù)據(jù)上來(lái)，實(shí)際上報(bào)警數(shù)據(jù)不多，可能只有 10 萬(wàn)條數(shù)據(jù)級(jí)別，因此可以存入數(shù)據(jù)庫(kù)，這樣 Judge 就剝離了報(bào)警事件狀態(tài)。

雖然 Judge 內(nèi)存當(dāng)中還存一些前面所說(shuō)數(shù)據(jù)狀態(tài)，但也不是一個(gè)大問(wèn)題。因?yàn)楸O(jiān)控?cái)?shù)據(jù)是源源不斷上來(lái)，即使丟掉一些狀態(tài)，新的 Judge 實(shí)例很快就會(huì)又填充數(shù)據(jù)。

擴(kuò)容

一致性哈希對(duì)擴(kuò)容不是很友好，比如 20 臺(tái) Graph 的機(jī)器如果變成 40 臺(tái)，勢(shì)必有老的 Graph 實(shí)例的一部分?jǐn)?shù)據(jù)打到新的 Graph 上，因此我們做了一個(gè)自動(dòng)數(shù)據(jù)遷移。

這個(gè)自動(dòng)遷移是由于一致性哈希造成的問(wèn)題，如果用映射表做分片，在映射表這統(tǒng)一維護(hù)數(shù)據(jù)和 graph 實(shí)例對(duì)應(yīng)關(guān)系，擴(kuò)容就簡(jiǎn)單很多。

4. 數(shù)據(jù)與策略快速匹配

當(dāng)數(shù)據(jù)上來(lái)后，要判斷這個(gè)數(shù)據(jù)是不是觸發(fā)了報(bào)警策略，策略有很多種，比如我們現(xiàn)在系統(tǒng)中有幾千上萬(wàn)條。

上來(lái)一條數(shù)據(jù)之后，要判斷這個(gè)數(shù)據(jù)跟哪一條策略相關(guān)，然后再判斷閥值是多少，是不是要觸發(fā)報(bào)警。

我們選擇去數(shù)據(jù)庫(kù)同步所有報(bào)警策略列表，因?yàn)椴呗粤斜碚麄€(gè)公司不會(huì)特別多，雖然數(shù)據(jù)量多，但是策略不是特別多，比如只有幾千條或者幾萬(wàn)條。

在策略數(shù)據(jù)庫(kù)做了一個(gè)簡(jiǎn)單索引，方便數(shù)據(jù)上來(lái)之后快速定位策略，然后根據(jù)閥值看是否要需要報(bào)警處理。

為了加快策略判定，需要知道近期一些歷史數(shù)據(jù)，歷史存在 Judge 內(nèi)存中，這樣獲取速度相對(duì)來(lái)說(shuō)快一些。

第一個(gè)版本做測(cè)試時(shí)沒(méi)有放到內(nèi)存中，當(dāng)時(shí)用了 56 個(gè) Redis 實(shí)例，每個(gè)實(shí)例大概有 3,000 QPS，那時(shí)上的量不大，仍然達(dá)到了一個(gè)這么高的 QPS。由于并發(fā)高，把數(shù)據(jù)放到 Redis 中并不是一個(gè)很好的解決辦法，后來(lái)就把它放到了Judge 內(nèi)存里。這樣處理起來(lái)就快很多。

報(bào)警狀態(tài)也存在 Judge 內(nèi)存及 DB。如果每個(gè)報(bào)警判斷都去訪(fǎng)問(wèn) DB 比較耗時(shí)，所以就加載到 Judge 內(nèi)存，相當(dāng)與緩存的機(jī)制，內(nèi)存沒(méi)有再去 DB 加載。在 Judge 重啟的時(shí)候，內(nèi)存沒(méi)有數(shù)據(jù)，這時(shí)報(bào)警狀態(tài)的判斷需要去 DB 加載，然后再讀到內(nèi)存里。

5. 數(shù)據(jù)延遲寫(xiě)入，減少 RRD 文件打開(kāi)次數(shù)

時(shí)間序列數(shù)據(jù)自動(dòng)歸檔

報(bào)警數(shù)據(jù)存儲(chǔ)采用 RRD，RRD 比較有名。大量開(kāi)源監(jiān)控軟件存儲(chǔ)時(shí)間序列數(shù)據(jù)都選用 RRD。

RRD 最大的優(yōu)點(diǎn)是自動(dòng)歸檔。監(jiān)控?cái)?shù)據(jù)有一個(gè)特點(diǎn)，不需要關(guān)心歷史監(jiān)控?cái)?shù)據(jù)具體的值，只需知道當(dāng)時(shí)的趨勢(shì)即可。

最新 6 個(gè)小時(shí)可能有看原始值需求。但是最近 3 天 及 1 個(gè)月原始值的需求就很小。而且那個(gè)點(diǎn)特別多，一分鐘 1 個(gè)點(diǎn)，一天有 1440 個(gè)點(diǎn)。如果加載 1 個(gè)月瀏覽器不崩才怪。

由于對(duì)歷史點(diǎn)只要能看到趨勢(shì)就行。因此監(jiān)控?cái)?shù)據(jù)特別需要?dú)w檔功能。比如一個(gè)小時(shí)的數(shù)據(jù)歸檔為一個(gè)點(diǎn)，RRD 可以幫我們做這個(gè)事情。

RRD 優(yōu)化：延遲合并寫(xiě)入

RRD 默認(rèn)操作性能比較差，它的邏輯是打開(kāi) RRD 文件，然后去 seek，write，seek，write，最后 close 文件句柄。一個(gè)監(jiān)控指標(biāo)對(duì)應(yīng)一個(gè) RRD 文件，比如這個(gè)機(jī)器上面處理了大約 200 萬(wàn)個(gè)監(jiān)控指標(biāo)，實(shí)際上就有 200 萬(wàn)個(gè) RRD 的文件。

每次寫(xiě)入數(shù)據(jù)的時(shí)候，打開(kāi)這個(gè) RRD 文件，讀頭部信息，包含一些 meta 信息，記錄了歸檔策略、數(shù)據(jù)類(lèi)型之類(lèi)數(shù)據(jù)，然后去做寫(xiě)入操作。

如果每一個(gè)數(shù)據(jù)上來(lái)之后都做這個(gè)操作，RRD 讀寫(xiě)會(huì)造成特別大的 IO。雖然現(xiàn)在磁盤(pán)都是 SSD，但由于 IO 居高不下，于是做了一個(gè)延遲寫(xiě)入的優(yōu)化。

現(xiàn)在數(shù)據(jù)都是 1 分鐘上報(bào)一次，可能有的數(shù)據(jù) 10 秒或 30 秒上報(bào)一次。并不是上報(bào)上來(lái)立馬打開(kāi) RRD 文件寫(xiě)入，而是等 10 分鐘或者 30 分鐘，在內(nèi)存中緩存一段時(shí)間，緩存 30 個(gè)點(diǎn)或者 60 個(gè)點(diǎn)，一次性把文件打開(kāi)，一次性寫(xiě)入再關(guān)閉，這樣可以減少 RRD 文件打開(kāi)的次數(shù)，讓 IO 降低一些。

我們根據(jù)緩存的時(shí)間，比如緩存半個(gè)小時(shí)，再按照半個(gè)小時(shí)時(shí)間長(zhǎng)度來(lái)做數(shù)據(jù)打散，比如現(xiàn)在半個(gè)小時(shí)是 1,800 秒，舉個(gè)例子，1,800 秒把它做成 1,800 個(gè)槽位，每個(gè)數(shù)據(jù)上來(lái)之后平均分散到 1,800 個(gè)槽位當(dāng)中，寫(xiě)的時(shí)候慢慢地寫(xiě)，這樣做了一個(gè)打散操作，避免讓 IO 出現(xiàn)一些峰值。

6. 報(bào)警事件按優(yōu)先級(jí)入隊(duì)列緩沖

報(bào)警事件量通常不是特別大，但個(gè)別時(shí)候會(huì)比較大——觸發(fā)一些大面積報(bào)警的時(shí)候，比如某一個(gè)核心交換機(jī)掛掉了，會(huì)產(chǎn)生特別大的報(bào)警。

比如服務(wù)依賴(lài)于上游某幾個(gè)服務(wù)，上游服務(wù)掛了，所有下游服務(wù)都報(bào)警。如果核心交換機(jī)掛了，很多核心服務(wù)都受影響，核心服務(wù)受影響之后，下游很多服務(wù)就產(chǎn)生報(bào)警，這樣產(chǎn)生一個(gè)大面積報(bào)警。但通常情況下，報(bào)警量都是一個(gè)很平穩(wěn)的一個(gè)量。

當(dāng)大面積報(bào)警出現(xiàn)時(shí)，我們?nèi)匀皇菓?yīng)用 Queue 機(jī)制，用 Queue 來(lái)抹平峰值。

報(bào)警的分級(jí)處理

我們將報(bào)警進(jìn)行分級(jí)，從 P0、P1 一直到 P5，P0 最高。

基于優(yōu)先級(jí)的分級(jí)策略

P0、P1 發(fā)短信發(fā)郵件，并且是收到報(bào)警立即發(fā)； P2 這個(gè)級(jí)別發(fā)短信不是立即發(fā)，而是做一個(gè)報(bào)警合并； P3、P4 那些低級(jí)別就做報(bào)警合并，同時(shí)不發(fā)短信，只發(fā)郵件。

我們對(duì)報(bào)警事件做一個(gè)分級(jí)，每一個(gè)級(jí)別就對(duì)應(yīng) Redis 里面一個(gè)Queue。利用 Redis BRPOP 簡(jiǎn)單實(shí)現(xiàn)按照優(yōu)先級(jí)處理報(bào)警事件，即先處理 P0，再處理 P1、P2 順序。

7. 通過(guò)限制 Worker 數(shù)目發(fā)送接口限流

系統(tǒng)本身可能鏈路比較長(zhǎng)，每個(gè)鏈路都希望能夠扛住高并發(fā)，實(shí)際上在系統(tǒng)開(kāi)發(fā)過(guò)程當(dāng)中，我們依賴(lài)于其他基礎(chǔ)設(shè)施，比如內(nèi)部有 SMTP 服務(wù)器來(lái)發(fā)送郵件，有短信通道來(lái)發(fā)送短信，但是這些接口扛不住很大的并發(fā)。

當(dāng)要系統(tǒng)依賴(lài)調(diào)用幾個(gè)并發(fā)能力較差的接口，最好做一個(gè)限流。

有一個(gè)專(zhuān)門(mén)的模塊 Sender 發(fā)送報(bào)警郵件或者報(bào)警短信，它發(fā)送時(shí)候可以給它配置一個(gè) Worker 數(shù)量，大家可以理解成最多有多少個(gè)線(xiàn)程來(lái)調(diào)用發(fā)送接口。這樣就可以保護(hù)后端發(fā)送接口，不至于把它打掛。

“OpenFalcon在高并發(fā)場(chǎng)景的應(yīng)對(duì)手段有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！

新聞名稱(chēng)：OpenFalcon在高并發(fā)場(chǎng)景的應(yīng)對(duì)手段有哪些
本文鏈接：http://muchs.cn/article30/ghsipo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、自適應(yīng)網(wǎng)站、標(biāo)簽優(yōu)化、企業(yè)建站、品牌網(wǎng)站制作、品牌網(wǎng)站設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)