關於kafka

Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料，具有類似JMS的特性，但設計與實現完全不同，也並不是JMS規範實現的，顯式分散式架構設計，producer、broker（kafka）和consumer都可以有多個

訊息的生產及訊息傳遞：Producer，consumer實現Kafka註冊的介面，topic訊息從producer傳送到broker，broker承擔一箇中間快取和分發的作用。broker分發註冊到系統中的consumer。broker的作用類似於快取，即活躍的資料和離線處理系統之間的快取。客戶端和伺服器端的通訊，是基於簡單，高效能，且與程式語言無關的TCP協議

概念解析

JMS：即Java訊息服務（Java Message Service）應用程式介面，是一個Java平臺中關於面向訊息中介軟體（MOM）的API，用於在兩個應用程式之間，或分散式系統中傳送訊息，進行非同步通訊

Topic：特指Kafka處理的訊息源（feeds of messages）的不同分類，topic只是儲存訊息的一個邏輯的概念，他並沒有實際的檔案存在磁碟上，可以認為是某一型別的訊息的集合。所有傳送到kafka上的訊息都一個型別，這個型別就是他的topic。在物理上來說，不同的topic的訊息是分開儲存的。同時，一個topic可以有多個producer和多個consumer

partition：Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的佇列。partition中的每條訊息都會被分配一個有序的id（offset）

Message：訊息，是通訊的基本單位

producers：訊息和資料生產者，向Kafka的一個topic釋出訊息的過程叫做producers

consumers：訊息和資料消費者，訂閱topics並處理其釋出的訊息的過程叫做consumers

Broker：快取代理，Kafa叢集中的一臺或多臺伺服器統稱為broker

訊息佇列的兩種模式

點對點模式：生產者將訊息傳送訊息佇列中，消費者獲取佇列訊息消費，queue不再儲存被消費的訊息，所以消費者不可能消費到已經被消費的訊息。Queue支援存在多個消費者，但是對一個訊息而言，只能被一個消費者消費

釋出/訂閱模式：生產者將訊息釋出到topic中，同時可以有多個消費者訂閱該訊息。和點對點方式不同，釋出到topic的訊息會被所有訂閱者消費

釋出與訂閱的實現

1、kafka訊息生產過程

① 生產者與叢集建立連線：通過本地broker叢集配置，與叢集建立連線，會獲取一個叢集對映關係，從對映關係中選擇一個最終的broker地址建立連線，此刻會獲取到叢集的所有topic集合，判斷當前topic是否在集合中，並從topic所對應的partitio中隨機選擇一個分割槽作為leader，建立連線。

② 生產topic訊息：topic訊息一次可以生產多組，生產者在推送叢集前，會進行訊息轉化，內部會在判斷叢集中是否存在相應topic，並組裝成叢集可識別的訊息格式

③ 為保證資料不丟失，在生產者端，資料推送分為三種：0-不等叢集回覆即預設成功，1-leader接收成功並回復，all-主從同步成功後回覆

2、叢集處理kafka訊息

一個獨立的kafka伺服器被稱為broker，而kafka的高可用、容災性強的特性要求了kafka是一個叢集制，也就是有多個broker組成。

叢集是由一個基於觀察者模式設計的分散式服務管理框架zookeeper管理的，它負責儲存和管理大家都關心的資料，topic、consumers、producers、brokers要接受觀察者的註冊，一旦這些資料的狀態發生變化，ZooKeeper就將負責通知已經在。ZooKeeper上註冊的那些觀察者做出相應的反應，從而實現叢集中類似Master/Slave管理模式

broker接收來自生產者的訊息，為訊息設定偏移量，並提交訊息到磁碟儲存。broker為消費者提供服務，對讀取分割槽的請求作出相應，返回已經提交到磁碟上的訊息

Broker處理請求：broker會在它所監聽的每個埠上執行一個Acceptor執行緒，這個執行緒會建立一個連線並把它交給Processor執行緒去處理。Processor執行緒（也叫網路執行緒）的數量是可配的，Processor執行緒負責從客戶端獲取請求資訊，把它們放進請求佇列，然後從響應佇列獲取響應資訊，併發送給客戶端

