主題、磁區與副本

基本概念

主題、磁區和副本的關系

主題是一個邏輯概念，代表了一類訊息，實際作業中我們使用主題來區分業務，而主題之下并不是訊息，而是磁區，磁區是一個物理概念，它是磁盤上的一個目錄，目錄中是保存訊息的日志段檔案，磁區的目的是為了提高吞吐量，實作主題的負載均衡，一個主題至少有一個磁區；而故障轉移這個功能就放在了副本上，一個磁區至少有一個副本，一個磁區的所有副本原則上其資料是一致的且分布在不同的broker上，這樣其中某一個broker故障那么其他的broker可以繼續提供針對該磁區的資料讀寫，

主題的名稱是用戶自己設定，磁區名稱是主題名稱-磁區編號，其中磁區編號從0開始而且用戶不可能自己設定，副本數量由用戶設定，前面說過磁區是存放訊息的物理檔案，那么訊息也會被分配一個序列號，該序列號從0開始單調遞增，

副本的型別

上面我們知道副本的作用是防止資料丟失，那么當有多個副本的時候這些副本都提供服務么？在Kafka的機制里副本并不都對外提供服務，它分為兩類：Leader和Follower，前者對外提供讀寫服務后者只被動的從Leader副本同步資料，所以通過這里我們就可以回答一個問題就是3臺Kafka集群，所有服務器都是活躍的不存在主從之分，服務器是否對外提供讀寫服務完全取決于所持有的副本型別，如果是Leader則提供，如果是Follower則不提供，

Kafka會盡量保證所有副本不在同一臺機器上，但是如果副本數量大于集群機器數量那么就無法保證了，

上面這個主題就是3個磁區，每個磁區有3個副本，橫向來看就是

Partition：0 這個磁區當前的Leader副本在Broker.id為0的機器上

Replicas：1,0,2 表示副本有3個，以及這些副本都在哪些broker上

Isr：1,0,2 表示該集合中的所有副本的資料都與Leader副本保持同步狀態，意味著只要Isr中存在一個活著的副本那么生產者已提交的資料就不會丟失，如果Isr中的某些副本落后Leader副本那么該落后的副本就會被移出，

副本與ISR

我們知道副本就是備份，Kafka會盡量把磁區的副本均衡的放在不同broker上，并從中挑選一個作為Leader副本來對外提供讀寫服務，那么其他的就是Follower副本，而這些Follower副本保持與Leader副本的資料同步，

為什么Kafka只能讓Leader副本提供讀寫操作呢？因為這樣可以實作所寫即所得，都是從Leader副本讀寫，所以寫入資料后，消費者就可以馬上讀取；另外就是單調讀，尤其是在副本數量多的時候，不會出現某些副本有這個資料，某些副本沒有，所以這就是只讓Leader副本提供讀寫操作的好處，

假如當前的Leader副本所在主機宕機，那么Kafka集群就要從剩余的Follower副本中重新挑選一個副本作為新的Leader副本，那么顯然不是所有的Follower副本都具有競選資格，如果某些Follower副本資料落后太多那么它們則不能成為Leader副本，所以這就有了ISR的概念，

ISR就是Kafka動態維護的一組同步副本集合，每個主題的磁區都有自己的ISR串列，ISR中的所有副本都與Leader保持同步狀態，而且Leader副本也在ISR串列中，只有在ISR串列中的副本才有這個被選中為Leader，

不過這里有人可能會糊涂，broker的id是從0、1、2，這里的Isr也是0、1、2這三個數字，那么Replicas和Isr中的數字表示的是broker的id呢還是磁區的編號，下面我們修改一下集群中的broker的id，不過這種操作在線上可不建議使用，我們要把log.dirs目錄中的資料洗掉，然后修改組態檔，然后再啟動，

我們這里建立一個新的主題叫做TestBBB

可以看到無論是Replicas還是Isr顯示的都是broker的id，而不是磁區編號，下面我們說一下ISR是怎么同步的呢？

起始位移：表示副本中第一條訊息的位置

