從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） 目標
1、消息數據保存在磁盤，存取代價為O(1)。一般數據在磁盤上是使用BTree存儲的，存取代價為O（lgn）
2、高吞吐率。在普通的節點上，單機每秒10W消息讀寫
3、支持分布式，所有的producer、broker和consumer都會有多個，均為分布式的。
4、支持數據並行加載到Hadoop中。
（3） 相關概念
1、Topics/logs
一個Topic可以認為是一類消息，每個topic將被分成多個partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱為offset（偏移量），offset為一個long型數字，它是唯一的標記一條消息。kafka沒有提供索引機制來存儲offset，因為kafka中不對消息進行“隨機讀寫”。
kafka和ActiveMQ不同的是：即使消息被消費，消息仍然不會被立即刪除，日志文件將會根據broker中的配置要求，保留一定的時間之后刪除；比如log文件保留2天，之后不管消息是否被消費，文件都會被刪除。可以達到減少磁盤IO開支的效果。
2、Partitions
每個server（kafka實例）負責partitions中消息的讀寫操作；此外kafka還可以配置partitions需要備份的個數（replicas），每個partition將會被備份到多台機器上，以提高可用性。每個partition都有一個server為“leader”；leader負責所有的讀寫操作，如果leader失效，那么將會有其他follower來接管（成為新的leader）；follower只是簡單的跟進與leader，同步消息即可。leader server承載了全部的請求壓力，因此從集群整體考慮，有多少個partitions就有多少個leader，kafka將leader均衡分散在每個實例上，確保整體的性能穩定。
3、Producers
將消息發布到指定的Topic中，同時Producer也能決定將消息歸屬到哪個partitions，比如基於“round-robin”方式，或者通過其他的一些算法等。
4、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集群結構圖
1、message（消息）是通信的基本單位，每個producer可以向一個topic（主題）發布一些消息。如果consumer訂閱了這個主題，那么新發布的消息就會廣播給這些consumer。
2、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：大數據消息處理解決方案