今天下午參加了騰訊雲+社區組織的kafka公開課，收穫良多。正巧在工作中也遇到過kafka的問題，今天聽完之後產生了非常多的感想。無奈篇幅有限，本人又文筆愚鈍，所以今天的分享主要提及對我感觸最深的內容。分享的順序還是按照老形式來進行吧（提出疑問——解決疑問）
【提出疑問】
1、爲什麼要設計kafka？
2、開源的kafka架構是怎麼樣的？
3、騰訊雲的ckafka架構是怎樣的？
4、騰訊雲的ckafka架構解決了什麼樣的問題？
5、我對開源kafka的設想？
一、爲什麼要設計kafka？
擴容性
過去生產消費模型採用的消息隊列一般爲RabbitMQ、ZeroMQ（最快）等。這些消息隊列對於數據的處理量存在一個上限，也就是說隨着信息化的數據爆炸式增長會出現一個吞吐量的瓶頸。下圖是我在網上找的圖，表示的是以往消息隊列的形式。過去MQ的瓶頸存在的原因在於這個隊列不能很好的支持擴容。舉個通俗點的例子來說過去的MQ是一條鄉間小路，路的大小是事先設計好的。而kafka則是一條高速公路，且這條高速公路可以根據業務的需求進行擴展（流量大時採用5車道，閒時採用2車道）。因此這同時也是一種非常節約資源的解決方案。
統一處理
上圖表示的是以前的處理方式。舉個案例來說，現在公司裏有兩個數據源（oracle和mysql），我需要給每個業務都定義一個使用數據庫的接口。然而隨着公司業務的不斷擴展，數據源的種類越來越多，添加了諸如redis等，同時業務的變更也擴展地非常快。這時如果對每個業務都編寫一個接口就會顯得非常麻煩。kafka則可以很好的應對上述場景，這也是基於避免重複造輪子的思想。
上圖是簡單的kafka架構。kafka的開源版本里提供了很多數據源的接口，業務只需要對kafka集羣進行連接就可以實現對數據的抓取。與此同時，kafka集羣還可以進行對數據的篩選。也就是後面會提到的日誌存儲。
二、開源的kafka架構是怎麼樣的？
Broker
Kafka集羣包含一個或多個服務器，這種服務器被稱爲broker
Topic
每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）
Partition
Parition是物理上的概念，每個Topic包含一個或多個Partition.
Producer
負責發佈消息到Kafka broker
Consumer
消息消費者，向Kafka broker讀取消息的客戶端。
Consumer Group
每個Consumer屬於一個特定的Consumer Group（可爲每個Consumer指定group name，若不指定group name則屬於默認的group）。
topic&partition理解
每個topic都可以看成是一個隊列，消費必須指定它的topic。爲了使得Kafka的吞吐率可以線性提高，物理上把Topic分成一個或多個Partition，每個Partition在物理上對應一個文件夾，該文件夾下存儲這個Partition的所有消息和索引文件。
日誌存儲
開源kafka的日誌存儲可以實現數據解耦、多消費者讀取等功能。如下圖所示
對於傳統的message queue而言，一般會刪除已經被消費的消息，而Kafka集羣會保留所有的消息，無論其被消費與否。當然，因爲磁盤限制，不可能永久保留所有數據（實際上也沒必要），因此Kafka提供兩種策略刪除舊數據。一是基於時間，二是基於Partition文件大小。
HA
爲了提高Kafka的容錯能力，需要將同一個Partition的Replica儘量分散到不同的機器。如果某個Broker宕機了，需要保證它上面的負載可以被均勻的分配到其它倖存的所有Broker上。此外，還涉及了投票選舉機制。也就是說當一個leader掛了之後會投票選出一個新leader。（具體機制改天再整理出個詳細的文檔）。
開源的kafka架構是將各個topic冗餘備份分步到各個broker上，當一個broker掛了之後能夠很快的根據備份信息恢復。
數據篩選
開源kafka支持sql、java、python等語言的過濾程序。下圖是基於sql改良的ksql
三、騰訊雲的ckafka架構是怎樣的？
騰訊雲ckafka項目在開源kafka項目的基礎上做了很多的改進，下圖是ckafka的特點
ckafka的現狀
1、日消息超萬億條、總流量數十PB級，單集羣每分鐘達十億
2、broker數量上千，集羣有上百個
3、服務付費實例超千個，topic也過千
總的來說就是日消息量、日吞吐量、集羣分鐘吞吐量都非常龐大
broker的選擇
新建實例時，如何選擇broker才能保證資源的充分利用？針對這一問題，騰訊雲是基於帶寬和磁盤容量來判斷的。會根據broker中存儲的topic類別，來存放最類似的topic到這個集羣。
實例的升配
在升配方面，首先會預估節點變更的可能性和資源的利用率，其次會計算遷移的代價。也就是當容量不夠的時候存在兩種情況：1、分區節點有冗餘，這種情況會直接升級2、broker資源不足，這時就要進行遷移重新劃分資源。當新節點加入後還需要進行機器的負載均衡、節點資源的碎片整理。
實例的遷移
據我的感受而言，騰訊雲在遷移方面做的是最好的。大概存在三種情況會需要遷移：服務異常、實例擴縮容、負載均衡。
遷移又涉及到三種情況：
1、leader遷移：數據遷移代價較小，可能會造成cpu負載及網卡出流量
2、replica遷移：代價比較大，會消耗非常多的機器資源
3、遷移對象和目的地的考量：數據大小、生產/消費速率、資源利用率
四、騰訊雲的ckafka架構解決了什麼樣的問題？
我印象最深的主要有3點改良：
1、在高負載情況下的調優
2、增強了容錯機制
3、增強了故障處理機制
五、我對開源kafka的設想？
就我愚見，目前kafka在故障應對機制方面還不是很強。現在只能做到事故發生後再處理。如果能夠事先收集各種故障的信息，進行數據分析，使其能夠在故障前自動的處理就能夠將故障扼殺在搖籃中。
由此略微展開聯想，可以設計一種信息收集組件並提供自定義行爲接口，用戶能夠自行通過接口設計故障前的行爲。這也是我對未來運維的展望——工程師能夠專注於處理隱患機器，故障判斷交予機器。