1.rabbitMQ
1.1 使用RabbitMQ有什麼好處？
1、 解耦，系統A在程式碼中直接呼叫系統B和系統C的程式碼，如果將來D系統接入，系統A還需要修改程式碼，過於麻煩！
2、 非同步，將訊息寫入訊息佇列，非必要的業務邏輯以非同步的方式執行，加快響應速度
3、 削峰，併發量大的時候，所有的請求直接懟到資料庫，造成資料庫連線異常
1.2 RabbitMQ基本概念
1、 Broker： 簡單來說就是訊息佇列伺服器實體
2、 Exchange： 訊息交換機，它指定訊息按什麼規則，路由到哪個佇列
3、 Queue： 訊息佇列載體，每個訊息都會被投入到一個或多個佇列
4、 Binding： 繫結，它的作用就是把exchange和queue按照路由規則繫結起來
5、 Routing Key： 路由關鍵字，exchange根據這個關鍵字進行訊息投遞
6、 VHost： vhost 可以理解為虛擬 broker ，即 mini-RabbitMQ server。其內部均含有獨立的 queue、exchange 和 binding 等，但最最重要的是，其擁有獨立的許可權系統，可以做到 vhost 範圍的使用者控制。當然，從 RabbitMQ 的全域性角度，vhost 可以作為不同許可權隔離的手段（一個典型的例子就是不同的應用可以跑在不同的 vhost 中）。
7、 Producer： 訊息生產者，就是投遞訊息的程式
8、 Consumer： 訊息消費者，就是接受訊息的程式
9、 Channel： 訊息通道，在客戶端的每個連線裡，可建立多個channel，每個channel代表一個會話任務
由Exchange、Queue、RoutingKey三個才能決定一個從Exchange到Queue的唯一的線路。
1.3 交換器4種型別？
fanout:把所有傳送到該交換器的訊息路由到所有與該交換器繫結的佇列中。
direct:把訊息路由到BindingKey和RoutingKey完全匹配的佇列中。
topic:
匹配規則：
RoutingKey 為一個 點號’.': 分隔的字串。 比如: java.xiaoka.show
BindingKey和RoutingKey一樣也是點號“.“分隔的字串。
BindingKey可使用 _ 和 # 用於做模糊匹配，_匹配一個單詞，#匹配多個或者0個
headers:不依賴路由鍵匹配規則路由訊息。是根據傳送訊息內容中的headers屬性進行匹配。效能差，基本用不到。
1.4 如何避免訊息重複投遞或重複消費?
在訊息生產時，MQ內部針對每條生產者傳送的訊息生成一個inner-msg-id，作為去重和冪等的依據（訊息投遞失敗並重傳），避免重複的訊息進入佇列；在訊息消費時，要求訊息體中必須要有一個bizId（對於同一業務全域性唯一，如支付ID、訂單ID、帖子ID等）作為去重和冪等的依據，避免同一條訊息被重複消費。
這個問題針對業務場景來答分以下幾點：
1、 拿到這個訊息做資料庫的insert操作。然後給這個訊息做一個唯一主鍵，那麼就算出現重複消費的情況，就會導致主鍵衝突，避免資料庫出現髒資料。
2、 拿到這個訊息做Redis的set的操作，因為你無論set幾次結果都是一樣的，set操作本來就算冪等操作。
3、 如果上面兩種情況還不行。準備一個第三方介質,來做消費記錄。以Redis為例，給訊息分配一個全域性id，只要消費過該訊息，將<id,message>以K-V形式寫入Redis。那消費者開始消費前，先去Redis中查詢有沒消費記錄即可。
1.5 如何確保訊息不丟失？
rabbitMQ訊息可能丟失的情況：
1.生產者傳送方發出訊息但沒有進入佇列。
將通道設定成confirm模式（傳送方確認模式），則所有在通道上釋出的訊息都 會被指派一個唯一的ID。一旦訊息被投遞到目的佇列後，或者肖息被寫入磁碟後
（可持久化的訊息），通道會傳送一個確認給生產者（包念肖息唯一ID ）。
2.接收者接到訊息，但處理過程出現錯誤。
當消費者獲取訊息後，會向RabbitMQ傳送回執ACK ,告知訊息我被接收。不 過這種回執ACK分兩種情況:
自動ACK :訊息一旦被接收，消費者自動傳送ACK
如果訊息不太重要，丟失也沒有影響，那麼自動ACK會比較方便
手動ACK :訊息接收後，不會傳送ACK ,需要手動呼叫
-如果訊息非常重要，不容丟失。那麼最好在消費完成後手動ACK ,否則接收訊息 後就自動ACK , RabbitMQ就會把訊息從佇列中刪除。如果此時f肖費者當機,那 麼消，諷丟失了。
3.佇列或者列機。
訊息持久化，當然前提是佇列和交換機必須持久化
1.6 rabbitmq怎麼實現延遲訊息佇列
使用RabbitMQ來實現延遲任務必須先了解RabbitMQ的兩個概念:訊息的TTL 和死信Exchange ,透過這兩者的組合來實現上述需求。如果佇列設定了，訊息也 設定了，那麼會取小的。所以一個訊息如果被路由到不同的佇列中，這個訊息死亡 的時間有可能不一樣（不同的佇列設定）O
延遲任務透過訊息的TTL和Dead Letter Exchange來實現。我們需要建立2個 佇列，一個用於傳送訊息，一個用於訊息過期後的轉發目標佇列。
生產者輸出訊息到Queuel,並且這個訊息是設定有有效時間的，比如3分鐘。 訊息會在Queuel中等待3分鐘，如果沒有消費者收掉的話，它就是被轉發到 Queue2 , Queue2有消費者，收到，處理延遲任務。
1.7 如何解決訊息佇列的延時以及過期失效問題？訊息佇列滿了以後該怎麼處理？有幾百萬訊息持續積壓幾小時，怎麼辦？
訊息積壓處理辦法：臨時緊急擴容：
1、 先修復 consumer 的問題，確保其恢復消費速度，然後將現有 cnosumer 都停掉。
2、 新建一個 topic，partition 是原來的 10 倍，臨時建立好原先 10 倍的 queue 數量。
3、 然後寫一個臨時的分發資料的 consumer 程式，這個程式部署上去消費積壓的資料，消費之後不做耗時的處理，直接均勻輪詢寫入臨時建立好的 10 倍數量的 queue。
4、 接著臨時徵用 10 倍的機器來部署 consumer，每一批 consumer 消費一個臨時 queue 的資料。這種做法相當於是臨時將 queue 資源和 consumer 資源擴大 10 倍，以正常的 10 倍速度來消費資料。
5、 等快速消費完積壓資料之後，得恢復原先部署的架構，重新用原先的 consumer 機器來消費訊息。
6、 MQ中訊息失效：假設你用的是 RabbitMQ，RabbtiMQ 是可以設定過期時間的，也就是 TTL。如果訊息在 queue 中積壓超過一定的時間就會被 RabbitMQ 給清理掉，這個資料就沒了。那這就是第二個坑了。這就不是說資料會大量積壓在 mq 裡，而是大量的資料會直接搞丟。我們可以採取一個方案，就是批次重導，這個我們之前線上也有類似的場景幹過。就是大量積壓的時候，我們當時就直接丟棄資料了，然後等過了高峰期以後，比如大家一起喝咖啡熬夜到晚上12點以後，使用者都睡覺了。這個時候我們就開始寫程式，將丟失的那批資料，寫個臨時程式，一點一點的查出來，然後重新灌入 mq 裡面去，把白天丟的資料給他補回來。也只能是這樣了。假設 1 萬個訂單積壓在 mq 裡面，沒有處理，其中 1000 個訂單都丟了，你只能手動寫程式把那 1000 個訂單給查出來，手動發到 mq 裡去再補一次。
mq訊息佇列塊滿了：
如果訊息積壓在 mq 裡，你很長時間都沒有處理掉，此時導致 mq 都快寫滿了，咋辦？這個還有別的辦法嗎？沒有，誰讓你第一個方案執行的太慢了，你臨時寫程式，接入資料來消費，消費一個丟棄一個，都不要了，快速消費掉所有的訊息。然後走第二個方案，到了晚上再補資料吧。
1.8 message 被可靠持久化的條件是 queue 和 exchange 具有durable 屬性，同時 message 具有 persistent 屬性才行？
binding 關係可以表示為 exchange – binding – queue 。從文件中我們知道，若要求投遞的 message 能夠不丟失，要求 message 本身設定 persistent 屬性，要求 exchange和 queue 都設定 durable 屬性。
其實這問題可以這麼想，若 exchange 或 queue 未設定durable 屬性，則在其 crash 之後就會無法恢復，那麼即使 message 設定了 persistent 屬性，仍然存在 message 雖然能恢復但卻無處容身的問題；同理，若 message 本身未設定persistent 屬性，則 message 的持久化更無從談起。
1.9 RabbitMQ的叢集模式有幾種？
RabbitMQ 是比較有代表性的，因為是基於主從（非分散式）做高可用性的，我們就以 RabbitMQ 為例子講解第一種 MQ 的高可用性怎麼實現。RabbitMQ 有三種模式：單機模式、普通叢集模式、映象叢集模式。
1、 單機模式，就是 Demo 級別的，一般就是你本地啟動了玩玩兒的?，沒人生產用單機模式
2、 普通模式：以兩個節點（rabbit01，rabbit02）為例來進行說明，對於Queue來說，訊息實體只存在於其中一個節點rabbit01（或者rabbit02），rabbit01和rabbit02兩個節點僅有相同的後設資料，即佇列結構。當訊息進入rabbit01節點的Queue後，consumer從rabbit02節點消費時，RabbitMQ會臨時在rabbit01，rabbit02間進行訊息傳輸，把A中的訊息實體取出並經過B傳送給consumer，所以consumer應儘量連線每一個節點，從中取訊息。即對於同一個邏輯佇列，要在多個節點建立物理Queue。否則無論consumer連rabbit01或rabbit02，出口總在rabbit01，會產生瓶頸。當rabbit01節點故障後，rabbit02節點無法取到rabbit01節點中還未消費的訊息實體。如果做了訊息持久化，那麼等到rabbit01節點恢復，然後才可被消費。如果沒有訊息持久化，就會產生訊息丟失的現象。
3、 映象模式：把需要的佇列做成映象佇列，存在與多個節點屬於RabibitMQ的HA方案，該模式解決了普通模式中的問題，其實質和普通模式不同之處在於，訊息體會主動在映象節點間同步，而不是在客戶端取資料時臨時拉取，該模式帶來的副作用也很明顯，除了降低系統效能外，如果映象佇列數量過多，加之大量的訊息進入，叢集內部的網路頻寬將會被這種同步通訊大大消耗掉，所以在對可靠性要求比較高的場合中適用
2.kafka
2.1 概念
高可用，幾乎所有相關的開源軟體都支援，滿足大多數的應用場景，尤其是大資料和流計算領域，
- Kafka高效，可伸縮，訊息持久化。支援分割槽、副本和容錯。
- 對批處理和非同步處理做了大量的設計，因此Kafka可以得到非常高的效能。
- 每秒處理幾十萬非同步訊息訊息，如果開啟了壓縮，最終可以達到每秒處理2000w訊息的級別。
- 但是由於是非同步的和批處理的，延遲也會高，不適合電商場景。
2.2 什麼是kafka
- Producer API：允許應用程式將記錄流釋出到一個或多個Kafka主題。
- Consumer API：允許應用程式訂閱一個或多個主題並處理為其生成的記錄流。
- Streams API：允許應用程式充當流處理器，將輸入流轉換為輸出流。
訊息 Message
Kafka的資料單元稱為訊息。可以把訊息看成是資料庫裡的一個“資料行”或一條“記錄”。
批次
為了提高效率，訊息被分批寫入Kafka。提高吞吐量卻加大了響應時間。
主題Topic
透過主題進行分類，類似資料庫中的表。
分割槽 Partition
Topic可以被分成若干分割槽分佈於kafka叢集中，方便擴容
單個分割槽內是有序的，partition設定為一才能保證全域性有序
副本 Replicas
每個主題被分為若干個分割槽，每個分割槽有多個副本。
生產者 Producer
生產者在預設情況下把訊息均衡地分佈到主題的所有分割槽上：
- 直接指定訊息的分割槽
- 根據訊息的key雜湊取模得出分割槽
- 輪詢指定分割槽。
消費者 Comsumer
消費者透過偏移量來區分已經讀過的訊息，從而消費訊息。把每個分割槽最後讀取的訊息偏移量儲存在Zookeeper 或Kafka上，如果消費者關閉或重啟，它的讀取狀態不會丟失。
消費組 ComsumerGroup
消費組保證每個分割槽只能被一個消費者使用，避免重複消費。如果群組內一個消費者失效，消費組裡的其他消費者可以接管失效消費者的工作再平衡，重新分割槽。
節點 Broker
連線生產者和消費者，單個broker可以輕鬆處理數千個分割槽以及每秒百萬級的訊息量。
- broker接收來自生產者的訊息，為訊息設定偏移量，並提交訊息到磁碟儲存。
- broker為消費者提供服務，響應讀取分割槽的請求，返回已經提交到磁碟上的訊息。
叢集
每隔分割槽都有一個首領，當分割槽被分配給多個broker時，會透過首領進行分割槽複製。
生產者 Offset
訊息寫入的時候，每一個分割槽都有一個offset，即每個分割槽的最新最大的offset。
消費者 Offset
不同消費組中的消費者可以針對一個分割槽儲存不同的Offset，互不影響。
LogSegment
- 一個分割槽由多個LogSegment組成，
- 一個LogSegment由.log .index .timeindex組成
- .log追加是順序寫入的，檔名是以檔案中第一條message的offset來命名的
- .Index進行日誌刪除的時候和資料查詢的時候可以快速定位。
- .timeStamp則根據時間戳查詢對應的偏移量。
2.3 優點和應用場景
優點：
- 高吞吐量：單機每秒處理幾十上百萬的訊息量。即使儲存了TB及訊息，也保持穩定的效能。
- 零複製 減少核心態到使用者態的複製，磁碟透過sendfile實現DMA 複製Socket buffer
- 順序讀寫 充分利用磁碟順序讀寫的超高效能
- 頁快取mmap，將磁碟檔案對映到記憶體, 使用者透過修改記憶體就能修改磁碟檔案。
- 高效能：單節點支援上千個客戶端，並保證零停機和零資料丟失。
- 持久化：將訊息持久化到磁碟。透過將資料持久化到硬碟以及replication防止資料丟失。
- 分散式系統，易擴充套件。所有的元件均為分散式的，無需停機即可擴充套件機器。
- 可靠性 - Kafka是分散式，分割槽，複製和容錯的。
- 客戶端狀態維護：訊息被處理的狀態是在Consumer端維護，當失敗時能自動平衡。
應用場景：
- 日誌收集：用Kafka可以收集各種服務的Log，透過大資料平臺進行處理；
- 訊息系統：解耦生產者和消費者、快取訊息等；
- 使用者活動跟蹤：Kafka經常被用來記錄Web使用者或者App使用者的各種活動，如瀏覽網頁、搜尋、點選等活動，這些活動資訊被各個伺服器釋出到Kafka的Topic中，然後消費者透過訂閱這些Topic來做運營資料的實時的監控分析，也可儲存到資料庫；
2.4 生產消費基本流程
1.Producer建立時，會建立一個Sender執行緒並設定為守護執行緒。
2.生產的訊息先經過攔截器->序列化器->分割槽器，然後將訊息快取在緩衝區。
3.批次傳送的條件為：緩衝區資料大小達到batch.size或者linger.ms達到上限。
4.批次傳送後，發往指定分割槽，然後落盤到broker；
- acks=0只要將訊息放到緩衝區，就認為訊息已經傳送完成。
- acks=1表示訊息只需要寫到主分割槽即可。在該情形下，如果主分割槽收到訊息確認之後就當機了，而副本分割槽還沒來得及同步該訊息，則該訊息丟失。
- acks=all （預設）首領分割槽會等待所有的ISR副本分割槽確認記錄。該處理保證了只要有一個ISR副本分割槽存活，訊息就不會丟失。
5.如果生產者配置了retrires引數大於0並且未收到確認，那麼客戶端會對該訊息進行重試。
6.落盤到broker成功，返回生產後設資料給生產者。
2.5 leader 選舉
- Kafka會在Zookeeper上針對每個Topic維護一個稱為ISR（in-sync replica）的集合；
- 當集合中副本都跟Leader中的副本同步了之後，kafka才會認為訊息已提交；
- 只有這些跟Leader保持同步的Follower才應該被選作新的Leader；
- 假設某個topic有N+1個副本，kafka可以容忍N個伺服器不可用，冗餘度較低 如果ISR中的副本都丟失了，則：
- 可以等待ISR中的副本任何一個恢復，接著對外提供服務，需要時間等待；
- 從OSR中選出一個副本做Leader副本，此時會造成資料丟失；
副本訊息同步
首先，Follower 傳送 FETCH 請求給 Leader。接著，Leader 會讀取底層日誌檔案中的消 息資料，再更新它記憶體中的 Follower 副本的 LEO 值，更新為 FETCH 請求中的 fetchOffset 值。最後，嘗試更新分割槽高水位值。Follower 接收到 FETCH 響應之後，會把訊息寫入到底層日誌，接著更新 LEO 和 HW 值。
相關概念：LEO和HW。
- LEO：即日誌末端位移(log end offset)，記錄了該副本日誌中下一條訊息的位移值。如果LEO=10，那麼表示該副本儲存了10條訊息，位移值範圍是[0, 9]。
- HW：水位值HW（high watermark）即已備份位移。對於同一個副本物件而言，其HW值不會大於LEO值。小於等於HW值的所有訊息都被認為是“已備份”的（replicated）。
Rebalance
- 組成員數量發生變化
- 訂閱主題數量發生變化
- 訂閱主題的分割槽數發生變化
leader選舉完成後，當以上三種情況發生時，Leader根據配置的RangeAssignor開始分配消費方案，即哪個consumer負責消費哪些topic的哪些partition。一旦完成分配，leader會將這個方案封裝進SyncGroup請求中發給coordinator，非leader也會發SyncGroup請求，只是內容為空。coordinator接收到分配方案之後會把方案塞進SyncGroup的response中發給各個consumer。這樣組內的所有成員就都知道自己應該消費哪些分割槽了。
分割槽分配演算法 RangeAssignor
- 原理是按照消費者總數和分割槽總數進行整除運算平均分配給所有的消費者；
- 訂閱Topic的消費者按照名稱的字典序排序，分均分配，剩下的字典序從前往後分配；
2.6 冪等性
保證在訊息重發的時候，消費者不會重複處理。即使在消費者收到重複訊息的時候，重複處理，也要保證最終結果的一致性。所謂冪等性，數學概念就是：f(f(x)) = f(x)
新增唯一ID，類似於資料庫的主鍵，用於唯一標記一個訊息。
ProducerID：#在每個新的Producer初始化時，會被分配一個唯一的PIDSequenceNumber：#對於每個PID傳送資料的每個Topic都對應一個從0開始單調遞增的SN值
2.7 如何保證資料不會丟失
- 生產者生產訊息可以透過comfirm配置ack=all解決；
- Broker同步過程中leader當機可以透過配置ISR副本+重試解決；
- 消費者丟失可以關閉自動提交offset功能，系統處理完成時提交offset；
2.8 如何解決積壓消費
- 修復consumer，使其具備消費能力，並且擴容N臺；
- 寫一個分發的程式，將Topic均勻分發到臨時Topic中；
- 同時起N臺consumer，消費不同的臨時Topic；
如何避免訊息積壓
- 提高消費並行度
- 批次消費
- 減少元件IO的互動次數
- 優先順序消費
2.9 如何設計訊息佇列
需要支援快速水平擴容，broker+partition，partition放不同的機器上，增加機器時將資料根據topic做遷移，分散式需要考慮一致性、可用性、分割槽容錯性
- 一致性：生產者的訊息確認、消費者的冪等性、Broker的資料同步；
- 可用性：資料如何保證不丟不重、資料如何持久化、持久化時如何讀寫；
- 分割槽容錯：採用何種選舉機制、如何進行多副本同步；
- 海量資料：如何解決訊息積壓、海量Topic效能下降；
效能上，可以借鑑時間輪、零複製、IO多路複用、順序讀寫、壓縮批處理。
3.rocketMQ
3.1 RocketMQ由哪些角色組成，每個角色作用和特點是什麼？
3.2 RocketMQ Broker中的訊息被消費後會立即刪除嗎？
不會，每條訊息都會持久化到CommitLog中，每個Consumer連線到Broker後會維持消費進度資訊，當有訊息消費後只是當前Consumer的消費進度（CommitLog的offset）更新了。
3.3 消費訊息是push還是pull？
RocketMQ沒有真正意義的push，都是pull，雖然有push類，但實際底層實現採用的是長輪詢機制，即拉取方式
為什麼要主動拉取訊息而不使用事件監聽方式？
事件驅動方式是建立好長連線，由事件（傳送資料）的方式來實時推送。
如果broker主動推送訊息的話有可能push速度快，消費速度慢的情況，那麼就會造成訊息在consumer端堆積過多，同時又不能被其他consumer消費的情況。而pull的方式可以根據當前自身情況來pull，不會造成過多的壓力而造成瓶頸。所以採取了pull的方式。
3.4 RocketMQ的事務訊息是如何實現的？
RocketMQ事務訊息的實現機制：
1、半訊息機制： 首先傳送半訊息到訊息伺服器，如果執行本地事務成功，則提交訊息，否則回滾。
2、本地事務執行： 訊息傳送者在傳送半訊息後執行本地事務。
3、狀態檢查： 訊息伺服器會定期檢查半訊息的狀態。
4、事務回查： 如果訊息狀態不確定，訊息伺服器會向傳送者回查事務狀態，確保訊息最終一致性。
3.5 RocketMQ中的訊息過濾功能是如何實現的？
RocketMQ訊息過濾功能的實現方式：
1、標籤過濾： 生產者在傳送訊息時設定標籤，消費者透過指定標籤來選擇性消費訊息。
2、SQL92過濾： 支援基於SQL92標準的過濾表示式，允許在消費端進行更復雜的訊息過濾。
3、客戶端過濾： 消費者客戶端在接收到訊息後，可以根據自定義邏輯進行過濾處理。
4、效能最佳化： 透過過濾減少網路傳輸的資料量，提高整體效能和效率。
3.6 RocketMQ如何保證訊息的可靠傳輸？
保證RocketMQ訊息可靠傳輸的機制：
1、訊息持久化： 所有訊息在伺服器端被持久化儲存，確保不會因伺服器故障而丟失。
2、同步雙寫： 在主備Broker中同步雙寫訊息，提高資料的可靠性。
3、確認機制： 消費者消費訊息後，需要向Broker傳送確認，未確認的訊息會被重新投遞。
4、事務訊息支援： 提供事務訊息機制，保證本地事務和訊息傳送的原子性。
3.7 rocketMQ和kafka元件的區別
適用場景
Kafka
Kafka最初由LinkedIn開發，主要用於處理大規模的日誌資料和實時資料流。它適合以下場景：
日誌收集：Kafka可以高效地收集、儲存和處理大規模日誌資料。
實時資料流處理：Kafka可以與Apache Storm、Apache Flink等實時處理框架結合使用，實現實時資料流的處理和分析。
資料管道：Kafka可以作為不同系統之間的資料管道，實現資料的傳輸和同步。
RocketMQ
RocketMQ由阿里巴巴開發，主要用於解決分散式系統中的訊息傳遞問題。它適合以下場景：
分散式事務處理：RocketMQ支援分散式事務，適合處理需要保證一致性的業務場景。
訊息推送：RocketMQ支援多種訊息推送模式，包括叢集消費和廣播消費，適合需要向多個消費者推送訊息的場景。
延遲訊息處理：RocketMQ支援延遲訊息，適合需要延遲處理的業務場景。
架構設計
Kafka
Kafka採用釋出-訂閱模式，主要包括生產者、消費者和Broker三個元件。
Broker：Kafka的Broker採用無中心設計，可以水平擴充套件。多個Broker組成一個Kafka叢集，共同承擔資料的儲存和處理任務。
Topic：Kafka中的資料以Topic為單位進行劃分，每個Topic可以有多個Partition。Partition是Kafka實現分散式儲存和並行處理的關鍵。
生產者和消費者：生產者負責向Kafka傳送訊息，消費者負責從Kafka接收訊息並進行處理。生產者和消費者透過Zookeeper進行協調和管理。
RocketMQ
RocketMQ採用主從架構，主要包括生產者、消費者、NameServer和Broker四個元件。
Broker：RocketMQ的Broker分為主Broker和從Broker，主從之間透過同步複製實現資料一致性。多個Broker組成一個RocketMQ叢集，共同承擔資料的儲存和處理任務。
Topic：RocketMQ中的資料同樣以Topic為單位進行劃分，每個Topic可以有多個Queue。Queue是RocketMQ實現分散式儲存和並行處理的關鍵。
生產者和消費者：生產者負責向RocketMQ傳送訊息，消費者負責從RocketMQ接收訊息並進行處理。生產者和消費者透過NameServer進行協調和管理。
效能
Kafka
Kafka在效能方面具有優勢，主要體現在以下幾個方面：
資料吞吐量：Kafka具有極高的資料吞吐量，可以達到每秒數百萬條訊息的處理能力。
延遲：Kafka的延遲較低，可以在毫秒級別內完成訊息的傳輸和處理。
資料型別：Kafka支援多種資料型別，包括文字、二進位制資料和JSON等，可以滿足不同場景的需求。
RocketMQ
RocketMQ在效能方面同樣表現出色，主要體現在以下幾個方面：
資料吞吐量：RocketMQ的資料吞吐量同樣很高，可以達到每秒數十萬條訊息的處理能力。
延遲：RocketMQ的延遲也較低，可以在毫秒級別內完成訊息的傳輸和處理。
資料型別：RocketMQ同樣支援多種資料型別，包括文字、二進位制資料和JSON等。
可靠性
Kafka
Kafka在可靠性方面採取了多種措施：
資料備份：Kafka的每個Partition都有多個副本，可以在一定程度上防止資料丟失。
主從機制：Kafka的Broker之間採用主從複製機制，保證資料的一致性。
高可用性：Kafka的Broker可以水平擴充套件，透過增加Broker的數量可以提高系統的可用性。此外，Zookeeper作為協調中心，也提高了系統的可靠性。
RocketMQ
RocketMQ在可靠性方面同樣採取了多種措施：
資料備份：RocketMQ的每個Queue都有多個副本，可以在一定程度上防止資料丟失。
高可用性：主從Broker之間採用同步複製機制，保證資料的一致性。當主Broker出現故障時，從Broker可以自動切換為主Broker，保證系統的可用性。此外，透過增加Broker的數量也可以提高系統的可用性。NameServer作為協調中心，也提高了系統的可靠性。當某個NameServer出現故障時，其他NameServer可以接管它的任務，保證系統的正常執行。生產者和消費者在傳送和接收訊息時會自動選擇可用的Broker和NameServer進行操作提高了系統的可靠性。生產者和消費者在傳送和接收訊息時會自動選擇可用的Broker和NameServer進行操作避免了單點故障的風險。同時RocketMQ還支援事務訊息保證了分散式事務的一致性。
4.mqtt相關
4.1 MQTT是什麼？
MQTT（Message Queuing Telemetry Transport，訊息佇列遙測傳輸協議）是一種輕量級的、基於釋出/訂閱模式的通訊協議，由IBM的Andy Stanford-Clark和Cirrus Link的Arlen Nipper於1999年設計。它被設計用於有限的頻寬和不穩定網路環境中，非常適合物聯網（IoT）裝置之間的通訊。
MQTT協議的主要特點包括：
輕量級：MQTT的訊息頭部很小，可以減少裝置的頻寬和功耗，適合在嵌入式裝置上使用。
釋出/訂閱模式：允許一個裝置透過釋出訊息到一個主題，同時多個裝置可以訂閱這個主題來接收訊息。
可靠性：支援三種不同的服務質量（QoS）級別，確保訊息的可靠傳輸。
非同步通訊：釋出者和訂閱者不需要同時線上，訊息會被儲存在伺服器上，直到訂閱者成功接收。
簡單易用：協議簡單，易於實現，支援多種程式語言。
MQTT廣泛應用於物聯網、行動通訊、智慧家居、智慧電網、遠端監控和汽車等多個領域。
4.2 它與HTTP有什麼不同？
MQTT（Message Queuing Telemetry Transport）協議和HTTP（Hypertext Transfer Protocol）協議都是網路協議，但它們在設計理念、使用場景和效能特點上有著顯著的不同：
通訊模式：
MQTT基於釋出/訂閱模式，允許一個裝置（釋出者）傳送訊息到主題，而多個裝置（訂閱者）可以訂閱這些主題來接收訊息。
HTTP基於請求/響應模式，客戶端傳送請求到伺服器，伺服器返回響應。
用途和場景：
MQTT專為物聯網（IoT）設計，適用於頻寬有限、延遲敏感和不穩定的網路環境，如行動通訊、嵌入式裝置等。
HTTP主要用於網頁瀏覽、檔案傳輸和API服務，適用於穩定、高頻寬的網路環境。
訊息大小和開銷：
MQTT協議頭很小，訊息開銷低，適合傳輸小訊息。
HTTP協議頭相對較大，適合傳輸較大資料，如檔案、圖片等。
服務質量（QoS）：
MQTT支援三種不同的服務質量級別，可以根據需要選擇不同級別的訊息傳遞可靠性。
HTTP沒有內建的訊息服務質量級別，但可以透過實現特定的錯誤處理和重試機制來提高可靠性。
連線模型：
MQTT保持長連線，客戶端與伺服器之間保持持久的會話，直到客戶端顯式斷開連線。
HTTP使用短連線，每個請求完成後連線通常會被關閉，雖然HTTP/1.1支援持久連線（keep-alive），但每次請求/響應互動後，連線可能會處於空閒狀態。
實時性：
MQTT設計用於實時通訊，延遲低，適合需要即時響應的應用。
HTTP的實時性不如MQTT，儘管有WebSocket等協議可以提供實時通訊功能，但HTTP本身更適合非實時應用。
資源消耗：
MQTT由於輕量級設計，對裝置資源的要求較低。
HTTP通常需要更多的資源，尤其是在移動或嵌入式裝置上。
總的來說，MQTT和HTTP各有優勢，適用於不同的應用場景。在選擇合適的協議時，需要根據應用的需求、網路環境和裝置能力來決定。
4.3 MQTT協議的優點和缺點是什麼？
MQTT協議的優點和缺點如下：
優點：
1.輕量級：MQTT協議的設計非常簡潔，訊息頭部很小，這使得它非常適合在頻寬有限、計算能力有限的裝置上使用，如物聯網裝置。
2.低延遲：MQTT協議支援實時通訊，延遲低，適合需要快速響應的應用場景。
3.支援多種質量服務（QoS）級別：MQTT提供三種不同級別的訊息傳遞可靠性，可以根據應用的需求選擇適當的QoS級別。
4.高效的釋出/訂閱模型：MQTT使用釋出/訂閱模型，允許一個訊息被多個訂閱者接收，這減少了網路流量和裝置的資源消耗。
5.良好的網路適應性：MQTT協議可以在不穩定或間歇性的網路環境中工作，如行動網路或衛星通訊。
6.支援持久會話：MQTT客戶端可以與伺服器建立持久會話，即使客戶端斷開連線，伺服器也會儲存其訂閱資訊和未接收的訊息，直到客戶端重新連線。
缺點：
1.安全性問題：雖然MQTT支援加密和認證，但預設情況下，它可能不夠安全。需要在傳輸層使用TLS/SSL或其他安全措施來增強安全性。
2.不適合大量資料傳輸：MQTT協議不適合傳輸大量資料，因為它設計用於小型、頻繁的訊息傳遞。
3.依賴於中央代理：MQTT使用中央代理（Broker）來處理訊息的釋出和訂閱，這可能導致單點故障和效能瓶頸。
4.實現複雜性：儘管MQTT協議本身簡單，但在某些平臺上實現客戶端和服務端可能需要較多的開發工作。
5.有限的客戶端支援：雖然MQTT在物聯網裝置中廣泛使用，但在傳統的桌面或移動應用中，HTTP可能是更常見的通訊協議。
在選擇使用MQTT協議時，需要根據應用的具體需求、網路環境和裝置能力來權衡其優缺點。
4.4 MQTT中有哪些訊息質量（Qos）等級，並解釋它們的含義？
MQTT協議定義了三種訊息質量等級（Quality of Service, QoS），用於指定訊息傳遞的可靠性。這些QoS等級如下：
QoS 0 - 至多一次（At Most Once）：
這是最低的QoS等級，訊息最多被傳遞一次。
釋出者將訊息傳送給代理（Broker），不會等待任何確認。
如果訂閱者線上並能夠接收訊息，它將收到訊息；否則，訊息可能會丟失。
這個等級適用於可以容忍訊息丟失的場景，例如實時監控或感測器資料，其中最新的資料比舊資料更重要。
QoS 1 - 至少一次（At Least Once）：
在這個等級，訊息至少被傳遞一次。
釋出者傳送訊息後，會等待代理的確認（PUBACK）。
如果代理沒有收到確認，它會嘗試重新傳送訊息。
訂閱者在接收到訊息後，需要向代理傳送確認（PUBACK）。
這個等級適用於不能容忍訊息丟失，但可以容忍重複傳遞的場景。
QoS 2 - 正好一次（Exactly Once）：
這是最高等級的QoS，確保訊息精確地被傳遞一次。
釋出者傳送訊息，並等待代理的確認（PUBREC）。
代理在收到訊息後，傳送PUBREC給釋出者，並等待發布者的響應（PUBREL）。
釋出者收到PUBREC後，傳送PUBREL給代理。
代理收到PUBREL後，傳送最終的確認（PUBCOMP）給釋出者。
訂閱者在接收到訊息後，也需要向代理傳送確認（PUBACK）。
這個等級適用於那些需要確保訊息不丟失、不重複傳遞的重要資料，如計費系統或財務交易。
選擇合適的QoS等級取決於應用程式的具體需求和網路環境。例如，在穩定的網路環境中，QoS 0可能是足夠的，因為它具有最低的延遲和開銷。而在不穩定的網路環境中，或者當訊息的可靠性非常重要時，QoS 1或QoS 2可能是更好的選擇。
4.5 能給出一些使用MQTT的應用場景嗎
MQTT（Message Queuing Telemetry Transport）協議由於其輕量級、低延遲和可靠性的特點，被廣泛應用於多種物聯網（IoT）和移動應用場景。以下是一些典型的MQTT應用場景：
物聯網裝置通訊：
MQTT被廣泛用於物聯網裝置之間的通訊，如感測器網路、智慧家居裝置、工業控制系統等。
它允許這些裝置以極低的頻寬和功耗傳送和接收訊息。
移動應用：
MQTT可以用於移動應用的訊息推送，例如，即時訊息、通知、天氣更新等。
它支援斷開連線的裝置在重新連線時接收離線訊息。
智慧城市：
在智慧城市應用中，MQTT用於連線各種裝置和系統，如交通訊號燈、監控攝像頭、環境監測站等。
它幫助實現實時資料收集和智慧決策支援。
遠端監控和管理：
MQTT用於遠端監控和管理系統，如太陽能發電站、風力發電機組、遠端醫療裝置等。
它允許實時監控裝置狀態並遠端控制裝置。
車輛和運輸：
在車聯網（V2X）通訊中，MQTT可以用於車輛之間的通訊，以及車輛與基礎設施之間的通訊。
它支援實時交通訊息交換、車輛診斷資料傳輸等。
農業：
MQTT在精準農業中用於連線農田感測器、灌溉系統、無人機等，以監控作物生長環境和最佳化農業管理。
金融服務：
MQTT可以用於金融交易系統、股票市場資料推送、實時匯率更新等金融服務應用。
能源管理：
在智慧電網和能源管理系統中，MQTT用於監控能源消耗、控制智慧電錶和電網裝置。
零售和物流：
MQTT可以用於零售和物流行業，用於庫存管理、物流跟蹤、自動化倉庫系統等。
智慧家居：
MQTT在智慧家居裝置中用於控制和監控，如燈光、恆溫器、安全系統等。
這些應用場景展示了MQTT協議的多樣性和靈活性，使其成為物聯網和移動網際網路領域的理想選擇。