kafaka數據怎麼看

1. 請問kafka和rabbitmq有啥區別啊

kafaka和rabbitmq的最主要區別在於數據的可靠性和吞吐量上；在實際場景中，需要按需求取捨。rabbitmq在金融場景中經常使用，具有較高的嚴謹性，數據丟失的可能性更小，同時具備更高的實時性，基於存儲的可靠性的要求存儲可以採用內存或者硬碟。而kafka優勢主要體現在吞吐量上，雖然可以通過策略實現數據不丟失，但從嚴謹性角度來講，大不如rabbitmq；而且由於kafka保證每條消息最少送達一次，有較小的概率會出現數據重復發送的情況。
請採納，謝謝！

2. Spark 應用場景示例

使用IDE新建Scala 或 Java 工程，確保項目結構符合 Maven 推薦的項目結構。

以IDEA為例：

從靜態數據源(Parquet,Json,CVS,JDBC,Hive,RDDs)讀取數據，運行分析

再 resource 目錄構建一個 Json 數據源 data.json :

新建 Static Data Spark Demo.scala :

以上，我們擬對數據進行展示和基本的篩選工作(age > 10)

開啟調試,可以看到 log 中Spark執行了 3 個 Job ，並已經正確輸出了預期的結果。

接下來就可以根據需求進行更復雜的數據處理操作

從Kafka、Flume、S3/HDFS、kinesis、Twitter等數據源讀取數據進行實時分析

例：從 Kafka 讀取流數據，進行實時處理。

由於讀取Kafka流式數據，我們需要模擬kafka流。

參考Kafka文檔

核心文件 KafkaApplication.java

application.yml

以上，我們向Kafka伺服器的 topic 為 saprk 上不斷發送數據以模擬數據流。
現在，啟動程序開始模擬數據流

復用上例中的目錄結構，也可以新建一個 sbt 項目。

新建文件 StreamDataSparkDemo.scala

以上，我們從Kafaka伺服器讀取一個 topic 為 spark 的流，然後進行展示。

運行程序，輸出如下：

取出數據之後，就可以用於實時分析了。

假設topic spark 為新注冊的用戶信息，我們可以統計新用戶的每實時注冊量，以及階段內新注冊用戶性別比例。

在 StreamDataSparkDemo.scala 中修改

<未完待續...>

3. 海康威視1——p6升級2——p7怎麼面試

電話面試：

第一次面試關注的問題，
1）java基礎：
jvm 內存回收，垃圾回收基本原理，Java並發包的線程池，Java8的新特性。nio 堆排序。conrenthashmap , concurrenthashmap 的size實現, spring的事務
2）資料庫基礎：
事務隔離級別，資料庫連接池,鎖性等。。MQ如何保證順序性。spring事務傳播性。 資料庫跨庫一致性
資料庫死鎖的問題，一個刪除昨天一個刪除今天的，怎麼死鎖的。
還有個延遲隊列和隊列排序的問題。
3）如果項目中有用到框架：Redis，RPC、Kafaka、MQ 、Spring 等。
問到的問題比如springmvc工作機制、Spring MVC的aop實現原理，Spring MVC 的請求過程，一個Controller是單例還是多實例。再比如Redis，在項目裡面承擔了核心緩存左右，選擇的持久化方式是什麼。redis恢復。Redis的內存廢棄策略。redis高並發的key怎麼處理。
非常注重源代碼，不管是jdk的，還是框架的
還有比如spring，redis源代碼的實現
架構方面，分布式框架和中間件問題:
bbo原理
zookeeper原理
netty原理
高並發綜合策略 數據一致性處理策略
4）線上問題處理經驗
5）表達對技術的鑽研熱情
第二次電話面試是交叉面試，同上。
第三次是現場技術終面+HR面
P6的考察側重點
1、80後。
2給人的感覺是上進心很強，努力學習精進技術的，不願意混日子。
過往的工作經驗是owner一個獨立的業務系統，負責系統的設計開發工作，可以不是架構。明確知道系統架構的情況，理解上下游關系。理解該系統的業務定位，該系統當前存在的問題和後續的規劃發展有自己的見解。
3 Java基礎知識和分布式經驗應該很熟悉，框架層面源碼如果能研讀可以加分。但是如果只是會用而不了解原理就要減分。
4會重點考察分布式/服務化系統（不是大流量高並發）的設計原理，思路，關注點。要會理解一些分布式session、全局流水ID號、服務多次重試冪等、同步轉非同步、服務監控、最終一致性等原理和應用。
P7的考察側重點
1 敢說敢做，有氣場勇於承擔事情
2不是一個單純的技術實現人員，而是一個有規劃，有思考的人。主導一個復雜的系統（多個業務系統完整鏈路）；或者負責一塊五臟俱全的業務。
3 對業務系統的理解會更多從商業價值角度去描述，熟悉這塊產品鏈的模式和玩法，或者工業化成熟度較高的專業實現方案。
對基礎中間件系統可以描述常見競品、實現原理演算法、核心難點。
4如果是電商交易類背景的，分布式系統設計原則要比P6的同學理解更深入：分庫分表分布式事務、性能穩定性的實踐。
如果能描述分庫分表中間件實現原理（SQLParse、語法樹）、單元化/多機房災備可以加分-就可以往P7+、P8去談。
5 P7的同學開放式的問題會比較多，會更多在答題思路和內容中去挖掘亮點。

