如何分析Apache TubeMQ數據可靠性

這篇文章主要為大家分析了如何分析Apache TubeMQ數據可靠性的相關知識點，內容詳細易懂，操作細節(jié)合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學習“如何分析Apache TubeMQ數據可靠性”的知識吧。

1. 前言

我們在Apache TubeMQ的適用場景有介紹，TubeMQ適用于極端情況下容忍少量數據丟失的業(yè)務場景，那么TubeMQ到底在什么情況下可能會出現(xiàn)數據丟失？為什么要這么設計？同類MQ在這方面是怎么做的？這篇文檔計劃解答這幾個問題。

2. 結論

Apache TubeMQ系統(tǒng)數據存儲采用的是單節(jié)點多磁盤RAID10的副本方案進行存儲，數據只在如下場景存在可能丟失情況：

1. 機器斷電，已回復成功但還沒有被消費且處在內存中的數據會丟；機器上線后，已存儲在磁盤上的數據不受影響；

2. RAID10 hold不住的磁盤異常，已返回成功但還沒有被消費的數據會受影響；磁盤修復后，已存儲但沒有恢復回來的數據會丟失；

3. RAID10 能hold住的日常壞盤，壞盤Broker節(jié)點的生產和消費不受影響；

3. 能否給出一個量化的數據可靠性指標來評估Apache TubeMQ系統(tǒng)的可靠性？

這個問題也是交流最多的一個話題，大家最直觀的感受是：機器很容易掛，TubeMQ只有單節(jié)點，數據的可靠性是不高的。這里個人的觀點還是如其他場合介紹里一直表達的：用數據可靠性指標來反應系統(tǒng)的數據可靠性其實是不太合適，因為它只是反映了系統(tǒng)數據可靠性的果，對如何解決數據可靠性其實沒有太直接的關系；從介紹的數據可能存在丟的場景介紹我們可以看到，生產環(huán)境的機房情況、服務器硬件情況，以及業(yè)務能否即時消費完數據等直接影響到系統(tǒng)的數據可靠性，是這些內容故障導致了系統(tǒng)數據可靠性的高或者低，如果沒有上述這些問題，TubeMQ系統(tǒng)的數據可靠性其實就是100%，所以，我們應該通過對應環(huán)境導致數據可能丟失的故障率指標來評估、分析系統(tǒng)的數據可靠性，個人覺得這個是根本。

按照2019年我們線上環(huán)境的故障數據統(tǒng)計，TubeMQ集群在我們環(huán)境，全年導致數據可能丟失的故障率大概是2.67%：整個TubeMQ集群1500臺機器，日均有35萬億條的數據接入量前提下，全年大概有40臺左右的服務器出現(xiàn)過機器ping異常，以及RAID10 hold不住的磁盤組損壞異常。個人覺得我們環(huán)境的故障率指標還可以再降低，因為TubeMQ集群里用的機器多是重點業(yè)務用了幾年后淘汰下來的二手機器設備。

4. 為什么要將Apache TubeMQ設計為單節(jié)點存儲？

降成本： 大家都知道，要達到完全100%的數據可靠性是非常耗費成本的，一個MQ管道要做成類似太空飛船設計樣構造多套獨立節(jié)點的冗余數據備份，來保證數據不丟；而從我們的分析來看，通過MQ傳遞的業(yè)務數據，90%左右的數據是可以容許極端情況下丟失少量數據的，有10%左右的數據是要求一條都不能丟，比如交易流水，涉及到錢相關的日志數據等；如果我們將這10%的高可靠數據單獨拎出來處理的話，我們就可以節(jié)約大量的成本，基于這個思路，TubeMQ負責完成要求高性能、極端情況下容許數據少量丟失的數據服務。

如上圖示，除了方案上的考量外，我們在TubeMQ的存儲方案設計上也是做了仔細的斟酌：我們按照Topic維度進行了數據和索引的組件；我們在文件之上再疊加了一層內存存儲作為磁盤文件存儲的延申。但我們又沒有因為業(yè)務容忍少量丟失而完全的無所顧忌，比如：我們數據生產采用的是QoS1方案；我們的數據存儲是有強制的緩存刷盤（按條、按時間、按size）控制的刷盤控制；我們的磁盤故障是有服務端基于運營策略的Broker節(jié)點自動只讀或者下線管控（ServiceStatusHolder）；生產端針對Broker節(jié)點的服務質量也是有自動異常節(jié)點感知和算法屏蔽，等等等等，以此來達到高性能同時盡可能的提高數據的可靠性，降低數據丟失的可能。

能降多少成本？ 拿外部多個使用Kafka的廠商已經公開的運營數據來看，1萬億日均接入量，Kafka大概需要200 ~ 300臺萬兆機，按照2019年的運營數據，TubeMQ大概40 ~ 50臺萬兆機；這里還包含一些可以區(qū)分的特殊情況，比如獨立集群、特定業(yè)務份數的不同等，但機器的成本指標數據的比值應該是相差不大的。如果把這些數據指標換算成錢的話，這個節(jié)約的成本僅服務器成本都可以以億單位 來計算。

也有人會說，是不是我拿Kafka的單副本進行業(yè)務服務，就可以達到TubeMQ一樣的成本效果了？我想表達的是，如果可以的話，我們就不會耗費這么長的時間和資源去改進TubeMQ，直接使用Kafka單副本方案了，在我們開源初期做過一份全面的單Broker的性能壓測對比總結報告tubemq_perf_test_vs_Kafka，大家可以在上面找到對應的具體差異。

