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有個額外的優點，對於一個話題而言，無論有多少使用者訂閱了它，一條條消息都只會存儲一次。