1. JMS是什麼

1.1. JMS的基礎

       JMS是什麼：JMS是Java提供的一套技術規範

　　JMS乾什麼用：用來異構系統 集成通信，緩解系統瓶頸，提高系統的伸縮性增強系統用戶體驗，使得系統模塊化和組件化變得可行並更加靈活

　　通過什麼方式：生產消費者模式（生產者、伺服器、消費者）

1.2. JMS消息傳輸模型

• 點對點模式（一對一，消費者主動拉取數據，消息收到後消息清除）

　　點對點模型通常是一個基於拉取或者輪詢的消息傳送模型，這種模型從隊列中請求信息，而不是將消息推送到客戶端。這個模型的特點是發送到隊列的消息被一個且只有一個接收者接收處理，即使有多個消息監聽者也是如此。

• 發佈/訂閱模式（一對多，數據生產後，推送給所有訂閱者）

　　發佈訂閱模型則是一個基於推送的消息傳送模型。發佈訂閱模型可以有多種不同的訂閱者，臨時訂閱者只在主動監聽主題時才接收消息，而持久訂閱者則監聽主題的所有消息，即時當前訂閱者不可用，處於離線狀態。

　　queue.put（object）  數據生產

　　queue.take(object)    數據消費

1.3. JMS核心組件

• Destination：消息發送的目的地，也就是前面說的Queue和Topic。
• Message ：從字面上就可以看出是被髮送的消息。
• Producer：消息的生產者，要發送一個消息，必須通過這個生產者來發送。
• MessageConsumer： 與生產者相對應，這是消息的消費者或接收者，通過它來接收一個消息。

　　　　　　　　通過與ConnectionFactory可以獲得一個connection

　　　　　　　　　　通過connection可以獲得一個session會話。

2. Kafka是什麼

• Apache Kafka是一個開源消息系統，由Scala寫成。是由Apache軟體基金會開發的一個開源消息系統項目。
• Kafka最初是由LinkedIn開發，並於2011年初開源。2012年10月從Apache Incubator畢業。該項目的目標是為處理實時數據提供一個統一、高通量、低等待的平臺。
• Kafka是一個分散式消息隊列：生產者、消費者的功能。它提供了類似於JMS的特性，但是在設計實現上完全不同，此外它並不是JMS規範的實現。
• Kafka對消息保存時根據Topic進行歸類，發送消息者稱為Producer,消息接受者稱為Consumer,此外kafka集群有多個kafka實例組成，每個實例(server)成為broker。
• 無論是kafka集群，還是producer和consumer都依賴於zookeeper集群保存一些meta信息，來保證系統可用性

3. Kafka的架構

4. kafka名詞解釋

• Topic：用於劃分Message的邏輯概念，一個Topic可以分佈在多個Broker上。可以理解為一個隊列。
• Partition：是Kafka中橫向擴展和一切並行化的基礎，每個Topic都至少被切分為1個Partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。kafka只保證按一個partition中的順序將消息發給consumer，不保證一個topic的整體（多個partition間）的順序。
• Offset：消息在Partition中的編號，編號順序不跨Partition。kafka的存儲文件都是按照offset.kafka來命名，用offset做名字的好處是方便查找。例如你想找位於2049的位置，只要找到2048.kafka的文件即可。當然the first offset就是00000000000.kafka
• Producer：用於往Broker中發送/生產Message。
• Consumer：用於從Broker中取出/消費Message。
• Replication：Kafka支持以Partition為單位對Message進行冗餘備份，每個Partition都可以配置至少1個Replication(當僅1個Replication時即僅該Partition本身)。
• Leader：每個Replication集合中的Partition都會選出一個唯一的Leader，所有的讀寫請求都由Leader處理。其他Replicas從Leader處把數據更新同步到本地，過程類似大家熟悉的MySQL中的Binlog同步。
• Broker：Kafka中使用Broker來接受Producer和Consumer的請求，並把Message持久化到本地磁碟。每個Cluster當中會選舉出一個Broker來擔任Controller，負責處理Partition的Leader選舉，協調Partition遷移等工作。
• ISR(In-Sync Replica)：是Replicas的一個子集，表示目前Alive且與Leader能夠“Catch-up”的Replicas集合。由於讀寫都是首先落到Leader上，所以一般來說通過同步機制從Leader上拉取數據的Replica都會和Leader有一些延遲(包括了延遲時間和延遲條數兩個維度)，任意一個超過閾值都會把該Replica踢出ISR。每個Partition都有它自己獨立的ISR。
• Consumer Group （CG）：這是kafka用來實現一個topic消息的廣播（發給所有的consumer）和單播（發給任意一個consumer）的手段。一個topic可以有多個CG。topic的消息會複製（不是真的複製，是概念上的）到所有的CG，但每個partion只會把消息發給該CG中的一個consumer。如果需要實現廣播，只要每個consumer有一個獨立的CG就可以了；要實現單播只要所有的consumer在同一個CG。用CG還可以將consumer進行自由的分組而不需要多次發送消息到不同的topic。
• Zookeeper：集群依賴，保存meta信息。