4. RabbitMQ，RocketMQ，Kafka 事務性，消息丟失和重復發送處理策略

我們的伺服器從單機發展到擁有多台機器的分布式系統，各個系統之前需要藉助於網路進行通信，原有單機中相對可靠的方法調用以及進程間通信方式已經沒有辦法使用，同時網路環境也是不穩定的，造成了我們多個機器之間的數據同步問題，這就是典型的分布式事務問題。

在分布式事務中事務的參與者、支持事務的伺服器、資源伺服器以及事務管理器分別位於不同的分布式系統的不同節點之上。分布式事務就是要保證不同節點之間的數據一致性。

1、2PC(二階段提交)方案 - 強一致性

2、3PC(三階段提交)方案

3、TCC （Try-Confirm-Cancel）事務 - 最終一致性

4、Saga事務 - 最終一致性

5、本地消息表 - 最終一致性

6、MQ事務 - 最終一致性

消息的生產方，除了維護自己的業務邏輯之外，同時需要維護一個消息表。這個消息表裡面記錄的就是需要同步到別的服務的信息，當然這個消息表，每個消息都有一個狀態值，來標識這個消息有沒有被成功處理。

發送放的業務邏輯以及消息表中數據的插入將在一個事務中完成，這樣避免了業務處理成功 + 事務消息發送失敗，或業務處理失敗 + 事務消息發送成功，這個問題。

舉個栗子：

我們假定目前有兩個服務，訂單服務，購物車服務，用戶在購物車中對幾個商品進行合並下單，之後需要情況購物車中剛剛已經下單的商品信息。

1、消息的生產方也就是訂單服務，完成了自己的邏輯(對商品進行下單操作)然後把這個消息通過 mq 發送到需要進行數據同步的其他服務中，也就是我們栗子中的購物車服務。

2、其他服務(購物車服務)會監聽這個隊列；

1、如果收到這個消息，並且數據同步執行成功了，當然這也是一個本地事務，就通過 mq 回復消息的生產方(訂單服務)消息已經處理了，然後生產方就能標識本次事務已經結束。如果是一個業務上的錯誤,就回復消息的生產方，需要進行數據回滾了。

2、很久沒收到這個消息，這種情況是不會發生的，消息的發送方會有一個定時的任務，會定時重試發送消息表中還沒有處理的消息；

3、消息的生產方(訂單服務)如果收到消息回執；

1、成功的話就修改本次消息已經處理完，也就是本次分布式事務的同步已經完成；

2、如果消息的結果是執行失敗，同時在本地回滾本次事務，標識消息已經處理完成；

3、如果消息丟失，也就是回執消息沒有收到，這種情況也不太會發生，消息的發送方(訂單服務)會有一個定時的任務，定時重試發送消息表中還沒有處理的消息，下游的服務需要做冪等，可能會收到多次重復的消息，如果一個回復消息生產方中的某個回執信息丟失了，後面持續收到生產方的 mq 消息，然後再次回復消息的生產方回執信息，這樣總能保證發送者能成功收到回執，消息的生產方在接收回執消息的時候也要做到冪等性。

