目錄

• 前言
• 一、消息隊列 MQ
• • 為什么需要消息隊列（MQ）
  • 使用消息隊列的好處
  • 消息隊列的兩種模式
• 二、Kafka 概述
• • Kafka 簡介
  • Kafka 的特性
• 三 實驗

前言

一、消息隊列 MQ

• MQ，Message Queue 消息隊列

為什么需要消息隊列（MQ）

主要原因是由于在高并發(fā)環(huán)境下，同步請求來不及處理，請求往往會發(fā)生阻塞。比如大量的請求并發(fā)訪問數(shù)據(jù)庫，導(dǎo)致行鎖表鎖，最后請求線程會堆積過多，從而觸發(fā) too many connection 錯誤，引發(fā)雪崩效應(yīng)。

我們使用消息隊列，通過【異步處理】請求，從而緩解系統(tǒng)的壓力。

消息隊列常應(yīng)用于 異步處理，流量削峰，應(yīng)用解耦，消息通訊 等場景。

當(dāng)前比較常見的 MQ 中間件有 ActiveMQ、RabbitMQ、RocketMQ、Pulsar。

使用消息隊列的好處

（1）解耦

• 允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

（2）可恢復(fù)性

• 系統(tǒng)的一部分組件失效時，不會影響到整個系統(tǒng)。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。
• 因為MQ 將消息保存在磁盤中，恢復(fù)后可以繼續(xù)發(fā)送消息。

（3）緩沖（重點）

• 有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度，解決生產(chǎn)消息（先緩存） 和 消費消息 的處理速度不一致的情況。
• 生產(chǎn)消息 先進行緩存，放到緩沖區(qū)，消費消息 再慢慢去取，去處理，起到緩沖效果。

（4）靈活性 & 峰值處理能力

• 在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見。如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時待命無疑是巨大的浪費。
• 使用消息隊列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會因為突發(fā)的超負(fù)荷的請求而完全崩潰。
• 比如搶紅包、雙十一秒殺活動場景

（5）異步通信
很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

消息隊列的兩種模式

（1）點對點模式（一對一，消費者主動拉取數(shù)據(jù)，消息收到后消息清除)
消息生產(chǎn)者生產(chǎn)消息發(fā)送到消息隊列中，然后消息消費者從消息隊列中取出并且消費消息。消息被消費以后，消息隊列中不再有存儲，所以消息消費者不可能消費到已經(jīng)被消費的消息。消息隊列支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。

（2）發(fā)布/訂閱模式（一對多，又叫觀察者模式，消費者消費數(shù)據(jù)之后不會清除消息)
消息生產(chǎn)者（發(fā)布）將消息發(fā)布到topic中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不同，發(fā)布到topic 的消息會被所有訂閱者消費。
發(fā)布/訂閱模式是定義對象間一種一對多的依賴關(guān)系，使得每當(dāng)一個對象（目標(biāo)對象）的狀態(tài)發(fā)生改變，則所有依賴于它的對觀察者對象)都會得到通知并自動更新。

二、Kafka 概述

Kafka定義：

• Kafka 是一個分布式的、基于發(fā)布/訂閱模式的 消息隊列，主要應(yīng)用于大數(shù)據(jù)實時處理領(lǐng)域。

Kafka 簡介

• Kafka 是最初由 Linkedin 公司開發(fā)，于 2010年貢獻給了Apache 基金會并成為頂級開源項目。
• 是一個分布式、支持分區(qū)的(partition)、多副本的(replica)，基于Zookeeper協(xié)調(diào)的分布式消息中間件系統(tǒng)
• 它的最大的特性就是可以實時的處理大量數(shù)據(jù)以滿足各種需求場景，比如基于hadoop 的批處理系統(tǒng)、低延遲的實時系統(tǒng)、Spark/Flink流式處理引擎，nginx訪問日志，消息服務(wù)等等
• 用 scala語言編寫，

Kafka 的特性

高吞吐量、低延遲

• Kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒。每個topic可以分多個 Partition，Consumer Group對Partition進行消費操作，提高負(fù)載均衡能力和消費能力。
  ●可擴展性
• kafka集群支持熱擴展
  ●持久性、可靠性
• 消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失
  ●容錯性
• 允許集群中節(jié)點失敗（多副本情況下，若副本數(shù)量為n，則允許 n-1個節(jié)點失敗)

(1) Broker
一臺kafka服務(wù)器就是一個 broker。一個集群由多個broker組成。一個 broker 可以容納多個topic。

(2)Topic
可以理解為一個隊列，生產(chǎn)者和消費者面向的都是一個topic。
類似于數(shù)據(jù)庫的表名或者ES 的index
物理上不同topic 的消息分開存儲

(3) Partition
為了實現(xiàn)擴展性，一個非常大的 topic可以分布到多個 broker(即服務(wù)器）上，一個 topic可以分割為一個或多個partition，每個 partition 是一個有序的隊列。Kafka只保i證partition內(nèi)的記錄是有序的，而不保證topic 中不同partition的順序。

每個topic至少有一個partition，當(dāng)生產(chǎn)者產(chǎn)生數(shù)據(jù)的時候，會根據(jù)分配策略選擇分區(qū)，然后將消息追加到指定的分區(qū)的隊列末尾。

##Partation數(shù)據(jù)路由規(guī)則:
1．指定了patition，則直接使用;
2．未指定 patition但指定key（相當(dāng)于消息中某個屬性），通過對key的value進行hash取模，選出一個patition;
3. patition和 key都未指定，使用輪詢選出一個patition。
每條消息都會有一個自增的編號，用于標(biāo)識消息的偏移量，標(biāo)識順序從О開始。每個partition中的數(shù)據(jù)使用多個segment文件存儲。
如果 topic有多個partition，消費數(shù)據(jù)時就不能保證數(shù)據(jù)的順序。嚴(yán)格保證消息的消費順序的場景下（例如商品秒殺、搶紅包)，需要將partition數(shù)目設(shè)為1。

