一、介紹
Kafka在世界享有盛名，大部分互聯網公司都在使用它，那麼它到底是什麼呢?
Kafka由LinkedIn公司於2011年推出，自那時起功能逐步迭代，目前演變成一個完整的平臺級產品，它允許您冗餘地存儲巨大的數據量，擁有一個具有巨大吞吐量(數百萬/秒)的消息總線，並且支持實時流任務處理。總的來說，Kafka是一個分佈式，可水平擴展，容錯的日誌提交系統
這些描述都非常抽象，讓我們一個接一個地理解它們的意思，隨後深入探討其工作原理。
二、分佈式
分佈式系統意味着不同機器上的服務實例一起工作成一個整體爲用戶提供完整的服務，Kafka的分佈式體現在存儲、接收信息、發送信息在不同的節點上，它帶來的好處是可擴展性和容錯性。
三、水平可擴展
我們先給垂直可擴展下一個定義，比如說，你的傳統數據庫服務開始變得超負載，可以通過簡單地擴充該服務器資源(CPURAMSSD)緩存這個問題，這就叫垂直擴展-單點增加資源，不過有兩大致命的缺點：底層硬件資源有限、需要停機操作。反之，水平擴展通過增加更多的機器部署服務解決類似問題。
四、容錯
分佈式系統被設計成可容許一定程序的錯誤，不像單點部署發生異常時整體服務都將不可用，有五個節點的Kafka實例，即使有2個節點宕機了仍能繼續工作。
五、commit日誌
一個commit日記類似預寫式日記(WAL)和事務日記，它是可追加的有序的持久化數據，無法進行修改或者刪除。
這種結構是Kafka的核心，它具備排序功能，而排序則可以保證確定性的處理，這兩者都是分佈式系統中的重要問題。
Kafka通常會將消息持久化到磁盤上，它充分利用磁盤的有序讀取特性，讀寫的時間複雜度都爲O(1),這是相當了不起的，另外讀取和寫入操作不會相互影響，寫入不會加鎖阻塞讀取操作。
六、如何工作的
生產者發到消息至Kafka Node節點，存儲在主題Topic中，消費者訂閱主題以接收消息，這是一個生產訂閱模式。爲了使一個節點Topic的數據量不至過大，Kafka引入分區的概念，從而具備更好的性能和伸縮性。Kafka保證分區內的所有消息都按照到達順序排序，區分消息的方式是通過其偏移量offset，你可以將其理解爲普通數組的下標索引。
Kafka中Broker服務節點是愚蠢的，消費者是聰明的，Kafka不會記錄消費者讀取的操作和刪除消息，相反，數據被存儲一段時間或者達到一定的大小閾值，消費者可以自由調整偏移量offset以重複獲取他們想要的消息或者捨棄。
值得注意的是爲了避免進程兩次讀取相同的消息，Kafka引入了消費者組的概念，其中包含一個或者多個消息者實例，約定每個組只能同時有一個實例消費分區的消息。不過這引來了一個麻煩，連社區也無力解決，也就是Kafka中的重平衡Rebalance問題,它本質是一種協議，規定一個消費者組下的所有消費者實例如何達成一致，來分配訂閱主題的每個分區，當組成員數發生變更、訂閱主題數發生變更、訂閱主題的分區數發生變更時都會觸發Rebalance，從而達到最公平的分配策略，不過他和GC的STW類似，在Rebalance期間，所有的消費者實例都會停止消費，然後重新分配連接。我們應該儘量避免這種情況的發生，儘量讓消費實例數等於分區數。
七、持久化至磁盤
正如前面提及的，Kafk將消息存儲至磁盤而不是內存RAM，你或許會驚訝它是如何做出這種選擇的，背後應該有許多優化使其可行，沒錯，事實上優化點包括：
Kafka的通信協議支持消息合併，減少網絡流量傳輸，Broker節點一次持續存儲大量數據，消費者可以一次獲取大量的消息
操作系統通過提前讀入(read-ahead)和write-behind緩存技術，使得磁盤上的線性讀寫速度快，現代磁盤速度慢的結論是基於需要磁盤搜索的場景
現代操作系統引入頁面緩存(Page cache)技術，頁緩衝由多個磁盤塊構造，在linux讀寫文件時，它用於緩存文件的邏輯內容，從而加塊對磁盤映射和數據的訪問
Kafka存儲消息使用的是不可變的標準二進制格式，可以充分利用零拷貝技術(zero-copy),將數據從頁緩存直接複製到socket通道中
八、數據分佈式和複製
我們來談談Kafka如何實現容錯以及如何在節點間分配數據。
Kafka將分區數據拷貝複製到多個Brokers節點上，避免某個Broker死亡導致數據不可達。每時每刻，一個Broker節點”擁有”一個分區，並且是應用程序從該分區讀取寫入的節點，這稱爲分區leader，它將收到的數據複製到其他N個Broker節點上，它們稱爲follower,並準備好在leader節點死亡時被選舉爲leader。這種模式使得消息不易丟失，你可以根據消息的重要程序合理調整replication factor參數，下圖是4個Broker節點，擁有3個複製副本的示例：
你或許會有疑問，生產者或者消費者是如何正確得知分區的leader是哪個節點的?事實上，Kafka將這些信息保存到Zookeeper服務中。
九、Zookeeper服務
Zookeeper是一個分佈式KV對目錄存儲系統，特點是可靠性高、讀取性能高，但是寫入性能差，常被用於存儲元數據和保存集羣狀態，包括心跳、配置等等。
Kafka將以下消息保存至Zookeeper中：
消費者組的每個分區的偏移量，不過後來Kafka將其保存至內部主題__consumer_offsets中
訪問權限列表
生產者和消費者速率限定額度
分區leader信息和它們的健康狀態
十、Controller控制器
一個分佈式系統肯定是可協調的，當事件發生時，節點必須以某種方式做出反應，控制器負責決定集羣如何做出反應並指示節點做某事，它是功能不能過於複雜的Broker節點，最主要的職責是負責節點下線和重新加入時重平衡和分配新的分區leader。
控制器從ZooKeeper Watch事件中可以得知某個Broker節點實例下線(或者節點過期，一般發生於Broker長時間繁忙導致心跳異常)的情況，然後做出反應，決定哪些節點應成爲受影響分區的新leader，然後通知每個相關的follower通過leaderAndlsr請求開始從新的leader複製數據。
從上面可以得知，原本作爲分區leader的Broker節點實例重啓後，它將不再擔任任何分區的leader，消費者也不會從這個節點上讀取消息，這導致了資源的浪費，幸運的是，Kafka有一個被稱爲優先副本(preferred leader replica)的概念-你可以理解成原先爲該分區leader節點(通過broker id區分)的副本,如果該副本可用，Kafka會將集羣恢復成之前狀態，通過設置auto.leader.rebalance.enabled=true可以使得這個過程自動觸發，默認值爲true。
Broker節點下線通常都是短暫的，這意味着一段時間後會恢復，這就是爲什麼當一個節點離開集羣時，與之關聯的元數據不會被刪除，如果它是一個分區的跟隨者，系統也不會爲此分區重新分配新的跟隨者。
但是需要注意的是，恢復加入的節點不能立即拿回其上次的leader地位，它還沒有資格。
十一、ISR
副本同步隊列ISR(in-sync replicas)，它是由leader維護的，follower從leader同步數據是有延遲的，任意一個超過閾值都會被剔除出ISR列表, 存入OSR(Outof-Sync Replicas)列表中，新加入的follower也會先存放在OSR中。
一個follower想被選舉成leader，它必須在ISR隊列中才有資格,不過，在沒有同步副本存在並且已有leader都下線的邊緣情況下，可以選擇可用性而不是一致性。
ISR列表維護標準如下：
它在過去的X秒內有完整同步leader消息，通過replica.lag.time.max.ms配置約定
它在過去的X秒內向Zookeeper發送了一個心跳，通過zookeeper.session.timeout.ms配置約定
十二、生產者acks設置
明顯，存在一系列意外事件會導致leader下線，假如leader節點接收到生產者的消息，在存儲並且響應ack後節點崩潰了,此時Kafka會從ISR列表中選舉一個新的leader,但是由於生產者ack配置默認爲1,意思是隻考慮leader接收情況不考慮follower同步情況，最終導致部分消息丟失了，所以我們應該在生產者端設置acks=all，要求每條數據必須是寫入所有副本之後，才能認爲是寫成功，另外一層意思是起碼有一個leader和一個follower。不過這種設置影響集羣性能，降低了吞吐量，使得生產者需要在發送下一批消息之前等待更多時間。
十三、水位
通過ack=all約定了leader節點在消息沒有同步到所有的ISR列表前不會有任何返回，另外，節點會跟蹤所有同步副本具有的最大偏移量，也就是高水位偏移量HW(high watermark offset)，consumer無法消費分區下leader副本中偏移量大於分區HW的任何消息。當某個副本成爲leader副本時、broker出現崩潰導致副本被踢出ISR時、producer向leader寫入消息後、leader處理follower fetch請求時，都會嘗試更新分區HW，從而保證了數據一致性和正常消費時不會出現讀取到舊值。
十四、腦裂
想象一下，當正常存活的controller控制器由於長時間GC-STW導致不可用，然後Zookeeper會認爲/controller節點(節點3)已經過期隨即刪除併發送通知到其他broker節點，其他每個broker節點都嘗試升級爲控制器節點，假設節點2從競爭中勝出成功新的控制器節點並在ZK中創建/controller節點。
然後其他節點接收到通知，瞭解到節點2成爲了新的控制器節點，除了還在GC暫停的節點3，或者通知壓根沒到達的節點3，也就是說節點3不知道leadership已經發生了變化，它還以爲自己是控制器節點。此時，同時存在兩個控制器，並行發出可能存在衝突的命令，導致嚴重的後果。
幸運的是，Kafka提供了epoch number的方式可以輕鬆區分出真實的控制器，它是自增長的序列號，信息存儲在ZooKeeper中，顯然序列號最大的那個節點纔是真實的。
十五、什麼時候應該使用Kafka
從上面幾點可知，Kafka可以成爲事件驅動架構的中心部分，使你可以真正將應用程序彼此分離。
</div>
<div id="pages" class="text-c"></div>
<div class="Article-Tool">
<div class="bshare-custom"><div class="bsPromo bsPromo2"></div><a title="分享到：" href="http://www.bShare.cn/" id="bshare-shareto" class="bshare-more">分享到：</a><a title="分享到QQ空間" class="bshare-qzone"></a><a title="分享到新浪微博" class="bshare-sinaminiblog"></a><a title="分享到人人網" class="bshare-renren"></a><a title="分享到騰訊微博" class="bshare-qqmb"></a><a title="分享到網易微博" class="bshare-neteasemb"></a><a title="更多平臺" class="bshare-more bshare-more-icon more-style-addthis"></a><span class="BSHARE_COUNT bshare-share-count" style="float: none;">0</span><span id="favorite"><a href="javascript:;" onclick="add_favorite('十五個點，理解Apache Kafka');" class="t6">收藏</a></span></div><script type="text/javascript" charset="utf-8" src="http://static.bshare.cn/b/buttonLite.js#style=-1&uuid=&pophcol=2&lang=zh"></script><script type="text/javascript" charset="utf-8" src="http://static.bshare.cn/b/bshareC0.js"></script>
</div>
<div class="bk40 hr2"></div>
<p class="hot-search">
<span>相關熱詞搜索：</span><a href="http://www.raincent.com/index.php?m=content&c=tag&a=lists&tag=Kafka" class="blue mr10" target="_blank">Kafka</a><a href="http://www.raincent.com/index.php?m=content&c=tag&a=lists&tag=" class="blue mr10" target="_blank"></a> </p>
<div class="bk15"></div>
<p class="pre-next clear">
<span class="lf">上一篇：</span><a href="http://www.raincent.com/content-85-13581-1.html" class="lf">三行Python代碼，可以讓你的數據處理快別人4倍</a>
<a class="rt" href="http://www.raincent.com/content-85-13740-1.html">用Python操作Word文檔</a><span class="rt">下一篇：</span>
</p>
<div class="bk40 hr2"></div>
<script type="text/javascript" src="http://www.raincent.com/index.php?m=mood&c=index&a=init&id=85-13702-1"></script><style type="text/css"> #mood{text-align: center;}#mood ul li,#mood ul li div.pillar{display:inline-block;display:-moz-inline-stack;zoom:1;*display:inline;}#mood ul li{vertical-align: bottom}#mood ul li{width:80px; padding-bottom:10px}#mood ul li span{ font-size:12px}#mood ul li label{ display:block;}#mood ul li div.pillar{ height:20px; width:80px; background:url(http://www.raincent.com/statics/images/mood/mood.gif) repeat-y 28px center; margin-bottom:5px;}#mood ul li div.pass{background-position: -83px center;}</style><div id="mood"><ul></ul></div><script type="text/javascript">function vote(id) {$.getJSON('http://www.raincent.com/index.php?m=mood&c=index&a=post&id=85-13702-1&k='+id+'&'+Math.random()+'&callback=?', function(data){if(data.status==1){$('#mood').html(data.data);}else {alert(data.data);}})}</script> </div>
<h1><strong>十五個點，理解Apache Kafka</strong><span>2019-07-16 14:57:17 | 編輯：hely | 查看：<i id="hits">1429</i> | 評論：<a href="#comment_iframe" id="comment">0</a></span></h1>
<div class="summary"><strong></strong>Kafka在世界享有盛名，大部分互聯網公司都在使用它，那麼它到底是什麼呢?讓我們一步一步地來理解他，隨後深入探討其工作原理。</div> <div class="bk20"></div>
<div class="content">
<p>Kafka在世界享有盛名，大部分互聯網公司都在使用它，那麼它到底是什麼呢?讓我們一步一步地來理解他，隨後深入探討其工作原理。</p>
作者：Androidrobot
一、介紹
Kafka在世界享有盛名，大部分互聯網公司都在使用它，那麼它到底是什麼呢?
Kafka由LinkedIn公司於2011年推出，自那時起功能逐步迭代，目前演變成一個完整的平臺級產品，它允許您冗餘地存儲巨大的數據量，擁有一個具有巨大吞吐量(數百萬/秒)的消息總線，並且支持實時流任務處理。總的來說，Kafka是一個分佈式，可水平擴展，容錯的日誌提交系統
這些描述都非常抽象，讓我們一個接一個地理解它們的意思，隨後深入探討其工作原理。
二、分佈式
分佈式系統意味着不同機器上的服務實例一起工作成一個整體爲用戶提供完整的服務，Kafka的分佈式體現在存儲、接收信息、發送信息在不同的節點上，它帶來的好處是可擴展性和容錯性。
三、水平可擴展
我們先給垂直可擴展下一個定義，比如說，你的傳統數據庫服務開始變得超負載，可以通過簡單地擴充該服務器資源(CPURAMSSD)緩存這個問題，這就叫垂直擴展-單點增加資源，不過有兩大致命的缺點：底層硬件資源有限、需要停機操作。反之，水平擴展通過增加更多的機器部署服務解決類似問題。
四、容錯
分佈式系統被設計成可容許一定程序的錯誤，不像單點部署發生異常時整體服務都將不可用，有五個節點的Kafka實例，即使有2個節點宕機了仍能繼續工作。
五、commit日誌
一個commit日記類似預寫式日記(WAL)和事務日記，它是可追加的有序的持久化數據，無法進行修改或者刪除。
這種結構是Kafka的核心，它具備排序功能，而排序則可以保證確定性的處理，這兩者都是分佈式系統中的重要問題。
Kafka通常會將消息持久化到磁盤上，它充分利用磁盤的有序讀取特性，讀寫的時間複雜度都爲O(1),這是相當了不起的，另外讀取和寫入操作不會相互影響，寫入不會加鎖阻塞讀取操作。
六、如何工作的
生產者發到消息至Kafka Node節點，存儲在主題Topic中，消費者訂閱主題以接收消息，這是一個生產訂閱模式。爲了使一個節點Topic的數據量不至過大，Kafka引入分區的概念，從而具備更好的性能和伸縮性。Kafka保證分區內的所有消息都按照到達順序排序，區分消息的方式是通過其偏移量offset，你可以將其理解爲普通數組的下標索引。
Kafka中Broker服務節點是愚蠢的，消費者是聰明的，Kafka不會記錄消費者讀取的操作和刪除消息，相反，數據被存儲一段時間或者達到一定的大小閾值，消費者可以自由調整偏移量offset以重複獲取他們想要的消息或者捨棄。
值得注意的是爲了避免進程兩次讀取相同的消息，Kafka引入了消費者組的概念，其中包含一個或者多個消息者實例，約定每個組只能同時有一個實例消費分區的消息。不過這引來了一個麻煩，連社區也無力解決，也就是Kafka中的重平衡Rebalance問題,它本質是一種協議，規定一個消費者組下的所有消費者實例如何達成一致，來分配訂閱主題的每個分區，當組成員數發生變更、訂閱主題數發生變更、訂閱主題的分區數發生變更時都會觸發Rebalance，從而達到最公平的分配策略，不過他和GC的STW類似，在Rebalance期間，所有的消費者實例都會停止消費，然後重新分配連接。我們應該儘量避免這種情況的發生，儘量讓消費實例數等於分區數。
七、持久化至磁盤
正如前面提及的，Kafk將消息存儲至磁盤而不是內存RAM，你或許會驚訝它是如何做出這種選擇的，背後應該有許多優化使其可行，沒錯，事實上優化點包括：
Kafka的通信協議支持消息合併，減少網絡流量傳輸，Broker節點一次持續存儲大量數據，消費者可以一次獲取大量的消息
操作系統通過提前讀入(read-ahead)和write-behind緩存技術，使得磁盤上的線性讀寫速度快，現代磁盤速度慢的結論是基於需要磁盤搜索的場景
現代操作系統引入頁面緩存(Page cache)技術，頁緩衝由多個磁盤塊構造，在linux讀寫文件時，它用於緩存文件的邏輯內容，從而加塊對磁盤映射和數據的訪問
Kafka存儲消息使用的是不可變的標準二進制格式，可以充分利用零拷貝技術(zero-copy),將數據從頁緩存直接複製到socket通道中
八、數據分佈式和複製
我們來談談Kafka如何實現容錯以及如何在節點間分配數據。
Kafka將分區數據拷貝複製到多個Brokers節點上，避免某個Broker死亡導致數據不可達。每時每刻，一個Broker節點”擁有”一個分區，並且是應用程序從該分區讀取寫入的節點，這稱爲分區leader，它將收到的數據複製到其他N個Broker節點上，它們稱爲follower,並準備好在leader節點死亡時被選舉爲leader。這種模式使得消息不易丟失，你可以根據消息的重要程序合理調整replication factor參數，下圖是4個Broker節點，擁有3個複製副本的示例：
你或許會有疑問，生產者或者消費者是如何正確得知分區的leader是哪個節點的?事實上，Kafka將這些信息保存到Zookeeper服務中。
九、Zookeeper服務
Zookeeper是一個分佈式KV對目錄存儲系統，特點是可靠性高、讀取性能高，但是寫入性能差，常被用於存儲元數據和保存集羣狀態，包括心跳、配置等等。
Kafka將以下消息保存至Zookeeper中：
消費者組的每個分區的偏移量，不過後來Kafka將其保存至內部主題__consumer_offsets中
訪問權限列表
生產者和消費者速率限定額度
分區leader信息和它們的健康狀態
十、Controller控制器
一個分佈式系統肯定是可協調的，當事件發生時，節點必須以某種方式做出反應，控制器負責決定集羣如何做出反應並指示節點做某事，它是功能不能過於複雜的Broker節點，最主要的職責是負責節點下線和重新加入時重平衡和分配新的分區leader。
控制器從ZooKeeper Watch事件中可以得知某個Broker節點實例下線(或者節點過期，一般發生於Broker長時間繁忙導致心跳異常)的情況，然後做出反應，決定哪些節點應成爲受影響分區的新leader，然後通知每個相關的follower通過leaderAndlsr請求開始從新的leader複製數據。
從上面可以得知，原本作爲分區leader的Broker節點實例重啓後，它將不再擔任任何分區的leader，消費者也不會從這個節點上讀取消息，這導致了資源的浪費，幸運的是，Kafka有一個被稱爲優先副本(preferred leader replica)的概念-你可以理解成原先爲該分區leader節點(通過broker id區分)的副本,如果該副本可用，Kafka會將集羣恢復成之前狀態，通過設置auto.leader.rebalance.enabled=true可以使得這個過程自動觸發，默認值爲true。
Broker節點下線通常都是短暫的，這意味着一段時間後會恢復，這就是爲什麼當一個節點離開集羣時，與之關聯的元數據不會被刪除，如果它是一個分區的跟隨者，系統也不會爲此分區重新分配新的跟隨者。
但是需要注意的是，恢復加入的節點不能立即拿回其上次的leader地位，它還沒有資格。
十一、ISR
副本同步隊列ISR(in-sync replicas)，它是由leader維護的，follower從leader同步數據是有延遲的，任意一個超過閾值都會被剔除出ISR列表, 存入OSR(Outof-Sync Replicas)列表中，新加入的follower也會先存放在OSR中。
一個follower想被選舉成leader，它必須在ISR隊列中才有資格,不過，在沒有同步副本存在並且已有leader都下線的邊緣情況下，可以選擇可用性而不是一致性。
ISR列表維護標準如下：
它在過去的X秒內有完整同步leader消息，通過replica.lag.time.max.ms配置約定
它在過去的X秒內向Zookeeper發送了一個心跳，通過zookeeper.session.timeout.ms配置約定
十二、生產者acks設置
明顯，存在一系列意外事件會導致leader下線，假如leader節點接收到生產者的消息，在存儲並且響應ack後節點崩潰了,此時Kafka會從ISR列表中選舉一個新的leader,但是由於生產者ack配置默認爲1,意思是隻考慮leader接收情況不考慮follower同步情況，最終導致部分消息丟失了，所以我們應該在生產者端設置acks=all，要求每條數據必須是寫入所有副本之後，才能認爲是寫成功，另外一層意思是起碼有一個leader和一個follower。不過這種設置影響集羣性能，降低了吞吐量，使得生產者需要在發送下一批消息之前等待更多時間。
十三、水位
通過ack=all約定了leader節點在消息沒有同步到所有的ISR列表前不會有任何返回，另外，節點會跟蹤所有同步副本具有的最大偏移量，也就是高水位偏移量HW(high watermark offset)，consumer無法消費分區下leader副本中偏移量大於分區HW的任何消息。當某個副本成爲leader副本時、broker出現崩潰導致副本被踢出ISR時、producer向leader寫入消息後、leader處理follower fetch請求時，都會嘗試更新分區HW，從而保證了數據一致性和正常消費時不會出現讀取到舊值。
十四、腦裂
想象一下，當正常存活的controller控制器由於長時間GC-STW導致不可用，然後Zookeeper會認爲/controller節點(節點3)已經過期隨即刪除併發送通知到其他broker節點，其他每個broker節點都嘗試升級爲控制器節點，假設節點2從競爭中勝出成功新的控制器節點並在ZK中創建/controller節點。
然後其他節點接收到通知，瞭解到節點2成爲了新的控制器節點，除了還在GC暫停的節點3，或者通知壓根沒到達的節點3，也就是說節點3不知道leadership已經發生了變化，它還以爲自己是控制器節點。此時，同時存在兩個控制器，並行發出可能存在衝突的命令，導致嚴重的後果。
幸運的是，Kafka提供了epoch number的方式可以輕鬆區分出真實的控制器，它是自增長的序列號，信息存儲在ZooKeeper中，顯然序列號最大的那個節點纔是真實的。
十五、什麼時候應該使用Kafka
從上面幾點可知，Kafka可以成爲事件驅動架構的中心部分，使你可以真正將應用程序彼此分離。