這里有兩個很重要的操作：

1、伺服器處理消息需要是冪等的，消息的生產方和接收方都需要做到冪等性；

2、發送放需要添加一個定時器來遍歷重推未處理的消息，避免消息丟失，造成的事務執行斷裂。

該方案的優缺點

優點：

1、在設計層面上實現了消息數據的可靠性，不依賴消息中間件，弱化了對 mq 特性的依賴。

2、簡單，易於實現。

缺點：

主要是需要和業務數據綁定到一起，耦合性比較高，使用相同的資料庫，會佔用業務資料庫的一些資源。

下面分析下幾種消息隊列對事務的支持

RocketMQ 中的事務，它解決的問題是，確保執行本地事務和發消息這兩個操作，要麼都成功，要麼都失敗。並且，RocketMQ 增加了一個事務反查的機制，來盡量提高事務執行的成功率和數據一致性。

主要是兩個方面，正常的事務提交和事務消息補償

正常的事務提交

1、發送消息（half消息），這個 half 消息和普通消息的區別，在事務提交 之前，對於消費者來說，這個消息是不可見的。

2、MQ SERVER寫入信息，並且返回響應的結果；

3、根據MQ SERVER響應的結果，決定是否執行本地事務,如果MQ SERVER寫入信息成功執行本地事務，否則不執行；

如果MQ SERVER沒有收到 Commit 或者 Rollback 的消息，這種情況就需要進行補償流程了

補償流程

1、MQ SERVER如果沒有收到來自消息發送方的 Commit 或者 Rollback 消息，就會向消息發送端也就是我們的伺服器發起一次查詢，查詢當前消息的狀態；

2、消息發送方收到對應的查詢請求，查詢事務的狀態，然後把狀態重新推送給MQ SERVER，MQ SERVER就能之後後續的流程了。

相比於本地消息表來處理分布式事務，MQ 事務是把原本應該在本地消息表中處理的邏輯放到了 MQ 中來完成。

Kafka 中的事務解決問題，確保在一個事務中發送的多條信息，要麼都成功，要麼都失敗。也就是保證對多個分區寫入操作的原子性。

通過配合 Kafka 的冪等機制來實現 Kafka 的 Exactly Once，滿足了讀取-處理-寫入這種模式的應用程序。當然 Kafka 中的事務主要也是來處理這種模式的。

什麼是讀取-處理-寫入模式呢？

栗如：在流計算中，用 Kafka 作為數據源，並且將計算結果保存到 Kafka 這種場景下，數據從 Kafka 的某個主題中消費，在計算集群中計算，再把計算結果保存在 Kafka 的其他主題中。這個過程中，要保證每條消息只被處理一次，這樣才能保證最終結果的成功。Kafka 事務的原子性就保證了，讀取和寫入的原子性，兩者要不一起成功，要不就一起失敗回滾。

這里來分析下 Kafka 的事務是如何實現的

它的實現原理和 RocketMQ 的事務是差不多的，都是基於兩階段提交來實現的，在實現上可能更麻煩

先來介紹下事務協調者，為了解決分布式事務問題，Kafka 引入了事務協調者這個角色，負責在服務端協調整個事務。這個協調者並不是一個獨立的進程，而是 Broker 進程的一部分，協調者和分區一樣通過選舉來保證自身的可用性。

Kafka 集群中也有一個特殊的用於記錄事務日誌的主題，裡面記錄的都是事務的日誌。同時會有多個協調者的存在，每個協調者負責管理和使用事務日誌中的幾個分區。這樣能夠並行的執行事務，提高性能。

下面看下具體的流程

事務的提交

1、協調者設置事務的狀態為PrepareCommit，寫入到事務日誌中；

2、協調者在每個分區中寫入事務結束的標識，然後客戶端就能把之前過濾的未提交的事務消息放行給消費端進行消費了；

事務的回滾