broker存儲topic 的數(shù)據(jù)。如果某 topic有N個partition，集群有N個broker，那么每個 broker存儲該 topio的一個partition。
·如果某topic有N個partition，集群有(N+M)個broker，那么其中有N個 broker存儲 topic的一個partition,剩下的M個broker 不存儲該topic的partition數(shù)據(jù)。
·如果某topic有N個partition，集群中 broker 數(shù)目少于N個，那么一個broker存儲該topic的一個或多個partition。在實際生產(chǎn)環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導(dǎo)致Kafka集群數(shù)據(jù)不均衡。
//分區(qū)的原因
方便在集群中擴展，每個Partition可以通過調(diào)整以適應(yīng)它所在的機器，而一個topic又可以有多個Partition組成，因此整個集群就可以適應(yīng)任意大小的數(shù)據(jù)了;
●可以提高并發(fā)，因為可以以Partition為單位讀寫了。

( 4) Leader
每個partition有多個副本，其中有且僅有一個作為Leader，Leader是當(dāng)前負(fù)責(zé)數(shù)據(jù)的讀寫的 partition。

(5） Follower
Follower跟隨Leader，所有寫請求都通過Leader 路由，數(shù)據(jù)變更會廣播給所有 Follower，Follower 與Leader保持?jǐn)?shù)據(jù)同步。Follower只負(fù)責(zé)備份，不負(fù)責(zé)數(shù)據(jù)的讀寫。
如果Leader 故障，則從Follower中選舉出一個新的 Leader。
當(dāng)Follower 掛掉、卡住或者同步太慢，Leader 會把這個Follower 從ISR (Leader維護的一個和Leader保持同步的Follower集合）列表中刪除，重新創(chuàng)建一個Follower。

( 6) Replica
副本，為保證集群中的某個節(jié)點發(fā)生故障時，該節(jié)點上的 partition 數(shù)據(jù)不丟失，且 kafka仍然能夠繼續(xù)工作，kafka提供了副本機制，一個topic的每個分區(qū)都有若干個副本，一個 leader和若干個follower。

(7) Producer
生產(chǎn)者即數(shù)據(jù)的發(fā)布者，該角色將消息發(fā)布到Kafka 的topic中。
broker接收到生產(chǎn)者發(fā)送的消息后，broker將該消息追加到當(dāng)前用于追加數(shù)據(jù)的 segment 文件中。生產(chǎn)者發(fā)送的消息，存儲到一個partition 中，生產(chǎn)者也可以指定數(shù)據(jù)存儲的 partition。

(8) Consumer
消費者可以從 broker中讀取數(shù)據(jù)。消費者可以消費多個topic中的數(shù)據(jù)。

(9) Consumer Group (CG)
消費者組，由多個consumer 組成。
所有的消費者都屬于某個消費者組，即消費者組是邏輯上的一個訂閱者。可為每個消費者指定組名，若不指定組名則屬于默認(rèn)的組。
將多個消費者集中到一起去處理某一個Topic 的數(shù)據(jù)，可以更快的提高數(shù)據(jù)的消費能力。
消費者組內(nèi)每個消費者負(fù)責(zé)消費不同分區(qū)的數(shù)據(jù)，一個分區(qū)只能由一個組內(nèi)消費者消費，防止數(shù)據(jù)被重復(fù)讀取。消費者組之間互不影響。

(10) offset 偏移量
可以唯一的標(biāo)識一條消息。
偏移量決定讀取數(shù)據(jù)的位置，不會有線程安全的問題，消費者通過偏移量來決定下次讀取的消息（即消費位置)。消息被消費之后，并不被馬上刪除，這樣多個業(yè)務(wù)就可以重復(fù)使用Kafka 的消息。
某一個業(yè)務(wù)也可以通過修改偏移量達到重新讀取消息的目的，偏移量由用戶控制。消息最終還是會被刪除的，默認(rèn)生命周期為1周(7*24小時）。

(11) Zookeeper
Kafka通過Zookeeper來存儲集群的meta信息。
由于consumer在消費過程中可能會出現(xiàn)斷電宕機等故障，consumer恢復(fù)后，需要從故
障前的位置的繼續(xù)消費，所以consumer需要實時記錄自己消費到了哪個 offset，以便故障恢復(fù)后繼續(xù)消費。
Kafka 0.9版本之前，consumer 默認(rèn)將offset 保存在Zookeeper中;從 0.9版本開始，
consumer默認(rèn)將offset 保存在 Kafka一個內(nèi)置的topic中，該topic為_consumer_ offsets。

三 實驗

filebeat → kafka → logstash → es → kibana

elk
7-8 logstash
7-3 es
7-4 es filebeat

zookeeper

總結(jié)

以上是生活随笔為你收集整理的消息队列MQ 之 Kafka的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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