簡單的理解一下，副本就是對於分割槽中訊息的備份，是kafka中通過資料的冗餘保證高可用的一種方式，所以副本又是建立在kafka集群模式的基礎上的。
下圖中表示的含義為：集群中有3臺broker，有乙個名為topic的主題，設定了分割槽數為3，副本數量為3。
首領含義稍後解釋。
如果分割槽的數量大於broker數量時，就會變成這樣，其中乙個broker上會存放2個分割槽首領。
如下圖表示的含義為：集群中有2臺broker，乙個名為topic的主題，設定了分割槽數為3，副本數量為2，其中有兩個首領都在broker上。
分割槽中的首領會盡量保持均勻的存放在不同的broker中，以提高訊息的處理能力與kafka的可用性，因為只有首領分割槽才會處理訊息的接收與傳送。
注意，副本的數量不能大於broker數量，否則會報錯。
下面中個例子中我只啟動了2臺broker，卻想建立了3個副本，所以報錯了，提示資訊也很明顯。
當broker數量為3台時，建立成功。
當我們設定一定副本數量時，有且只有乙個副本是首領（leader）副本，其餘的副本都是跟隨者（follower）副本。
生產者傳送的訊息只會由leader副本直接接收到，同樣的，消費者拉取訊息也只會從leader副本中拉取，follower副本只負責不斷的從leader副本中同步資料即可，會盡量的讓自己與leader保持一致，這也是一種冗餘設計，以此來保證高可用性。
分割槽副本中除了首領副本，其餘的都是跟隨者副本，跟隨者副本不會接收與傳送訊息，只負責從首領副本中同步訊息，以保證與首領副本中的訊息一致，在首領副本傳送故障時，通過選舉變為新的首領副本，以此保證可用性與一致性。
isr（in-sync replica），是與分割槽leader保持同步的副本集合，在leader宕機時，一般會優先從isr中選舉乙個作為新的首領，所以follower副本會不斷的從leader副本中拉取並同步訊息，以保證自己在isr集合中。
3臺broker組成集群，broker.id為別為：0、1、2
建立了乙個主題名為：test_repli
分割槽數量：6
分割槽副本數：3
從圖中可以看出，每台broker均勻承擔了2個分割槽的leader，每乙個分割槽都有3個副本，isr副本有的分割槽是全量的，有的分割槽則並沒有滿足條件。
當把borker.id為2的停掉，可以看出原來leader為2的分割槽，一台為0，一台為1了。isr中也沒有了id為2的副本了。
至於為什麼replicas中為什麼還有id為2，那是因為這列資訊不管是否boker是否存活都會顯示。
那麼什麼樣follower可以視為與leader保持同步呢？或者說滿足什麼樣的條件就可以放入isr中？
實際上由於網路抖動，通訊延遲，突然流量等原因，並不一定要follower與leader保持完全一致才可以放入isr。
在0.9.0.0版本之前，有乙個引數replica.lag.max.messages，意為當副本中的追隨者與leader最多相差多少條訊息時，則會被踢出，這個引數在突發流量的場景下很容易造成追隨者被頻繁的踢出，平穩後又被加入isr中。
所以之後的版本中衡量乙個跟隨者是否能存在isr中只有乙個引數replica.lag.time.max.ms，意為最長多少時間不向leader請求資料，則被判定不同步，被踢出isr。
假如isr列表中只有leader自己，其他所有的副本都沒有與leader保持同步，那麼這時候如果leader宕機了，該怎麼辦呢？
等待isr中任意乙個副本出現，選舉為leader
隨便選擇乙個跟隨者，選舉為leader
第一種方案可能會造成等待時間較長，如果isr中所有的副本都無法活過來了，則分割槽會變的永久不可用，側重於資料的可靠性。
第二種方案雖然可能會丟失訊息，但是保證了可用性。
unclean.leader.election.enable引數決定使用哪一種，預設true（在0.11.0.0版本後預設為false）。
為true表示：允許從非isr副本中選擇乙個跟隨者，選舉為leader。
為false表示：必須從isr副本中選擇leader。
關於這個引數到底是設定true還是false，需要結合自己的業務區理解，不過可以看出kafka官方更側重於資料的可靠性。
最小同步副本？
與isr相關的還有乙個引數min.insync.replicas（最小同步副本），只有當isr中的數量大於等於最小同步副本數時，生產者的訊息才會被提交，即生產者才會被告知訊息傳送成功。
注意這個引數必須是生產者設定ack為all時才會生效，如果ack設定為0或者1時，表示的含義明顯與最小同步副本衝突。
關於ack含義的補充：
0:生產者只要把訊息傳送出去即可，不用等待broker的處理結果，吞吐量最高，同樣訊息的丟失率也最高。
1:生成者需要等分割槽leader將訊息寫入成功後 才認為此訊息傳送成功，1是ack的預設配置，兼顧了吞吐量和訊息丟失的問題，但是同樣有訊息丟失的風險，比如當leader寫入成功後突然掛了，其他分割槽跟隨者並為能夠將此訊息同步，則此訊息丟失。
all:生產者會等待所有的副本都寫入成功後才認為此訊息傳送成功，此方法保證了訊息不丟失，但也是吞吐量最低的。
Kafka中關於分割槽的一些理解
分割槽和主題 一般我們會在乙個topic下設定多個分割槽，這樣多個分割槽對應多個消費者，以此可以提高kafka的吞吐量，相當於處理訊息時達到了多執行緒並行執行的效果。分割槽和訊息 當生產者要向某個主題傳送訊息時，生產者會先將訊息序列化處理，然後根據topic，serializedkey，serial...
關於Linux集群的一些資料
嗯，最近打算研究一下這方面的東西，在網上找了找，東西還真不少 linux集群大全 rawn shah 作為專家，在 linux 現有的開放原始碼和封閉原始碼集群解決方案方面為您指點迷津。我比較感興趣的是lvs linux virtual server 這個專案是中國人做的，真是讓人感到自豪。這是lv...
kafka的一些引數
python操作kafka 需求，如果topic不存在，不允許自動建立 每個topic的分割槽個數，更 多的partition會產生更多的segment file num.partitions 2 是否允許自動建立topic 若是false，就需要通過命令建立topic auto.create.to...