1、協調者設置事務的狀態為PrepareAbort，寫入到事務日誌中；

2、協調者在每個分區中寫入事務回滾的標識，然後之前未提交的事務消息就能被丟棄了；

這里引用一下【消息隊列高手課中的圖片】

RabbitMQ 中事務解決的問題是確保生產者的消息到達MQ SERVER，這和其他 MQ 事務還是有點差別的，這里也不展開討論了。

先來分析下一條消息在 MQ 中流轉所經歷的階段。

生產階段 ：生產者產生消息，通過網路發送到 Broker 端。

存儲階段 ：Broker 拿到消息，需要進行落盤，如果是集群版的 MQ 還需要同步數據到其他節點。

消費階段 ：消費者在 Broker 端拉數據，通過網路傳輸到達消費者端。

發生網路丟包、網路故障等這些會導致消息的丟失

在生產者發送消息之前，通過channel.txSelect開啟一個事務，接著發送消息， 如果消息投遞 server 失敗，進行事務回滾channel.txRollback，然後重新發送， 如果 server 收到消息，就提交事務channel.txCommit

不過使用事務性能不好，這是同步操作，一條消息發送之後會使發送端阻塞，以等待RabbitMQ Server的回應，之後才能繼續發送下一條消息，生產者生產消息的吞吐量和性能都會大大降低。

使用確認機制，生產者將信道設置成 confirm 確認模式，一旦信道進入 confirm 模式，所有在該信道上面發布的消息都會被指派一個唯一的ID（從1開始），一旦消息被投遞到所有匹配的隊列之後，RabbitMQ 就會發送一個確認（Basic.Ack）給生產者（包含消息的唯一 deliveryTag 和 multiple 參數），這就使得生產者知曉消息已經正確到達了目的地了。

multiple 為 true 表示的是批量的消息確認，為 true 的時候，表示小於等於返回的 deliveryTag 的消息 id 都已經確認了，為 false 表示的是消息 id 為返回的 deliveryTag 的消息，已經確認了。

確認機制有三種類型

1、同步確認

2、批量確認

3、非同步確認

同步模式的效率很低，因為每一條消息度都需要等待確認好之後，才能處理下一條；

批量確認模式相比同步模式效率是很高，不過有個致命的缺陷，一旦回復確認失敗，當前確認批次的消息會全部重新發送，導致消息重復發送；

非同步模式就是個很好的選擇了，不會有同步模式的阻塞問題，同時效率也很高，是個不錯的選擇。

Kafaka 中引入了一個 broker。 broker 會對生產者和消費者進行消息的確認，生產者發送消息到 broker，如果沒有收到 broker 的確認就可以選擇繼續發送。

只要 Procer 收到了 Broker 的確認響應，就可以保證消息在生產階段不會丟失。有些消息隊列在長時間沒收到發送確認響應後，會自動重試，如果重試再失敗，就會以返回值或者異常的方式告知用戶。

只要正確處理 Broker 的確認響應，就可以避免消息的丟失。

RocketMQ 提供了3種發送消息方式，分別是：

同步發送：Procer 向 broker 發送消息，阻塞當前線程等待 broker 響應 發送結果。

非同步發送：Procer 首先構建一個向 broker 發送消息的任務，把該任務提交給線程池，等執行完該任務時，回調用戶自定義的回調函數，執行處理結果。

Oneway發送：Oneway 方式只負責發送請求，不等待應答，Procer 只負責把請求發出去，而不處理響應結果。

在存儲階段正常情況下，只要 Broker 在正常運行，就不會出現丟失消息的問題，但是如果 Broker 出現了故障，比如進程死掉了或者伺服器宕機了，還是可能會丟失消息的。

防止在存儲階段消息額丟失，可以做持久化，防止異常情況(重啟，關閉，宕機)。。。

RabbitMQ 持久化中有三部分：

消息的持久化，在投遞時指定 delivery_mode=2（1是非持久化），消息的持久化，需要配合隊列的持久，只設置消息的持久化，重啟之後隊列消失，繼而消息也會丟失。所以如果只設置消息持久化而不設置隊列的持久化意義不大。

