03 Apache Kafka支持發布與訂閱(RabbitMQ與Kafka之間的差異)

#8195; 2. 在.index文件中，使用二分查找，找到offset小于或者等于指定offset（這里假設是7）的最大的offset，這里查到的是6，然后獲取到index文件中offset為6指向的Position（物理偏移地址）為258。

   3. 在.log文件中，從磁盤位置258開始順序掃描，直到找到offset為7的Message。

至此，我們就簡單介紹完了Segment的基本組件.index文件和.log文件的存儲和查詢原理。但是我們會發現一個問題：.index文件中的offset并不是按順序連續存儲的，為什么Kafka要將索引文件設計成這種不連續的樣子？這種不連續的索引設計方式稱之為稀疏索引，Kafka中采用了稀疏索引的方式讀取索引，kafka每當.log中寫入了4k大小的數據，就往.index里以追加的寫入一條索引記錄。使用稀疏索引主要有以下原因：

   (1) 索引稀疏存儲，可以大幅降低.index文件占用存儲空間大小。

   (2) 稀疏索引文件較小，可以全部讀取到內存中，可以避免讀取索引的時候進行頻繁的IO磁盤操作，以便通過索引快速地定位到.log文件中的Message。

7. Message

  Message是實際發送和訂閱的信息是實際載體，Procer發送到Kafka集群中的每條消息，都被Kafka包裝成了一個Message對象，之后再存儲在磁盤中，而不是直接存儲的。Message在磁盤中的物理結構如下所示。

  其中 key 和 value 存儲的是實際的Message內容，長度不固定，而其他都是對Message內容的統計和描述，長度固定。因此在查找實際Message過程中，磁盤指針會根據Message的 offset 和 message length 計算移動位數，以加速Message的查找過程。之所以可以這樣加速，因為Kafka的.log文件都是順序寫的，往磁盤上寫數據時，就是追加數據，沒有隨機寫的操作。

8.Partition Replicas

  最后我們簡單聊一下Kafka中的Partition Replicas（分區副本）機制，0.8版本以前的Kafka是沒有副本機制的。創建Topic時，可以為Topic指定分區，也可以指定副本個數。kafka 中的分區副本如下圖所示：

  Kafka通過副本因子（replication-factor）控制消息副本保存在幾個Broker（服務器）上，一般情況下副本數等于Broker的個數，且同一個副本因子不能放在同一個Broker中。副本因子是以分區為單位且區分角色；主副本稱之為Leader（任何時刻只有一個），從副本稱之為 Follower（可以有多個），處于同步狀態的副本叫做in-sync-replicas(ISR)。Leader負責讀寫數據，Follower不負責對外提供數據讀寫，只從Leader同步數據，消費者和生產者都是從leader讀寫數據，不與follower交互，因此Kafka并不是讀寫分離的。同時使用Leader進行讀寫的好處是，降低了數據同步帶來的數據讀取延遲，因為Follower只能從Leader同步完數據之后才能對外提供讀取服務。

  如果一個分區有三個副本因子，就算其中一個掛掉，那么只會剩下的兩個中，選擇一個leader，如下圖所示。但不會在其他的broker中，另啟動一個副本（因為在另一臺啟動的話，必然存在數據拷貝和傳輸，會長時間占用網絡IO，Kafka是一個高吞吐量的消息系統，這個情況不允許發生）。如果指定分區的所有副本都掛了，Consumer如果發送數據到指定分區的話，將寫入不成功。Consumer發送到指定Partition的消息，會首先寫入到Leader Partition中，寫完后還需要把消息寫入到ISR列表里面的其它分區副本中，寫完之后這個消息才能提交offset。

  到這里，差不多把Kafka的架構和基本原理簡單介紹完了。Kafka為了實現高吞吐量和容錯，還引入了很多優秀的設計思路，如零拷貝，高并發網絡設計，順序存儲，以后有時間再說。

很赞哦!（938）