5. Consumer與topic關係

　　本質上kafka只支持Topic

• 每個group中可以有多個consumer，每個consumer屬於一個consumer group；

　　通常情況下，一個group中會包含多個consumer，這樣不僅可以提高topic中消息的併發消費能力，而且還能提高"故障容錯"性，如果group中的某個consumer失效那麼其消費的partitions將會有其他consumer自動接管。

• 對於Topic中的一條特定的消息，只會被訂閱此Topic的每個group中的其中一個consumer消費，此消息不會發送給一個group的多個consumer；

　　那麼一個group中所有的consumer將會交錯的消費整個Topic，每個group中consumer消息消費互相獨立，我們可以認為一個group是一個"訂閱"者。

• 在kafka中,一個partition中的消息只會被group中的一個consumer消費(同一時刻)；

　　一個Topic中的每個partions，只會被一個"訂閱者"中的一個consumer消費，不過一個consumer可以同時消費多個partitions中的消息。

• kafka的設計原理決定,對於一個topic，同一個group中不能有多於partitions個數的consumer同時消費，否則將意味著某些consumer將無法得到消息。

　　kafka只能保證一個partition中的消息被某個consumer消費時是順序的；事實上，從Topic角度來說,當有多個partitions時,消息仍不是全局有序的。

6. Kafka消息的分發

       Producer客戶端負責消息的分發

• kafka集群中的任何一個broker都可以向producer提供metadata信息,這些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息；
• 當producer獲取到metadata信息之後, producer將會和Topic下所有partition leader保持socket連接；
• 消息由producer直接通過socket發送到broker，中間不會經過任何"路由層"，事實上，消息被路由到哪個partition上由producer客戶端決定；

　　比如可以採用"random""key-hash""輪詢"等,如果一個topic中有多個partitions,那麼在producer端實現"消息均衡分發"是必要的。

• 在producer端的配置文件中,開發者可以指定partition路由的方式。

Producer消息發送的應答機制

　　設置發送數據是否需要服務端的反饋,有三個值0,1,-1

　　　　0: producer不會等待broker發送ack

　　　　1: 當leader接收到消息之後發送ack

　　　　-1: 當所有的follower都同步消息成功後發送ack

       request.required.acks=0

7. kafka文件存儲機制

7.1. Kafka文件存儲基本結構

• 在Kafka文件存儲中，同一個topic下有多個不同partition，每個partition為一個目錄，partiton命名規則為topic名稱+有序序號，第一個partiton序號從0開始，序號最大值為partitions數量減1。
• 每個partion(目錄)相當於一個巨型文件被平均分配到多個大小相等segment(段)數據文件中。但每個段segment file消息數量不一定相等，這種特性方便old segment file快速被刪除。預設保留7天的數據。

• 每個partiton只需要支持順序讀寫就行了，segment文件生命周期由服務端配置參數決定。（什麼時候創建，什麼時候刪除）

　　數據有序的討論？

      　　 一個partition的數據是否是有序的？ 間隔性有序，不連續

      　　 針對一個topic裡面的數據，只能做到partition內部有序，不能做到全局有序。

      　　 特別加入消費者的場景後，如何保證消費者消費的數據全局有序的？偽命題。

　　只有一種情況下才能保證全局有序？就是只有一個partition。

7.2. Kafka Partition Segment

• Segment file組成：由2大部分組成，分別為index file和data file，此2個文件一一對應，成對出現，尾碼".index"和“.log”分別表示為segment索引文件、數據文件。

• Segment文件命名規則：partion全局的第一個segment從0開始，後續每個segment文件名為上一個segment文件最後一條消息的offset值。數值最大為64位long大小，19位數字字元長度，沒有數字用0填充。
• 索引文件存儲大量元數據，數據文件存儲大量消息，索引文件中元數據指向對應數據文件中message的物理偏移地址。

    　　　　　　　　 3，497：當前log文件中的第幾條信息，存放在磁碟上的那個地方

       說明：其中以索引文件中元數據3,497為例，依次在數據文件中表示第3個message(在全局partiton表示第368772個message)、以及該消息的物理偏移地址為497。

7.3. Kafka 查找message

       讀取offset=368776【全局offset】的message，需要通過下麵2個步驟查找。

7.3.1. 查找segment file

　　00000000000000000000.index表示最開始的文件，起始偏移量(offset)為0

　　00000000000000368769.index的消息量起始偏移量為368770 = 368769 + 1

　　00000000000000737337.index的起始偏移量為737338=737337 + 1

　　其他後續文件依次類推。

　　以起始偏移量命名併排序這些文件，只要根據offset **二分查找**文件列表，就可以快速定位到具體文件。當offset=368776時定位到00000000000000368769.index和對應log文件。

7.3.2. 通過segment file查找message

　　當offset=368776時，依次定位到00000000000000368769.index的元數據物理位置和00000000000000368769.log的物理偏移地址

       然後再通過00000000000000368769.log順序查找直到offset=368776為止。