對於持久化，如果所有的消息都設置持久化，會影響寫入的性能，所以可以選擇對可靠性要求比較高的消息進行持久化處理。

不過消息持久化並不能百分之百避免消息的丟失

比如數據在落盤的過程中宕機了，消息還沒及時同步到內存中，這也是會丟數據的，這種問題可以通過引入鏡像隊列來解決。

鏡像隊列的作用：引入鏡像隊列，可已將隊列鏡像到集群中的其他 Broker 節點之上，如果集群中的一個節點失效了，隊列能夠自動切換到鏡像中的另一個節點上來保證服務的可用性。(更細節的這里不展開討論了)

操作系統本身有一層緩存，叫做 Page Cache，當往磁碟文件寫入的時候，系統會先將數據流寫入緩存中。

Kafka 收到消息後也會先存儲在也緩存中(Page Cache)中，之後由操作系統根據自己的策略進行刷盤或者通過 fsync 命令強制刷盤。如果系統掛掉，在 PageCache 中的數據就會丟失。也就是對應的 Broker 中的數據就會丟失了。

處理思路

1、控制競選分區 leader 的 Broker。如果一個 Broker 落後原先的 Leader 太多，那麼它一旦成為新的 Leader，必然會造成消息的丟失。

2、控制消息能夠被寫入到多個副本中才能提交，這樣避免上面的問題1。

1、將刷盤方式改成同步刷盤；

2、對於多個節點的 Broker，需要將 Broker 集群配置成：至少將消息發送到 2 個以上的節點，再給客戶端回復發送確認響應。這樣當某個 Broker 宕機時，其他的 Broker 可以替代宕機的 Broker，也不會發生消息丟失。

消費階段就很簡單了，如果在網路傳輸中丟失，這個消息之後還會持續的推送給消費者，在消費階段我們只需要控制在業務邏輯處理完成之後再去進行消費確認就行了。

總結：對於消息的丟失，也可以藉助於本地消息表的思路，消息產生的時候進行消息的落盤，長時間未處理的消息，使用定時重推到隊列中。

消息在 MQ 中的傳遞，大致可以歸類為下面三種：

1、At most once: 至多一次。消息在傳遞時，最多會被送達一次。是不安全的，可能會丟數據。

2、At least once: 至少一次。消息在傳遞時，至少會被送達一次。也就是說，不允許丟消息，但是允許有少量重復消息出現。

3、Exactly once：恰好一次。消息在傳遞時，只會被送達一次，不允許丟失也不允許重復，這個是最高的等級。

大部分消息隊列滿足的都是At least once，也就是可以允許重復的消息出現。

我們消費者需要滿足冪等性,通常有下面幾種處理方案

1、利用資料庫的唯一性

根據業務情況，選定業務中能夠判定唯一的值作為資料庫的唯一鍵，新建一個流水表，然後執行業務操作和流水表數據的插入放在同一事務中，如果流水表數據已經存在，那麼就執行失敗，藉此保證冪等性。也可先查詢流水表的數據，沒有數據然後執行業務，插入流水表數據。不過需要注意，資料庫讀寫延遲的情況。

2、資料庫的更新增加前置條件

3、給消息帶上唯一ID

每條消息加上唯一ID,利用方法1中通過增加流水表，藉助資料庫的唯一性來處理重復消息的消費。

5. 4.一文搞定：Flink與Kafka之間的精準一次性

在上一篇文章當中，也算是比較詳細且通俗的聊了聊Flink是如何通過checkpoint機制來完成數據精準一次性的實現的。並且也在上一章的結尾表示，要在接下來聊一聊Flink與它的鐵哥們Kafaka之間，是如何實現數據的精準一次性消費的。
本次的聊法，還是要通過以kafka（source）->Flink,Flink(source)->Kafka來分別展開討論。

kafka是一個具有數據保存、數據回放能力的消息隊列，說白了就是kafka中的每一個數據，都有一個專門的標記作為標識。而在Flink消費kafka傳入的數據的時候，source任務就能夠將這個偏移量以運算元狀態的角色進行保存，寫入到設定好的檢查點中。這樣一旦發生故障，Flink中的FlinkKafkaProce連接器就i能夠按照自己保存的偏移量，自己去Kafka中重新拉取數據，也正是通過這種方式，就能夠確保Kafka到Flink之間的精準一次性。

