kafka的特點和優勢
一、kafka的特點
高吞吐量：Kafka 每秒可以生產約 25 萬消息（50 MB），每秒處理 55 萬消息（110 MB）
持久化數據存儲：可進行持久化操作。將消息持久化到磁盤，因此可用於批量消費，例如 ETL，以及實時應用程序。通過將數據持久化到硬盤以及replication 防止數據丟失。
分佈式系統易於擴展：所有的 producer、broker 和 consumer 都會有多個，均爲分佈式的。無需停機即可擴展機器。
客戶端狀態維護：消息被處理的狀態是在 consumer 端維護，而不是由 server 端維護。當失敗時能自動平衡。
二、Topics、Producers、Consumers
1.Topics
一個topic是對一組消息的歸納。對每個topic，Kafka 對它的日誌進行了分區（參考圖：kafkaTopics）。
每個分區都由一系列有序的、不可變的消息組成，這些消息被連續的追加到分區中。
分區中的每個消息都有一個連續的序列號叫做offset,用來在分區中唯一的標識這個消息。
在一個可配置的時間段內，Kafka集羣保留所有發佈的消息，不管這些消息有沒有被消費。比如，如果消息的保存策略被設置爲2天，那麼在一個消息被髮布的兩天時間內，它都是可以被消費的。之後它將被丟棄以釋放空間。
Kafka的性能是和數據量無關的常量級的，所以保留太多的數據並不是問題。
每個分區在Kafka集羣的若干服務中都有副本，這樣這些持有副本的服務可以共同處理數據和請求，副本數量是可以配置的。副本使Kafka具備了容錯能力。
每個分區都由一個服務器作爲“leader”，零或若干服務器作爲“followers”,leader負責處理消息的讀和寫，followers則去複製leader.如果leader down了，followers中的一臺則會自動成爲leader。集羣中的每個服務都會同時扮演兩個角色：作爲它所持有的一部分分區的leader，同時作爲其他分區的followers，這樣集羣就會據有較好的負載均衡。
將日誌分區可以達到以下目的：首先這使得每個日誌的數量不會太大，可以在單個服務上保存。另外每個分區可以單獨發佈和消費，爲併發操作topic提供了一種可能。
分區是負載均衡失敗恢復分佈式數據存儲的基本單元。
2.Producers
Producer將消息發佈到它指定的topic中,並負責決定發佈到哪個分區。通常簡單的由負載均衡機制隨機選擇分區，但也可以通過特定的分區函數選擇分區。使用的更多的是第二種。
3.Consumers
實際上每個consumer唯一需要維護的數據是消息在日誌中的位置，也就是offset.這個offset由consumer來維護：一般情況下隨着consumer不斷的讀取消息，這offset的值不斷增加，但其實consumer可以以任意的順序讀取消息，比如它可以將offset設置成爲一箇舊的值來重讀之前的消息。
以上特點的結合，使Kafka consumers非常的輕量級：它們可以在不對集羣和其他consumer造成影響的情況下讀取消息。你可以使用命令行來"tail"消息而不會對其他正在消費消息的consumer造成影響。
消費消息通常有兩種模式：隊列模式（queuing）和發佈-訂閱模式(publish-subscribe)。
(1)隊列模式
隊列模式中，多個consumers可以同時從服務端讀取消息，每個消息只被其中一個consumer讀到；
(2)發佈訂閱模式
發佈-訂閱模式中消息被廣播到所有的consumer中。
(3)Consumers可以加入一個consumer group，組內的Consumer是一個競爭的關係，共同競爭一個topic內的消息，topic中的消息將被分發到組中的一個成員中，同一條消息只發往其中的一個消費者。同一組中的consumer可以在不同的程序中，也可以在不同的機器上。而如果有多個Consumer group來消費相同的Topic中的消息，則組和組之間是一個共享數據的狀態，每一個組都可以獲取到這個主題中的所有消息。
如果所有的consumer都在一個組中，這就成爲了傳統的隊列模式，在各consumer中實現負載均衡。
如果所有的consumer都不在不同的組中，這就成爲了發佈-訂閱模式，所有的消息都被分發到所有的consumer中。
更常見的是，每個topic都有若干數量的consumer組來消費，每個組都是一個邏輯上的“訂閱者”，爲了容錯和更好的穩定性，每個組都由若干consumer組成，在組內競爭實現負載均衡。實現了組內競爭負載均衡，組間共享互不影響，這其實就是一個發佈-訂閱模式，只不過訂閱者是個組而不是單個consumer
三、相比傳統的消息系統
傳統的隊列在服務器上保存有序的消息，如果多個consumers同時從這個服務器消費消息，服務器就會以消息存儲的順序向consumer分發消息。雖然服務器按順序發佈消息，但是消息是被異步的分發到各consumer上，所以當消息到達時可能已經失去了原來的順序，這意味着併發消費將導致順序錯亂。爲了避免故障，這樣的消息系統通常使用“專用consumer”的概念，其實就是隻允許一個消費者消費消息，當然這就意味着失去了併發性。
在這方面Kafka做的更好，通過分區的概念，Kafka可以在多個consumer組併發的情況下提供較好的有序性和負載均衡。將每個分區分只分發給一個consumer組，這樣一個分區就只被這個組的一個consumer消費，就可以順序的消費這個分區的消息。因爲有多個分區，依然可以在多個consumer組之間進行負載均衡。注意consumer組的數量不能多於分區的數量，也就是有多少分區就允許多少併發消費。
Kafka只能保證一個分區之內消息的有序性，在不同的分區之間是不可以的，這已經可以滿足大部分應用的需求。如果需要topic中所有消息的有序性，那就只能讓這個topic只有一個分區，當然也就只有一個consumer組消費它。
四、爲什麼大數據環境下的消息隊列常選擇kafka？
分佈式存儲數據，提供了更好的性能 可靠性 可擴展能力
利用磁盤存儲數據，且按照主題、分區來分佈式存放數據，持久化存儲，提供海量數據存儲能力
採用磁盤存儲數據，連續進行讀寫保證性能，性能和磁盤的性能相關和數據量的大小無關
五、爲什麼Kafka 的寫入操作是很快的？
主要得益於它對磁盤的使用方法的不同 雖然Kafka 會持久化所有數據到磁盤，但本質上每次寫入操作其實都只是把數據寫入到操作系統的頁緩存（page cache ）中，然後由操作系統自行決定什麼時候把頁緩存中的數據寫回磁盤上。這樣的設計有 個主要優勢：
1、操作系統頁緩存是在內存中分配的，所以消息寫入的速度非常快。
2、Kafka 不必直接與底層的文件系統打交道。所有煩瑣的 1/0 操作都交由操作系統來處理。
3、Kafka 寫入操作採用追加寫入（ append ）的方式，避免了磁盤隨機寫操作。
Kafka 就是依靠下列4點達到了高吞吐量、低延時的設計目標的。
1、大量使用操作系統頁緩存，內存操作速度快且命中率高。
2、Kafka 不直接參與物理 1/0 操作，而是交由最擅長此事的操作系統來完成。
3、採用追加寫入方式，摒棄了緩慢的磁盤隨機讀／寫操作。
4、使用以 sendfile 爲代表的零拷貝技術加強網絡間的數據傳輸效率。
六、消息持久化
Kafk且是要持久化消息的，而且要把消息持久化到磁盤上。這樣做的好處如下。
解耦消息發送與消息消費：本質上來說， Kafka 最核心的功能就是提供了生產者－消費者模式的完整解決方案。通過將消息持久化使得生產者方不再需要直接和消費者方藕合，它只是簡單地把消息生產出來井交由 Kafka 服務器保存即可，因此提升了整體的吞吐量。
實現靈活的消息處理：很 Kafka 的下游子系統（接收 Kafka 消息的系統）都有這樣的需求一一對於已經處理過的消息可能在未來的某個時間點重新處理 次，即所謂的消息重演（ message replay ）。消息持久化便可以很方便地實現這樣的需求。
另外， Kafka 實現持久化的設計也有新穎之處。普通的系統在實現持久化時可能會先儘量使用內存，當內存資源耗盡時，再 次性地把數據“刷盤”；而 Kafka 則反其道而行之，所有數據都會立即被寫入文件系統的持久化日誌中，之後 Kafka 服務器纔會返回結果給客戶端通知它們消息已被成功寫入。這樣做既實時保存了數據，又減少了 Kafka 程序對於內存的消耗，從而將節省出的內存留給頁緩存使用，更進一步地提升了整體性能。
七、負載均衡和故障轉移
作爲一個功能完備的分佈式系統， Kafka 如果只提供了最基本的消息引擎功能肯定不足以幫助它脫穎而出。一套完整的消息引擎解決方案中必然要提供負載均衡 Cload balancing ）和故障轉移（ fai l-over ）功能。
默認情況下 Kafka 的每臺服務器都有均等的機會爲 Kafka 的客戶提供服務，可以把負載分散到所有集羣中的機器上，避免出現“耗盡某臺服務器”的情況發生。Kafka 默認提供了很智能的 leader 選舉算法，可以在集羣的所有機器上以均等機會分散各個partition的leader ，從而整體上實現了負載均衡。
除了負載均衡，完備的分佈式系統還需要支持故障轉移 所謂故障轉移，是指當服務器意外中止時，整個集羣可以快速地檢測到該失效（ fai lur ），井立即將該服務器上的應用或服務自動轉移到其他服務器上 故障轉移通常是以“心跳”或“會話”的機制來實現的，即只要主服務器與備份服務器之間的心跳無法維持或主服務器註冊到服務中心的會話超時過期了，那麼就認爲主服務器己無法正常運行，集羣會自動啓動某個備份服務器來替代主服務器的工作。
Kafka 服務器支持故障轉移的方式就是使用會話機制 。每臺Kafka 服務器啓動後會以會話的形式把自己註冊到ZooKeeper 服務器上 。一旦該 服務器運轉出現問題，與ZooKeeper 的會話便不能維持從而超時失效，此時 Kafka 集羣
會選舉出另一臺服務器來完全代替這臺服務器繼續提供服務。