3、kafka消費

同樣的，消費端會與叢集建立連線，獲取broker的leader分割槽，拉取訊息。真實的應用中一般都回去有多個分割槽，在有效對broker上面的資料進行分片減少io效能問題的同時提高了消費能力，可以有多個consumer進行資料消費。

在多個consumer和partition消費策略時，會有group分組。組內的所有consumer均可以訂閱這個topic下的所有的訊息。

consumer與partition：一般partition是consumer的整數倍。消費者數量多於partition的數量的時候，會有消費者消費不到資料的情況。消費者數量少於partition的數量的時候，會有消費者消費多個partition

consumer的rebalance機制

該機制規定了同一個group下的consumer如何達成一致來消費訂閱各個分割槽的訊息，具體的策略是範圍策略，或者輪詢策略

1、觸發時機

① 同一個consumer group內新增了消費者

② 消費者離開當前所屬的consumer group，比如主動停機或者宕機

③ topic新增或者減少了分割槽

2、rebalance管理

① 首先我們會確定的一個coordinate角色，當啟動第一個consumer的時候我們就會確定為coordinate，之後所有的consumer都會與這個coordinate保持通訊。而我們的coordinate就是對consumer group進行管理

② 確定coordinate：消費者向kafka叢集中的任意一個broker傳送一個GroupCoordinatorRequest請求，服務端會返回一個負載最小的broker節點的id，並將該broker設定為coordinator

③ 進行第一階段joinGroup（選舉leader）的過程：所有的消費者都會向consumer傳送joinGroup的請求，當所有的consumer都發送了請求之後，我們的coordinate就會在選舉出一個consumer來作為leader，而且會把訂閱訊息，組成員資訊反饋回去

④ 進行第二階段同步leader的分割槽分配方案，簡單來說就是leader把分割槽分配方案發送給coordinate，然後，coordinate再把這個分割槽傳送給各個consumer

Leader選舉的相關範圍

AR：分割槽中的所有副本統稱為AR (Assigned Replicas）

ISR：所有與leader 副本保持一定程度同步的副本（包括leader 副本在內〕組成ISR （On-Sync Replicas），leader會從改組織中選取第一個

OSR：與leader 副本同步滯後過多的副本（不包括leader 副本）組成OSR (Out-of-Sync Replicas）

Mq保證分散式事務訊息最終一致性

最終一致性的分散式事務，就是說它保證的是訊息最終一致性，而不是像2PC、3PC、TCC那樣強一致分散式事務

兩點：生產者要保證100%的訊息投遞，消費者這一端需要保證冪等消費（唯一ID+業務自己實現的冪等）

RocketMQ分散式事務流程：

名詞解釋：

① 半事務訊息：

是指暫不能被Consumer消費的訊息。Producer 已經把訊息成功傳送到了 Broker 端，但此訊息被標記為暫不能投遞狀態，處於該種狀態下的訊息稱為半訊息。需要 Producer對訊息的二次確認後，Consumer才能去消費它。

② 訊息回查

由於網路閃段，生產者應用重啟等原因。導致 Producer 端一直沒有對 Half Message(半訊息) 進行 二次確認。這是Brock伺服器會定時掃描長期處於半訊息的訊息，會主動詢問 Producer端 該訊息的最終狀態(Commit或者Rollback),該訊息即為 訊息回查

① 使用者端後臺傳送一條更新商戶B餘額的半事務訊息至MQ服務端

② MQ服務端收到則會返回Success至使用者端

③ 使用者端收到Success,則會去執行更新使用者端餘額的事務

④ 執行結束後會根據本地事務執行結果返回狀態Commint或rollback給MQ伺服器端（如果MQ端長時間沒有接收到使用者端事務狀態，則會去呼叫使用者端檢查服務，判斷當前使用者端事務是否成功）

⑤ MQ端接受Commit則將該訊息修改成可投遞狀態，商戶端會去消費，並且去執行對應的修改餘額的事務。如果是RollBack則不投遞訊息，儲存三天後刪除

參考最終一致性解決方案：http://www.javashuo.com/article/p-xbgjaohm-y.html