在上一篇文章當中，已經表明了，如果想要讓輸出端能夠進行精準一次性消費，就需要使用到冪等性或者是事務。而事務中的兩階段提交是所有方案裡面最好的實現。

其實Flink到Kafak之間也是採用了這種方式，具體的可以看一下ctrl進到FlinkKafkaProce連接器內部去看一看：

這也就表明了，當數據通過Flink發送給sink端Kafka的時候，是經歷了兩個階段的處理的。第一階段就是Flink向Kafka中插入數據，進入預提交階段。當JobManager發送的Ckeckpoint保存成功信號過來之後，才會提交事務進行正式的數據發送，也就是讓原來不可用的數據可以被使用了。

這個實現過程到目前階段就很清晰了，它的主體流程無非就是在開啟檢查點之後，由JobManager向各個階段的處理邏輯發送有關於檢查點的barrier。所有的計算任務接收到之後，就會根據自己當前的狀態做一個檢查點保存。而當這個barrier來到sink任務的時候，sink就會開啟一個事務，然後通過這個事務向外預寫數據。直到Jobmanager來告訴它這一次的檢查點已經保存完成了，sink就會進行第二次提交，數據也就算是成功寫出了。

1.必須要保證檢查點被打開了，如果檢查點沒有打開，那麼之前說的一切話都是空談。因為Flink默認檢查點是關著的。
2.在FlinkKafakProcer連接器的構造函數中要傳入參數，這個參數就是用來保證狀態一致性的。就是在構造函數的最後一個參數輸入如下：

3.配置Kafka讀取數據的隔離級別
在kafka中有個配置，這個配置用來管理Kafka讀取數據的級別。而這個配置默認是能夠讀取預提交階段的數據的，所以如果你沒改這個配置，那兩階段提交的第一階段就是白費了。所以需要改一下這個配置，來更換一下隔離級別：

4.事務超時時間
這個配置也很有意思，大家試想一下。如果要進行兩階段提交，就要保證sink端支持事務，Kafka是支持事務的，但是像這個組件對於很多機制都有一個超時時間的概念，也就是說如果時間到了這個界限還沒完成工作，那就會默認這個工作失敗。Kafka中由這個概念，Flink中同樣由這個概念。但是flink默認超時時間是1小時，而Kafka默認是15分鍾，這就有可能出現檢查點保存東西的時間大於15分鍾，假如說是16分鍾保存完成然後給sink發送檢查點保存陳功可以提交事務的信號，但是這個時候Kafka已經認為事務失敗，把之前的數據都扔了。那數據不就是丟失了么。所以說Kafka的超時時間要大於Flink的超時時間才好。

截止到目前為止，基本上把有關於狀態維護的一些東西都說完了，有狀態後端、有檢查點。還通過檢查點完成可端到端的數據精準一次性消費。但是想到這我又感覺，如果有學習進度比我差一些的，萬一沒辦法很好的理解怎麼辦。所以在下一篇文章當中我就聊聊Flink中的「狀態」到底是個什麼東西，都有什麼類型，都怎麼去用。

6. 三、Kafaka的基本操作

在啟動Kafka之前，需要啟動zookeeper，否則會報錯！相關的啟動指令如下：

在此配置中，只有一個 ZooKeeper 和代理 id 實例。 配置步驟如下：（注意，以下過程中的topicName表示創建主題的名稱，可以自己定義。）
（1）創建Kafka主題
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic topicName
創建主題後，會在 Kafka 代理終端窗口中獲取通知，並在 config / server.properties 文件中的「/ tmp / kafka-logs /"中指定創建主題的日誌。
（2）啟動生產者以發送消息
bin/kafka-console-procer.sh --broker-list localhost:9092 --topic topicName
生產者命令行客戶端需要兩個主要參數：
1.代理列表（broker-list）： 要發送郵件的代理列表。 這種情況下，只有一個代理。
2.監聽埠： Config / server.properties 文件包含代理埠 ID，可以查到代理正在偵聽埠 9092，因此直接指定它。
生產者在 config / procer.properties 文件中指定默認生產者屬性。
（3）啟動消費者以接收消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topicName --from-beginning
消費者在config / consumer.properties 文件中指定了默認消費者屬性。 打開一個新終端並鍵入以下消息消息語法。
（4）在生產者終端輸入數據測試
生產者將等待消息的輸入並發布到 Kafka 集群。 默認情況下，每行數據都作為新消息發布。在生產者終端輸入數據，這些數據都會在消費者終端顯示。

