從JMS到KafKa

從JMS到KafKa

JMS

（1）JMS概念

JMS（Java Message Service,java消息服務）API是一個消息服務的標準或者說是規範，容許應用程序組件基於JavaEE平臺建立、發送、接收和讀取消息。它使分佈式通訊耦合度更低，消息服務更加可靠以及異步性。

（2）消息模型

P2P：發送端將消息發送到消息隊列（使用什麼樣的消息隊列最優？），不用管接收端的行爲，接受端只須要去消息隊列中取消息，若是有消息就取出來進行消費，沒有就進行等待。

圖1：P2P模型

Publish-Subscribe：發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須建立一個訂閱者以後，才能消費發佈者的消息，並且爲了消費消息，訂閱者必須保持運行的狀態

圖2：發佈者-訂閱者

 

 

KafKa

（1）   KafKa的概念

Kafka是Linkedin於2010年12月份開源的消息系統，是一個高性能，高可用，可持久化的，爲分佈式設計的消息中間件。

Kafka的集羣算法作的很先進，大大強於ActiveMQ。ActiveMQ只有主從互備的HA，負載均衡作的很差，沒有消息分片。而Kafka在HA，負載均衡和消息分片上作的很完美。

（2）   目標

一、消息數據保存在磁盤，存取代價爲O(1)。通常數據在磁盤上是使用BTree存儲的，存取代價爲O（lgn）

二、高吞吐率。在普通的節點上，單機每秒10W消息讀寫

三、支持分佈式，全部的producer、broker和consumer都會有多個，均爲分佈式的。

四、支持數據並行加載到Hadoop中。

（3）   相關概念

一、Topics/logs  

一個Topic能夠認爲是一類消息，每一個topic將被分紅多個partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset（偏移量），offset爲一個long型數字，它是惟一的標記一條消息。kafka沒有提供索引機制來存儲offset，由於kafka中不對消息進行「隨機讀寫」。

kafka和ActiveMQ不一樣的是：即便消息被消費，消息仍然不會被當即刪除，日誌文件將會根據broker中的配置要求，保留必定的時間以後刪除；好比log文件保留2天，以後無論消息是否被消費，文件都會被刪除。能夠達到減小磁盤IO開支的效果。

二、Partitions   

每一個server（kafka實例）負責partitions中消息的讀寫操做；此外kafka還能夠配置partitions須要備份的個數（replicas），每一個partition將會被備份到多臺機器上，以提升可用性。每一個partition都有一個server爲「leader」；leader負責全部的讀寫操做，若是leader失效，那麼將會有其餘follower來接管（成爲新的leader）；follower只是簡單的跟進與leader，同步消息便可。leader server承載了所有的請求壓力，所以從集羣總體考慮，有多少個partitions就有多少個leader，kafka將leader均衡分散在每一個實例上，確保總體的性能穩定。

三、Producers

將消息發佈到指定的Topic中，同時Producer也能決定將消息歸屬到哪一個partitions，好比基於「round-robin」方式，或者經過其餘的一些算法等。

四、Consumers

每一個consumer屬於一個consumer group。發送到Topic的消息，只會被訂閱此Topic的每一個group中的一個consumer消費。
若是全部的consumer都具備相同的group（屬於queue模式），消息將會在consumer之間負載均衡。
若是全部的consumer都具備不一樣的group（屬於「發佈-訂閱」模式），消息將會廣播給全部的消費者。
一個partition中的消息只會被group中的一個consumer消費，一個consumer能夠消費多個partitions中的消息。kafka只能保證一個partitions中的消息被某個consumer消費是順序的。
kafka的設計原理決定，對於一個topic，同一個group中不能有多餘partitions個數的consumer同時消費，不然將某些consumer沒法獲得消息。

（4）   KafKa的部署結構

圖3：KafKa集羣結構圖

一、message（消息）是通訊的基本單位，每一個producer能夠向一個topic（主題）發佈一些消息。若是consumer訂閱了這個主題，那麼新發布的消息就會廣播給這些consumer。

二、Kafka是顯式分佈式的，多個producer、consumer和broker能夠運行在一個大的集羣上，做爲一個邏輯總體對外提供服 務。對於consumer，多個consumer能夠組成一個group，這個message只能傳輸給某個group中的某一個consumer. 

（5）   大數據架構：flume-ng+Kafka+Storm+HDFS 實時系統組合

1）數據採集：負責從各節點上實時採集數據，選用cloudera的flume來實現

2）數據接入：因爲採集數據的速度和數據處理的速度不必定同步，所以添加一個消息中間件來做爲緩衝，選用apache的kafka

3）流式計算：對採集到的數據進行實時分析，選用apache的storm

4）數據輸出：對分析後的結果持久化，暫定用mysql

圖4：大數據消息處理解決方案