1、Kafka是什麼
在流式計算中，Kafka一般用來緩存數據，Storm通過消費Kafka的數據進行計算。
KAFKA + STORM +REDIS
- 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信息，來保證系統可用性
2、JMS是什麼
2.1、JMS的基礎
JMS是什麼：JMS是Java提供的一套技術規範
JMS幹什麼用：用來異構系統 集成通信，緩解系統瓶頸，提高系統的伸縮性增強系統用戶體驗，使得系統模塊化和組件化變得可行並更加靈活
通過什麼方式：生產消費者模式（生產者、服務器、消費者）
jdk，kafka，activemq……
2.2、JMS消息傳輸模型
- 點對點模式（一對一，消費者主動拉取數據，消息收到後消息清除）
點對點模型通常是一個基於拉取或者輪詢的消息傳送模型，這種模型從隊列中請求信息，而不是將消息推送到客戶端。這個模型的特點是發送到隊列的消息被一個且只有一個接收者接收處理，即使有多個消息監聽者也是如此。
- 發佈/訂閱模式（一對多，數據生產後，推送給所有訂閱者）
發佈訂閱模型則是一個基於推送的消息傳送模型。發佈訂閱模型可以有多種不同的訂閱者，臨時訂閱者只在主動監聽主題時才接收消息，而持久訂閱者則監聽主題的所有消息，即時當前訂閱者不可用，處於離線狀態。
queue.put（object） 數據生產
queue.take(object) 數據消費
2.3、JMS核心組件
- Destination：消息發送的目的地，也就是前面說的Queue和Topic。
- Message ：從字面上就可以看出是被髮送的消息。
- Producer： 消息的生產者，要發送一個消息，必須通過這個生產者來發送。
- MessageConsumer： 與生產者相對應，這是消息的消費者或接收者，通過它來接收一個消息。
2.4、常見的類JMS消息服務器
2.4.1、JMS消息服務器 ActiveMQ
ActiveMQ 是Apache出品，最流行的，能力強勁的開源消息總線。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規範的。
主要特點：
- 多種語言和協議編寫客戶端。語言: Java, C, C++, C#, Ruby, Perl, Python, PHP。應用協議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
- 完全支持JMS1.1和J2EE 1.4規範 (持久化,XA消息,事務)
- 對Spring的支持,ActiveMQ可以很容易內嵌到使用Spring的系統裏面去,而且也支持Spring2.0的特性
- 通過了常見J2EE服務器(如 Geronimo,JBoss 4, GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置,可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業服務器上
- 支持多種傳送協議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
- 支持通過JDBC和journal提供高速的消息持久化
- 從設計上保證了高性能的集羣,客戶端-服務器,點對點
- 支持Ajax
- 支持與Axis的整合
- 可以很容易得調用內嵌JMS provider,進行測試
2.4.2、分佈式消息中間件 Metamorphosis
Metamorphosis (MetaQ) 是一個高性能、高可用、可擴展的分佈式消息中間件，類似於LinkedIn的Kafka，具有消息存儲順序寫、吞吐量大和支持本地和XA事務等特性，適用於大吞吐量、順序消息、廣播和日誌數據傳輸等場景，在淘寶和支付寶有着廣泛的應用，現已開源。
主要特點：
- 生產者、服務器和消費者都可分佈
- 消息存儲順序寫
- 性能極高,吞吐量大
- 支持消息順序
- 支持本地和XA事務
- 客戶端pull，隨機讀,利用sendfile系統調用，zero-copy ,批量拉數據
- 支持消費端事務
- 支持消息廣播模式
- 支持異步發送消息
- 支持http協議
- 支持消息重試和recover
- 數據遷移、擴容對用戶透明
- 消費狀態保存在客戶端
- 支持同步和異步複製兩種HA
- 支持group commit
2.4.3、分佈式消息中間件 RocketMQ
RocketMQ 是一款分佈式、隊列模型的消息中間件，具有以下特點：
- 能夠保證嚴格的消息順序
- 提供豐富的消息拉取模式
- 高效的訂閱者水平擴展能力
- 實時的消息訂閱機制
- 億級消息堆積能力
- Metaq3.0 版本改名，產品名稱改爲RocketMQ
2.4.4、其他MQ
- .NET消息中間件 DotNetMQ
- 基於HBase的消息隊列 HQueue
- Go 的 MQ 框架 KiteQ
- AMQP消息服務器 RabbitMQ
- MemcacheQ 是一個基於 MemcacheDB 的消息隊列服務器。
3、爲什麼需要消息隊列（重要）
消息系統的核心作用就是三點：解耦，異步和並行
以用戶註冊的案列來說明消息系統的作用
3.1、用戶註冊的一般流程
問題：隨着後端流程越來越多，每步流程都需要額外的耗費很多時間，從而會導致用戶更長的等待延遲。
3.2、用戶註冊的並行執行
問題：系統並行的發起了4個請求，4個請求中，如果某一個環節執行1分鐘，其他環節再快，用戶也需要等待1分鐘。如果其中一個環節異常之後，整個服務掛掉了。
3.3、用戶註冊的最終一致
- 保證主流程的正常執行、執行成功之後，發送MQ消息出去。
- 需要這個destination的其他系統通過消費數據再執行，最終一致。
4、Kafka核心組件
- Topic ：消息根據Topic進行歸類
- Producer：發送消息者
- Consumer：消息接受者
- broker：每個kafka實例(server)
- Zookeeper：依賴集羣保存meta信息。
5、Kafka集羣部署
5.1集羣部署的基本流程
下載安裝包、解壓安裝包、修改配置文件、分發安裝包、啓動集羣
5.2集羣部署的基礎環境準備
安裝前的準備工作（zk集羣已經部署完畢）
5.3 Kafka集羣部署
5.3.1、下載安裝包
在linux中使用wget命令下載安裝包
wget http://mirrors.hust.edu.cn/apache/kafka/0.8.2.2/kafka_2.11-0.8.2.2.tgz
5.3.2、解壓安裝包
tar -zxvf kafka_2.11-0.8.2.2.tgz -C /usr/local/
cd /usr/local
mv kafka_2.11-0.8.2.2 kafka kafka
5.3.3、修改配置文件
cp kafka/config/server.properties /server.properties.bak
vim server.properties
輸入以下內容：
5.3.4、分發安裝包
scp -r /kafka slave1:/usr/local
5.3.5、再次修改配置文件（重要）
依次修改各服務器上配置文件的的broker.id，分別是0,1,2不得重複。
5.3.6、啓動集羣
依次在各節點上啓動kafka
bin/kafka-server-start.sh config/server.properties
5.4、Kafka常用操作命令
- 查看當前服務器中的所有topic
bin/kafka-topics.sh –list –zookeeper Master:2181
- 創建topic
bin/kafka-topics.sh –create –zookeeper Master:2181 –replication-factor 1 –partitions 1 –topic test
注： partitions指定topic分區數，replication-factor指定topic每個分區的副本數
- partitions分區數:
- partitions ：分區數，控制topic將分片成多少個log。可以顯示指定，如果不指定則會使用broker(server.properties)中的num.partitions配置的數量
- 雖然增加分區數可以提供kafka集羣的吞吐量、但是過多的分區數或者或是單臺服務器上的分區數過多，會增加不可用及延遲的風險。因爲多的分區數，意味着需要打開更多的文件句柄、增加點到點的延時、增加客戶端的內存消耗。
- 分區數也限制了consumer的並行度，即限制了並行consumer消息的線程數不能大於分區數
- 分區數也限制了producer發送消息是指定的分區。如創建topic時分區設置爲1，producer發送消息時通過自定義的分區方法指定分區爲2或以上的數都會出錯的；這種情況可以通過alter –partitions 來增加分區數。
- replication-factor副本
- replication factor 控制消息保存在幾個broker(服務器)上，一般情況下等於broker的個數。
- 如果沒有在創建時顯示指定或通過API向一個不存在的topic生產消息時會使用broker(server.properties)中的default.replication.factor配置的數量
- 刪除topic
sh bin/kafka-topics.sh –delete –zookeeper Master:2181 –topic test
需要server.properties中設置delete.topic.enable=true否則只是標記刪除或者直接重啓。
- 通過shell命令發送消息
kafka-console-producer.sh –broker-list Master:9092 –topic itheima
- 通過shell消費消息
sh bin/kafka-console-consumer.sh –zookeeper Master:2181 –from-beginning –topic test1
- 查看消費位置
sh kafka-run-class.sh kafka.tools.ConsumerOffsetChecker –zookeeper
Master:2181 –group testGroup
- 查看某個Topic的詳情
sh kafka-topics.sh –topic test –describe –zookeeper Master:2181
5.5、kafka的使用
先啓動kafka的服務
bin/kafka-server-start.sh config/server.properties
在啓動生產者
kafka-console-producer.sh --broker-list hadoop000:9092 --topic logstashkafka
在啓動消費者消費
kafka-console-consumer.sh --zookeeper hadoop000:2181 --topic logstashkafka --from-beginning
在生產者中生產數據，消費者就能查看到數據。