7. MQ之主流MQ：kafaka+RocketMQ+RabbitMQ對比

@TOC

消息隊列已經逐漸成為企業IT系統內部通信的核心手段。它具有低耦合、可靠投遞、廣播、流量控制、最終一致性等一系列功能，成為非同步RPC的主要手段之一。當今市面上有很多主流的消息中間件，如老牌的ActiveMQ、RabbitMQ，炙手可熱的Kafka，阿里巴巴自主開發RocketMQ等。

有些業務不想也不需要立即處理消息。消息隊列提供了非同步處理機制，允許用戶把一個消息放入隊列，但並不立即處理它。想向隊列中放入多少消息就放多少，然後在需要的時候再去處理它們。

降低工程間的強依賴程度，針對異構系統進行適配。在項目啟動之初來預測將來項目會碰到什麼需求，是極其困難的。通過消息系統在處理過程中間插入了一個隱含的、基於數據的介面層，兩邊的處理過程都要實現這一介面，當應用發生變化時，可以獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的介面約束。

有些情況下，處理數據的過程會失敗。除非數據被持久化，否則將造成丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險。許多消息隊列所採用的」插入-獲取-刪除」範式中，在把一個消息從隊列中刪除之前，需要你的處理系統明確的指出該消息已經被處理完畢，從而確保你的數據被安全的保存直到你使用完畢。

因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調節參數。便於分布式擴容。

在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量無法提取預知；如果以為了能處理這類瞬間峰值訪問為標准來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因為突發的超負荷的請求而完全崩潰。

系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。

在大多使用場景下，數據處理的順序都很重要。大部分消息隊列本來就是排序的，並且能保證數據會按照特定的順序來處理。

在任何重要的系統中，都會有需要不同的處理時間的元素。消息隊列通過一個緩沖層來幫助任務最高效率的執行，該緩沖有助於控制和優化數據流經過系統的速度。以調節系統響應時間。

分布式系統產生的海量數據流，如：業務日誌、監控數據、用戶行為等，針對這些數據流進行實時或批量採集匯總，然後進行大數據分析是當前互聯網的必備技術，通過消息隊列完成此類數據收集是最好的選擇。

交互系統之間沒有直接的調用關系，只是通過消息傳輸，故系統侵入性不強，耦合度低。

例如原來的一套邏輯，完成支付可能涉及先修改訂單狀態、計算會員積分、通知物流配送幾個邏輯才能完成；通過MQ架構設計，就可將緊急重要（需要立刻響應）的業務放到該調用方法中，響應要求不高的使用消息隊列，放到MQ隊列中，供消費者處理。

通過消息作為整合，大數據的背景下，消息隊列還與實時處理架構整合，為數據處理提供性能支持。

項目的復雜度提高

MQ的高度依賴

AMQP即Advanced Message Queuing Protocol,一個提供統一消息服務的應用層標准高級消息隊列協議,是應用層協議的一個開放標准,為面向消息的中間件設計。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端/中間件不同產品，不同開發語言等條件的限制。 優點：可靠、通用

MQTT（Message Queuing Telemetry Transport，消息隊列遙測傳輸）是IBM開發的一個即時通訊協議，有可能成為物聯網的重要組成部分。該協議支持所有平台，幾乎可以把所有聯網物品和外部連接起來，被用來當做感測器和致動器（比如通過Twitter讓房屋聯網）的通信協議。 優點：格式簡潔、佔用帶寬小、移動端通信、PUSH、嵌入式系統

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協議，是一種為MOM(Message Oriented Middleware，面向消息的中間件)設計的簡單文本協議。STOMP提供一個可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進行交互。 優點：命令模式（非topicqueue模式）