高水位標記：表示副本最新一條被提交的訊息的位置，這個值決定了客戶端可以讀取到的訊息最大范圍，超過高水位標記的訊息【5、6】屬于未提交訊息，客戶端讀取不到，

日志末端位移：表示下一條待寫入訊息的位移，也就是說LEO指向的位置是沒有訊息的，當寫入一條訊息LEO會加1.

以上三個位移無論是在Leader副本還是Follower副本都具有，而磁區的HW值就是Leader副本的HW值，并且Leader副本所在的broker上還保存了Follower副本的HW和LEO水位值，

何時更新LEO值

從上圖看到Leader副本所在broker上保存了所有Follower副本的HW和LEO值，同時Follower副本所在broker也保存了自己的HW和LEO，

生產者向Leader副本寫入資料，那么Leader的LEO值就會增加；Follower向Leader拉取資料并寫入自己的日志檔案時Follower的LEO也會增加，

在Leader的broker上保存的Follower副本的LEO值是在Leader收到Follower的拉取資料請求之后和真正發送資料給Follower之前進行更新的，而且來拉取的時候Follower會發送自己的HW值，Leader上保存的Follower副本的LEO值就是Follower拉取資料時發送過來的自己的HW值，

何時更新HW值

Follower收到資料然后就要寫入日志，之后就要更新自己的LEO值，更新完成后再去更新自己的HW值，原則就是Leader發送過來的資料中包含Leader自己的HW，所以Follower在更新完自己的LEO之后嘗試更新自己的HW的時候會比較Leader的HW和自己的LEO哪個最小，它取最小值來設定自己的HW值，

Leader更新自己的HW發生在：

生產者寫入新的訊息，Leader更新了自己的LEO后嘗試更新自己的HW
Leader從日志中讀取了資料并發送給Follower之后嘗試更新自己的HW

上面都是嘗試更新，而不是一定更新，因為更新原則是取Leader副本的LEO和它所保存的所有Follower副本的LEO的最小值為Leader副本的HW值，比如在初始狀態（LEO為0、HW為0，保存的Follower的LEO也為0）下如果寫入一條訊息雖然Leader更新了自己的LEO為1，而此時保存的的Follower的LEO為0，取最小值就是0，所以HW也是0，故不需要更新，

上述機制由于有時間差問題導致Follower需要進行兩輪拉取才能完成HW的更新，所以會出現資料丟失情況，所以在0.11版本中引入了Leader Epoch機制來解決，

如何判定不同步

這里就有一個問題，如何被認定ISR中的副本落后Leader太久呢也就是判斷不同步的標準是什么？0.9版本之前是按照訊息個數來做的，0.9之后是時間，默認是10秒，如果一個Follower副本落后Leader的時間持續超過10秒則該Follower被認為不是同步的，

主題和磁區的日常管理

創建主題

kafka-topics.sh --bootstrap-server 172.16.100.10:9092 --create --topic TestCCC --partitions 3 --replication-factor 3

列出所有主題

kafka-topics.sh --list --bootstrap-server 172.16.100.10:9092

查看主題詳情

kafka-topics.sh --describe --bootstrap-server 172.16.100.10:9092 --topic TestCCC

洗掉主題

kafka-topics.sh --delete --bootstrap-server 172.16.100.10:9092 --topic TestCCC

這只是標記主題為洗掉，因為它是一個異步操作，如果發現某些時候洗掉了主題但是其ZK中的節點包括磁盤資料還都在，你可以手動清理一下：

洗掉ZK中/admin/delete_topics下的需要洗掉的主題名稱

手動洗掉磁盤上的該主題磁區目錄

在ZK中執行 rmr /controller 來觸發Controller的重新選舉，這一步要慎重因為它會造成大規模Leader重新選舉，不過只執行前兩步也行，只是Controller中的快取沒有更新而已，

修改主題的磁區數量

kafka-topics.sh --bootstrap-server 172.16.100.10:9092 --alter --topic TestCCC --partitions 4

只支持增加磁區數量，不支持減少，

說明：這里你可能發現命令中使用的都是 --bootstrap-server而不是之前的--zookeeper引數，因為使用--bootstrap-server是目前操作kafka的標準方式，而且也會經過kafka的安全體系，