1.什么是Kafka

Kafka是一個高通過率的分布式消息系統(tǒng)

2.消息隊列（Message Queue)MQ的模型

消息隊列的簡單架構圖

3個核心概念：

Sender Application：消息隊列的發(fā)送者，也叫生產(chǎn)者producer

Message Queue

Receiver Application：消息接受者，也叫消費者comsumer

消息隊列：消息排隊，消息就是數(shù)據(jù)。通過消息模型可以完成一個系統(tǒng)和另一個系統(tǒng)的交互，系統(tǒng)的通信也就是系統(tǒng)與系統(tǒng)的調(diào)用。

消息隊列容易和SOA混淆

SOA系統(tǒng)是直接的調(diào)用，通過代理對另個系統(tǒng)調(diào)用，也叫RPC的解決方案。

作為消息的架構和作為SOA的RPC最大的區(qū)別：不是直接的調(diào)用關系，消息作為異構系統(tǒng)的整合是通過消息的傳遞完成彼此之間的交互解耦合，彼此之間協(xié)調(diào)的處理。

消息隊列的好處：1.解耦合 ?沒有系統(tǒng)的侵入性?2.提高系統(tǒng)的響應時間?

比如訂單支付本來是需要完成123，這樣會響應等待時間較長。

訂單支付成功的方法(){
? ? ? 1、修改訂單狀態(tài)
? ? ? 2、計算會員積分
? ? ? 3、通知物流進行配送
}

改進 ：把用戶最需要得到的響應操作放在訂單支付成功的方法()中

訂單支付成功的方法(){
? ? ? 1、修改訂單狀態(tài)
}

另外2個非主要功能可以借用消息系統(tǒng)發(fā)送到消息隊列中，由消費者來消費。

? ? ? 2、計算會員積分
? ? ? 3、通知物流進行配送

3.消息隊列的分類

兩種：點對點和發(fā)布訂閱

點對點問題：

1.如果消息被某個系統(tǒng)消費，但是其他系統(tǒng)就不能再消費

2.為了性能的提高我們還是希望有多點來消費，因為只能有一個消費者，所以這樣就無法實現(xiàn)。

所以點對點用的很少。

kafka也屬于發(fā)布訂閱。

4.其他常見消息隊列

RabbitMQ：支持的協(xié)議多，非常重量級消息隊列，對路由(Routing)，負載均衡(Load balance)或者數(shù)據(jù)持久化都有很好的支持。
負載和路由：系統(tǒng)設計中，消息隊列也許是要集群，集群就會消息在生產(chǎn)之后往哪個集群中的節(jié)點去發(fā)送數(shù)據(jù)。
持久化：有些消息隊列可以文件等形式存儲消息，目的是以防意外消息丟失。保證消息安全，但是由于其有IO所以性能有損失。

ZeroMQ：號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景，擅長的高級/復雜的隊列，但是技術也復雜，并且只提供非持久性的隊列。
不支持持久化。

ActiveMQ：很早出現(xiàn)了，Apache下的一個子項，類似ZeroMQ，能夠以代理人和點對點的技術實現(xiàn)隊列 。JMS的一個實現(xiàn)者。EJB可以對其訪問。
Redis：本質(zhì)上不是消息隊列而是一個key-Value的NoSql數(shù)據(jù)庫，但也支持MQ功能，數(shù)據(jù)量較小，性能優(yōu)于RabbitMQ，數(shù)據(jù)超過10K就很慢，10K之內(nèi)效率在上面三者之上。

5.Kafka簡介

Kafka是伴隨大數(shù)據(jù)產(chǎn)生的，只要處理大數(shù)據(jù)，主要是內(nèi)存計算，實時計算。Kafka作為一個非常重要的緩沖者完成內(nèi)存計算或者實時計算的數(shù)據(jù)支持。

Kafka 是分布式發(fā)布-訂閱消息系統(tǒng)，LinkedIn開源，Scala語言編寫。

Kafka 是分布式發(fā)布-訂閱消息系統(tǒng)。是一個分布式的，可劃分的（對消息進行分區(qū)），多訂閱者，冗余備份的持久性的日志服務（消息從生產(chǎn)者發(fā)送到kafka之后會存到其日志中）。它主要用于處理活躍的流式數(shù)據(jù)（幾分鐘左右，區(qū)別有mapreduce的幾個小時）。

6.Kafka的特點

1.同時為發(fā)布和訂閱提供高吞吐量。據(jù)了解，Kafka 每秒可以生產(chǎn)約 25 萬消息（50 MB），每秒處理 55 萬消息（110 MB）。
2.可進行持久化操作。將消息持久化到磁盤，因此可用于批量消費，例如 ETL，以及實時應用程序。通過將數(shù)據(jù)持久化到硬盤以及 replication 防止數(shù)據(jù)丟失。
3.分布式系統(tǒng)，易于向外擴展。所有的 producer、broker（對于MQ的表達，消息服務器叫broker） 和 consumer 都會有多個，均為分布式的。無需停機即可擴展機器。擴展需要依賴于zookeeper做節(jié)點負載均衡和master節(jié)點選舉。
4.消息被處理的狀態(tài)是在 consumer 端維護，而不是由 server 端維護。當失敗時能自動平衡。

由哪個?consumer消費，消費了多少Broker不管。Broker只管存消息，刪消息，不維護消息狀態(tài)，是無狀態(tài)服務。consumer需要zookeeper配合完成，消息來了，需要?consumer 去watch到zookeeper中的變化，zookeeper會記錄消費的內(nèi)容。
5.支持 online 和 offline 的場景。

7.性能測試

在虛擬機上做的性能測試。 測試環(huán)境：cpu: 雙核? ?內(nèi)存 ：2GB? ?硬盤：60GB
結論

消息堆積壓力測試	單個kafka broker節(jié)點測試，啟動一個kafka broker和Producer，Producer不斷向broker發(fā)送數(shù)據(jù)， 直到broker堆積數(shù)據(jù)為18GB為止(停止Producer運行)。啟動Consumer，不間斷從broker獲取數(shù)據(jù)， 直到全部數(shù)據(jù)讀取完成為止，最后查看Producer==Consumer數(shù)據(jù)，沒有出現(xiàn)卡死或broker不響應現(xiàn)象	數(shù)據(jù)大量堆積不會出現(xiàn)broker卡死 或不響應現(xiàn)象
生產(chǎn)者速率	1.200byte/msg,4w/s左右。2.1KB/msg,1w/s左右	性能上是完全滿足要求，其性能主要由磁盤決定
消費者速率	1.200byte/msg,4w/s左右。2.1KB/msg,1w/s左右	性能上是完全滿足要求，其性能主要由磁盤決定

參考：http://www.aboutyun.com/thread-9942-1-1.html

8.Kafka的邏輯架構

Produces生產(chǎn)消息放到topic中，會有多個topic，消息有分類，不同的消息對應不同的topic。

總結

以上是生活随笔為你收集整理的《Apache Kafka》学习笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。