XMPP（可擴展消息處理現場協議，Extensible Messaging and Presence Protocol）是基於可擴展標記語言（XML）的協議，多用於即時消息（IM）以及在線現場探測。適用於伺服器之間的准即時操作。核心是基於XML流傳輸，這個協議可能最終允許網際網路用戶向網際網路上的其他任何人發送即時消息，即使其操作系統和瀏覽器不同。 優點：通用公開、兼容性強、可擴展、安全性高，但XML編碼格式佔用帶寬大

有些特殊框架（如：redis、kafka、zeroMq等）根據自身需要未嚴格遵循MQ規范，而是基於TCPIP自行封裝了一套協議，通過網路socket介面進行傳輸，實現了MQ的功能。

參考：

https://blog.csdn.net/wqc19920906/article/details/82193316

8. kafka 怎樣查看kafka狀態

輸入以下代碼即可查看kafka狀態：

BROKER_HOST是kafka server的ip地址，PORTt是server的監聽埠。多個host port之間用逗號隔開。

第一條命令是獲取group列表，一般而言，應用是知道消費者group的，通常在應用的配置里，如果已知，該步驟可以省略。

第二條命令是查看具體的消費者group的詳情信息，需要給出group的名稱。

Kafka是由Apache軟體基金會開發的一個開源流處理平台，由Scala和Java編寫。Kafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者在網站中的所有動作流數據。

這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。

對於像Hadoop一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群來提供實時的消息。

9. Kafaka入門（1）- Kafka簡介和安裝與啟動（mac）

Kafka是由Apache軟體基金會開發的一個開源流處理平台，由Scala和Java編寫。kafka 是一個高性能的消息隊列，也是一個分布式流處理平台。
kafka中文網
kafka官網

Procer ：Procer即生產者，消息的產生者，是消息的入口。
kafka cluster ：
Broker ：Broker是kafka實例，每個伺服器上有一個或多個kafka的實例，姑且認為每個broker對應一台伺服器。一個集群由多個broker組成，集群內的broker都有一個不重復的編號，如圖中的broker-0、broker-1等……
Topic ：消息的主題，可以理解為消息的分類，kafka的數據就保存在topic。在每個broker上都可以創建多個topic。
Partition ：Topic的分區，每個topic可以有多個分區，分區的作用是做負載，提高kafka的吞吐量。 同一個topic在不同的分區的數據是不重復的 ，partition的表現形式就是一個一個的文件夾！
Replication : 每一個分區都有多個副本 ，副本的作用是做備胎。當主分區（Leader）故障的時候會選擇一個備胎（Follower）上位，成為Leader。在kafka中默認副本的最大數量是10個，且副本的數量不能大於Broker的數量，follower和leader絕對是在不同的機器，同一機器對同一個分區也只可能存放一個副本（包括自己）。
Message ：每一條發送的消息主體。
Consumer ：消費者，即消息的消費方，是消息的出口。
Consumer Group ：將多個消費組成一個消費者組。在kafka的設計中 同一個分區的數據只能被同一消費者組中的某一個消費者消費 。Partition 的分配問題，即確定哪個 Partition 由哪個 Consumer 來消費。Kafka 有兩種分配策略，一個是 RoundRobin，一個是 Range，默認為Range。
一個消費者組內也可以訂閱多個topic
多個消費組可以訂閱同一個topic 。

Zookeeper ：kafka集群依賴zookeeper來保存集群的的元信息，來保證系統的可用性。

使用brew進行安裝，非常方便。

ZooKeeper是一個分布式的，開放源碼的 分布式應用程序協調服務 ，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟體，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。
kafka是基於zookeeper的，啟動kafka之前，需要先啟動zookeeper

查看啟動是否成功

啟動kafka

查看啟動是否成功

查看topic列表

新起一個終端，作為生產者，用於發送消息，每一行算一條消息，將消息發送到kafka伺服器

新起一個終端作為消費者，接收消息

服務關閉的順序是先kafka，然後zookeeper

再過半小時，你就能明白kafka的工作原理了
Kafka架構原理，也就這么回事！