kafka 源碼調研系列1 特點

     kafka 相關調研不少，其中以FrankHui大神（http://my.oschina.net/ielts0909）的kafka系列文章很是精彩，悲催的是，前期調研時候沒有看到，老老實實的看完了Apache kafka官方文檔（http://kafka.apache.org/introduction.html），但仍是雲裏霧裏，和同事討論的時候發現不少細節都沒有琢磨清楚，再看kafka孵化MQ產品MetaQ(http://www.iteye.com/magazines/107)的相關資料和FrankHui的系列博文，對照官方設計文檔，有了更清楚的認識。

     kafka比較新穎的特點如如下：

     1 結合實時數據和離線大數據兩種數據處理業務，所以方便有相關需求的同志不須要搭建hadoop專門處理離線數據，然後又搭建storm等來處理實時數據；

     2 採起文件系統做爲數據存儲介質，而不是像ZeroMq之類的基於內存的mq，設計體現的好處是既能保證高吞吐率的同時，又能保證極端狀況下數據的恢復，更好的是，極大節約了內存成本。固然爲了媲美基於內存MQ的讀寫性能，kafka作了一些巧妙的設計，最突出的就是利用順序讀寫代替基於BTree的讀寫方式和Zero-copy（具體技術細節見https://www.ibm.com/developerworks/linux/library/j-zerocopy/）。另外，持久化的問題也迎刃而解。

     3 利用consumer存儲消費信息，而非傳統的broker存儲，這樣好處是避免的broker存儲時對Message的多標籤化。具體而言，若是由broker存儲消息，一條Message的消費分爲broker下發->consumer確認消費->broker確認3個狀態，中間涉及兩次網絡通訊，期間可能引發各類緣由致使的重下發，而重下發又涉及到消息回滾的排序方式。簡而言之，若是重下發的消息入隊首，可以馬上下發，減少延遲，可是可能出現該消息錯誤引發的隊列阻塞；入隊尾，可能產生很長時間的延遲。
     若是換consumer存儲消息，能夠避免上述麻煩，感受這個設計很贊，可是其存在基礎是基於kafka順序讀寫的設計方式。具體這樣作有什麼可能的弊端呢？本身當初設計相似流程的時候都在扣標籤細節，怎麼沒有想到這個思路？思惟太固化了仍是新方案有什麼缺陷？（歡迎討論）

    4 利用遊標offset來標註消費數據，能夠很是方便的回滾信息。

    5 利用語義分區實現partition，而且保證一個分區發給一個消費組裏面的一個consumer，因爲partition中消息有序，從而保證該consumer的接收消息有序，從而實習數據收發一致性，並同時保證負載均衡。

    kafka可能的問題：

    1 負載均衡問題：若是有些生產者產生的消息遠多於其它生產者，按每一個代理對TCP鏈接進行平均分配可能會致使每一個代理接收到的消息總數並不平均；

    2 消息推拉方式：kafka採用producer push消息，consumer poll消息的方式，可能會出現一些應用場景不匹配問題；

    3 partitions 沒有副本控制。

    以上問題我在kafka 0.8中已經看到有所更新，衷心佩服各位大牛！

    接下去我去繼續寫一些關於源碼和具體調試中關於kafka的一些想法。新人報道，知識水平，表達方式各方面都存在欠缺，但願你們海涵，同時也但願你們必定要多多指出不足，多多交流，謝謝。