這里想表達的是，實際上，TubeMQ系統(tǒng)本身的數據可靠性其實并不低。這里大家有沒有想過，各個MQ，在多副本方案下，系統(tǒng)數據可靠性又有多高呢？

5. 同類MQ的多副本方案分析：

Kafka： 以我個人分析的觀點，在高性能場景下Kafka的多副本方案也只是盡力而為的保證數據多副本存儲不丟。

Kafka副本機制通過一個AR集合以及ISR集合來識別和區(qū)分副本份數以及在線同步副本數，通過replica.lag.time.max.ms參數記錄各個副本最近同步的時間來判定各個Follower是否仍與Leader處于同步在線；在0.9X版本之前Kafka還有另外一個已經去掉的replica.lag.max.messages參數，F(xiàn)ollower副本滯后Leader副本的消息數，結合起來判定失效副本。線上運行時Kafka又通過ISR的個數及請求的副本應答個數保證數據多個節(jié)點存儲：服務器端通過min.insync.replicas來確保ISR里最少處于同步狀態(tài)的副本個數，客戶端可以指定請求的Ack個數（0：不應答，1：Leader存儲即OK，-1：所有ISR節(jié)點都應答）結合起來確保數據可以被多個副本所接收。

從這個機制的設計我們可以很清晰的看到，即使是Kafka的設計者，也是很清楚數據很有可能沒有從Leader同步到各個Follower，存在復制不及時的情況，所以將ISR識別由（滯后條數，同步時間）改為了（同步時間），因為滯后量太大影響到了ISR副本數的判定。而這個ISR的副本數又影響到了對應Topic的寫入，如果Topic的ISR個數為0，原生Kafka是無法寫入消息的；為此Kafka又增加了一個unclean.leader.election.enable參數，允許未處于同步狀態(tài)的Topic副本可以選為Leader對外服務，做盡力而為的服務。

從如上分析，在大數據場景下Kafka的這種副本機制，可以滿足回溯消費業(yè)務需要，主副本所在機器故障后，已經同步到副本的數據可以被回溯業(yè)務消費到，但是，由于上述問題存在數據丟的問題，對于要求回溯并保證數據不丟的場景無法滿足；同時，這種方案資源消耗大利用率非常的低，按照2副本的配置，資源增加了至少1倍、網絡帶寬下降1/2，同時為了避免2副本形成ISR為0的情況，使用方很有可能配置3副本，從而資源增加更多而資源利用率則更低，用如此高的成本維系的卻是一個不可靠的數據服務，方案并不廉價有效；最后，Kafka在分區(qū)無副本存活時阻塞生產流量直接掉0，這對大流量環(huán)境的業(yè)務個人覺得是無法接受的，而即使采用配置3副本模式，因為3副本?；钍莿討B(tài)的，極端情況下仍然存在生產受阻問題。

Pulsar： 以我個人的分析觀點，可以保證數據不丟，但大數據場景下是有影響的。

Pulsar采用了類似Raft協(xié)議模式，多數副本寫成功即返回成功，并且是采用的服務器主動Push請求到各個Bookeeper副本節(jié)點的模式。這種實時的多副本同步方案可以滿足絕大多數的高可靠業(yè)務需要，用戶的眼睛是雪亮的，我想近期的Pulsar火熱，也是與它滿足了市場上這方面業(yè)務需求有關系。不過，如果把它放置在大數據場景下，上千的Topic上萬的Partition時，這種多副本方案就需要耗費大量的機器資源。所以，我們TEG數據平臺部對于高可靠的數據，使用的是Pulsar對內進行服務；同時我們也將我們對Pulsar的改進捐獻給社區(qū)。

TubeMQ： 就如其適用場景介紹，TubeMQ就是為了滿足在容忍極端情況下允許數據少量丟失的業(yè)務數據上報管道需求，結合業(yè)務成本、數據可靠性的要求走了一條不一樣的自研路，針對致命異常在系統(tǒng)可靠性上也達到了不一樣的效果：

1. 只要Topic分配的Broker集合里還有任意一臺Broker存活，該Topic的對外服務都可用；

2. 基于第1點，只要集群里所有的Topic都還有任意一臺Broker存活，整個集群的Topic對外服務都是可用；

3. 即使管控節(jié)點Master全部掛掉，集群里新增的生產、消費會受影響，但已注冊了的生產、消費不受影響，仍可繼續(xù)生產和消費；

TubeMQ基于有損服務的前提下采用盡可能保證數據不丟、服務不受阻的思路進行設計，力求方案簡單維護簡便：TubeMQ的設計里，分區(qū)故障并不影響Topic的整體對外服務，只要Topic有一個分區(qū)存活，整體的對外服務就不會受阻；TubeMQ的數據時延P99可以做到毫秒級，這樣保證了業(yè)務可以盡可能快的消費完數據，做到盡可能不丟；TubeMQ獨有的數據存儲方案設計性能要比Kafka的TPS至少高出50%以上（有些機型上還是翻倍的效果），同時借助存儲方案的不同，單機容納的Topic數和分區(qū)數更多，進而可以使得集群規(guī)模更大，減少維護成本。這些不一樣的考慮和實現(xiàn)結合起來從而使得TubeMQ做到低成本，高性能，高穩(wěn)定性基礎。

關于“如何分析Apache TubeMQ數據可靠性”就介紹到這了,更多相關內容可以搜索億速云以前的文章，希望能夠幫助大家答疑解惑，請多多支持億速云網站！