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

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

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

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

對于監(jiān)控系統(tǒng)來說，包含幾個核心功能：數(shù)據(jù)采集、歷史數(shù)據(jù)存儲、報警，最后是繪圖展示及數(shù)據(jù)挖掘。

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

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

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

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

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

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

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

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

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

因此周期是指數(shù)據(jù)量是 5 分鐘以內(nèi)，有上報動作的數(shù)據(jù)。

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

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

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

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

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

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

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

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

一致性哈希分片

這么多數(shù)據(jù)上來不可能由一臺機器處理，因此做了一個數(shù)據(jù)分片，即一個機器只處理一部分數(shù)據(jù)，報警數(shù)據(jù)是由 Judge 做分片，繪圖數(shù)據(jù)由 Graph 做分片，這兩個都是使用一致性哈希。

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

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

狀態(tài)標記

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

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

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

雖然 Judge 內(nèi)存當中還存一些前面所說數(shù)據(jù)狀態(tài)，但也不是一個大問題。因為監(jiān)控數(shù)據(jù)是源源不斷上來，即使丟掉一些狀態(tài)，新的 Judge 實例很快就會又填充數(shù)據(jù)。

擴容

一致性哈希對擴容不是很友好，比如 20 臺 Graph 的機器如果變成 40 臺，勢必有老的 Graph 實例的一部分數(shù)據(jù)打到新的 Graph 上，因此我們做了一個自動數(shù)據(jù)遷移。

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

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

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

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

我們選擇去數(shù)據(jù)庫同步所有報警策略列表，因為策略列表整個公司不會特別多，雖然數(shù)據(jù)量多，但是策略不是特別多，比如只有幾千條或者幾萬條。

在策略數(shù)據(jù)庫做了一個簡單索引，方便數(shù)據(jù)上來之后快速定位策略，然后根據(jù)閥值看是否要需要報警處理。

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

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

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

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

時間序列數(shù)據(jù)自動歸檔

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

RRD 最大的優(yōu)點是自動歸檔。監(jiān)控數(shù)據(jù)有一個特點，不需要關(guān)心歷史監(jiān)控數(shù)據(jù)具體的值，只需知道當時的趨勢即可。

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

由于對歷史點只要能看到趨勢就行。因此監(jiān)控數(shù)據(jù)特別需要歸檔功能。比如一個小時的數(shù)據(jù)歸檔為一個點，RRD 可以幫我們做這個事情。

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

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

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

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

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

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

6. 報警事件按優(yōu)先級入隊列緩沖

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

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

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

報警的分級處理

我們將報警進行分級，從 P0、P1 一直到 P5，P0 最高。

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

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

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

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

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

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

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

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

新聞名稱：OpenFalcon在高并發(fā)場景的應(yīng)對手段有哪些
本文鏈接：http://www.sd-ha.com/article30/ghsipo.html

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

廣告

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