摘要：消息隊列Kafka是一個分布式的、高吞吐量、高可擴展性消息隊列服務，廣泛用于日志收集、監控數據聚合、流式數據處理、在線和離線分析等，是大數據生態中不可或缺的產品之一。

消息隊列Kafka

消息隊列Kafka是一個分布式的、高吞吐量、高可擴展性消息隊列服務。相比于Apache Kafka，消息隊列Kafka所提供的是全托管的服務。這里也簡單地介紹一下Apache Kafka，Apache Kafka是一個分布式的基于push-subscribe的消息系統，它具備快速、可擴展、可持久化的特點。它現在是Apache旗下的一個開源系統，作為hadoop生態系統的一部分，目前被廣泛使用在大數據場景中。

而消息隊列 Kafka 針對Apache Kafka提供全托管服務，徹底解決開源產品長期以來的痛點。用戶只需專注于業務開發，無需部署運維，低成本、更彈性、更可靠。消息隊列產品最大的特點就是全托管服務，這里主要涉及到兩個特性：兼容性和便捷性。首先，對于兼容性，消息隊列Kafka能夠100%兼容Apache Kafka，對于用戶而言，可使用各種語言的開源客戶端進行無縫接入，目前使用開源Kafka的用戶，只需要更改一個接入點就可以使用消息隊列Kafka產品。同時，消息隊列Kafka兼容Apache Kafka的所有生態。其次，對于便捷性而言，消息隊列Kafka不需要部署，用戶只要在購買消息隊列Kafka后，填入實例信息，15分鐘內就能使用消息隊列Kafka的服務了，因此是非常便捷易用的。

上述是對于消息隊列Kafka的整體介紹，接下來將分為痛點、優勢以及場景這三個模塊與大家進行較為細節的分享。首先將與大家分享目前阿里云針對于消息隊列服務所收集到的用戶痛點，以及根據這些痛點來解決問題，消息隊列Kafka所具備的優勢又是什么，最后還將與大家介紹一下消息隊列Kafka所適用的場景。

痛點：自建Kafka的煩惱

Apache Kafka運維難度大

對于Kafka而言，從用戶視角來看，是一個非常簡單的產品，其所提供的是發布與訂閱模型。那么，在對于Kafka進行運維方面而言，其難度又會非常大，這是因為它不僅僅需要關注整個集群之內像broker、controller類似的角色，還需要關注其所依賴的一些產品像ZooKeeper等。所以對于以上這些模塊的運維不僅僅涉及到參數的調優，同時隨著業務的增長，還會面臨擴縮容等問題。此外，還需要關注磁盤以及網絡情況。因此，綜上所述，自建Kafka的運維成本和運維難度都是非常大的。接下來就為大家分享一些具體的例子。

數據混亂

一些用戶反饋在自己使用Kafka集群的時候出現了數據混亂的問題。大家都知道，在Kafka集群里面存在Controller和Broker兩種角色，在Controller出現異常的情況之下，會從Broker里面自動地選擇一個Broker成為新的Controller。但是由于網絡等異常情況，最開始掛掉的Controller可能重新復活了，那么在復活之后，對于整個集群而言就會出現“腦裂”的情況。因為Controller的主要職責是管理整個集群的分區和副本的狀態，而當出現“腦裂”就會造成數據混亂的問題，而這對于用戶而言，是不可接受的。

ZooKeeper不可用

整個Kafka集群對于ZK是強依賴的，而ZooKeeper的運維工作也是龐大而復雜的。比如在運維人員對于ZooKeeper不是非常了解的情況之下，可能不知道如何部署ZooKeeper，不知道如何保證ZK在同機房或者多機房的情況下保證其一定可用，而這些往往需要運維人員的思考和權衡。而ZooKeeper上面會存儲Kafka的重要數據，當ZK不可用的情況下，整個集群的災備選組以及存儲的數據都會受到影響。

帶寬關注

