Kafka消息topic分區

 

kafka是爲分佈式環境設計的,所以若是日誌文件,其實也能夠理解成消息數據庫,放在同一個地方,那麼必然會帶來可用性的降低,一掛全掛,若是全量拷貝到全部的機器上,那麼數據又存在過多的冗餘,並且因爲每臺機器的磁盤大小是有限的,因此即便有再多的機器,可處理的消息仍是被磁盤所限制,沒法超越當前磁盤大小.所以有了partition的概念.

kafka對消息進行必定的計算,經過hash來進行分區.這樣,就把一份log文件分紅了多份.如上面的分區讀寫日誌圖,分紅多份之後,在單臺broker上,好比快速上手中,若是新建topic的時候,咱們選擇了--replication-factor 1 --partitions 2,那麼在log目錄裏,咱們會看到
test-0目錄和test-1目錄.就是兩個分區了.

你可能會想,這特麼沒啥區別呀.注意,當有了多個broker以後,這個意義就存在了.這裏上一張圖,原文在參考連接裏有

 

這是一個topic包含4個Partition，2 Replication(拷貝),也就是說所有的消息被放在了4個分區存儲,爲了高可用,將4個分區作了2份冗餘,而後根據分配算法.將總共8份數據,分配到broker集羣上.

結果就是每一個broker上存儲的數據比全量數據要少,但每份數據都有冗餘,這樣,一旦一臺機器宕機,並不影響使用.好比圖中的Broker1,宕機了.那麼剩下的三臺broker依然保留了全量的分區數據.因此還能使用,若是再宕機一臺,那麼數據不完整了.固然你能夠設置更多的冗餘,好比設置了冗餘是4,那麼每臺機器就有了0123完整的數據,宕機幾臺都行.須要在存儲佔用和高可用之間作衡量.
至於宕機後,zookeeper會選出新的partition leader.來提供服務.這個等下篇文章

每一個使用者進程都屬於一個使用者小組（consumer group） 。

 

準確地講，每條消息都只會發送給每一個使用者小組中的一個進程。

 

所以，使用者小組使得許多進程或多臺機器在邏輯上做爲一個單個的使用者出現。使用者小組這個概念很是強大，能夠用來支持JMS中隊列（queue）或者話題（topic）這兩種語義。

 

爲了支持隊列語義，咱們能夠將全部的使用者組成一個單個的使用者小組，在這種狀況下，每條消息都會發送給一個單個的使用者。

 

爲了支持話題語義，能夠將每一個使用者分到它本身的使用者小組中，隨後全部的使用者將接收到每一條消息。

 

在咱們的使用當中，一種更常見的狀況是，咱們按照邏輯劃分出多個使用者小組，每一個小組都是有做爲一個邏輯總體的多臺使用者計算機組成的集羣。在大數據的狀況下，Kafka有個額外的優勢，對於一個話題而言，不管有多少使用者訂閱了它，一條條消息都只會存儲一次。