對于用戶而言，自建Kafka時不僅僅需要關注其外圍的依賴產品，其實還需要關注一個在集群內部經常會遇到的問題——帶寬。站在用戶的使用角度來看，經常需要做出對于副本數的權衡。而為了提升可靠性以及容災能力，集群往往需要三副本，而當副本數量一多，那么就會涉及到機器之間的數據復制，這種情況就會增加網絡的帶寬。同時，由于Broker之間是對等的，并且需要從Controller里面同步數據。這樣一來，Controller不僅僅需要承擔自己的本身的任務，還需要對外提供服務，而就其本身的設計而言，這兩部分任務是沒有優先級先后的，所以在集群規模大的情況之下，就會引發網絡帶寬的擁堵問題。而阿里云消息隊列Kafka就已經幫助用戶解決了上述問題了，用戶不需要去做備份之間的權衡，阿里云會幫助用戶實現數據的三副本存儲，并且使得服務可用性能夠達到99.9%

磁盤運維

用戶自建Kafka還會遇到其他的一些問題，比如磁盤的運維問題。從0.110版本之后，Consumer offsets不僅僅存儲在ZK端，其可以作為一個普通的Topic存儲在Kafka集群里面。而整個Consumer offsets的留存策略決定了磁盤的占用情況，因此有可能因為設置了錯誤的參數導致磁盤的占用過高。同時，用戶經常看到的情況是：自己的集群有100T的磁盤，僅僅使用了幾十T就已經出現了不可寫的情況。大家都知道，在Producer里面可以通過兩種方式對于數據進行分區，通過Hash可能會造成Hash的傾斜，而使用RoundBobin的方式也可能導致磁盤占用不均。對于用戶而言，其可能看到的情況是用戶明明購買了很多的磁盤，磁盤也沒有被占滿，但是Producer卻已經不可寫了。而關于磁盤運維的細節問題，消息隊列Kafka就已經幫助用戶解決掉了。

數據丟失

其實，對于用戶而言，最苦惱的就是數據丟失問題。Kafka為用戶提供了三種數據存儲策略，第一種可以認為是OneWay方式，第二種相當于將一個備份的數據落盤，最后一種相當于將所有備份數據落盤才能成功。對于這三種方式的選擇過程，其實就是可用性與性能之間的博弈。在網絡負載很高或者磁盤很難寫入的情況下，就可能造成磁盤寫入失敗。同時，Kafka的數據最開始是存儲在PageCache上面的，并且會定時地刷到磁盤上，但是并不是每條消息發送成功都會存儲在磁盤上的。如果出現斷電或者機器故障的情況，存儲在內存中的數據就會丟失。此外，還有一種情況就是當單批數據量超過限制也會丟失數據。而使用消息隊列Kafka，用戶就不需要去做這些數據上面的選型的博弈和考慮，因為只要消息隊列Kafka發送數據成功，那么這些數據就會被持久化，保證了數據不會丟失。因為消息隊列Kafka做了這些優化，數據的可靠性就能夠達到8個9(即99.999999%)

消息隊列Kafka的優勢

上述與大家分享的就是消息隊列Kafka的優勢，再來總結一下。消息隊列Kafka是完全兼容Apache Kafka的，Apache Kafka所能夠用到的整個生態的產品，比如上端的Flume等產品和下端的Spark、Storm、Flink以及ES等，對于消息隊列Kafka而言也是完全兼容的。其次，消息隊列Kafka所提供的是全托管的服務，也就是說無論集群中出現的是磁盤問題、網絡問題也好，無論是Kafka本身的還是其所依賴的產品所出現的任何問題，都是有專業團隊來解決的。對于用戶而言，所能夠看到的是產品99.9%的可用性，并且能夠為用戶帶來非常穩定的狀態，而底層的技術細節則是由阿里云專業的團隊來處理的。對于高可用以及高可靠這部分而言，其與全托管是存在強關聯的。對于數據的可靠性而言，都是每一個產品所最為重視的，因為當發生了數據的丟失，就可能使得整個的業務邏輯出現錯誤，進而引發一些重大的故障。而阿里云所承諾的是當用戶使用消息隊列Kafka發送消息，只要返回所發送的消息是成功的，那么這個數據的可靠性就能夠達到8個9，這一點也是用戶所無需擔心的。同時，阿里云消息隊列為用戶提供了非常實用的業務報表以及靈活全面的業務監控體系，并且業務的監控和報表是基于用戶業務維度的，包括整個集群的磁盤水位、Topic以及Consumer Group在內的所有的用戶所關心的業務相關指標，這些內容都會沉淀在消息隊列Kafka的控制臺里面，用戶直接登錄控制臺就能夠看到整體業務的運行情況。最后一點，運行在消息隊列Kafka上的數據是非常安全的，通過VPC網絡的隔離、鑒權、加密以及黑白名單這一系列的保障能夠保證用戶的數據是非常安全的，同時消息隊列Kafka所具有的一個巨大優勢就是其購買的每一個實例都是用戶購買所獨享的，用戶之間不會因為相互影響導致整個系統出現不穩定的情況。

場景

以上為大家介紹了消息隊列Kafka的優勢，接下來為大家分享其所適用的場景。其實，可以認為消息隊列Kafka與開源的Apache Kafka所適用的場景是一樣的，不同之處在于消息隊列Kafka具有更高的可靠性以及可用性，同時不需要用戶自己進行運維。

構建日志分析平臺

淘寶、天貓平臺等公司每天都會產生大量的日志。運營、運維團隊以及一些決策人員需要對于整個的日志數據進行分析與統計。而Kafka本身的性能是非常高效的，同時Kafka的特性決定它非常適合作為"日志收集中心"，這是因為Kafka在采集日志的時候業務是無感知的，其能夠兼容自己的上游，能夠直接地通過配置加密消息。當日志數據發送到Kafka集群里面，其實對于業務而言是完全無侵入的。同時其在下游又能夠直接地對接Hadoop/ODPS等離線倉庫存儲和Strom/Spark等實現實時在線分析。在這樣的情況之下，使用Kafka，只需要用戶去關注整個流程里面的業務邏輯，而無需做更多的開發就能夠實現統計、分析以及報表。

網站活動跟蹤場景

除了實現數據分析形成報表之外，Kafka還可以實現網站活動跟蹤場景。通過Kafka可以實時地收集到網站的活動數據，比如用戶對于頁面的瀏覽、搜索以及行為等。消息隊列Kafka可以通過Topic來對于業務上面不同的數據模型進行切分的。那么，用戶可以按照注冊或者登錄以及購買等進行切分，對于下游所需要跟蹤的場景的不同，可以對接不同的處理系統，比如實時處理、實時監控以及離線處理，Kafka在這個場景里面是非常便捷易用的。

數據在流動中產生價值

前面兩個例子是將消息隊列Kafka在整個解決方案里面承擔的是數據輸入流的角色，而Kafka卻不僅僅可以充當數據的輸入流，還可以做流計算處理，比如股市走向分析、氣象數據測控、網站用戶行為分析等領域，由于在這些領域中數據產生快、實時性強、數據量大，所以很難統一采集并入庫存儲后再做處理，這便導致傳統的數據處理架構不能滿足需求。而Kafka Stream以及Storm/Samza/Spark等流計算引擎的出現，可以根據業務需求對數據進行計算分析，最終把結果保存或者分發給需要的組件。

多路轉發

大家經常會遇到的場景就是對于不同的業務維度而言，需要不同的計算方式，比如對于對賬系統而言，可能需要實時的流處理方式；對于統計分析而言，可以使用批計算方式。而使用Kafka能夠實現多路轉發，上游生產一份數據，多個下游節點都能夠獲取這份數據并做出相應的處理，因此Kafka可以完成數據多路轉發的功能。