因為專案中使用了訊息佇列，面試中可能會問到ActiveMQ的相關問題

1. 應用場景
   1.非同步處理：例如簡訊通知、終端狀態推送、App推送、使用者註冊等

   1. 資料同步：業務資料推送同步
      3.重試補償：記賬失敗重試
   2. 系統解耦：通訊上下行、終端異常監控、分散式事件中心
      5.流量消峰：秒殺場景下的下單處理
      6.釋出訂閱：HSF的服務狀態變化通知、分散式事件中心
      7.高併發緩衝：日誌服務、監控上報

2. 概念

   1. Broker
      Broker的概念來自與Apache ActiveMQ，通俗的講就是MQ的伺服器。
3. 訊息的生產者、消費者
   訊息生產者Producer：傳送訊息到訊息佇列。
   訊息消費者Consumer：從訊息佇列接收訊息。

4. 訊息的層次
   (1)Topic 一類主題
   (2)每個訊息包含多個partition, partition儲存到不同的broker上，且每個partition有多個Replica(副本)【Partition 預設每個訊息有2個分割槽，建立Topic可以指定分割槽數，1天有 1億行可以分8個分割槽，如果每天幾十 萬行就一個分割槽吧（這裡指的是kafka）】
   (3)Message 是每個訊息

5. 訊息佇列模式
   1）點到點模式
   訊息生產者生產訊息傳送到queue中，然後訊息消費者從queue中取出並且消費訊息。訊息被消費以後，queue中不再有儲存，所以訊息消費者不可能消費到已經被消費的訊息。Queue支援存在多個消費者，但是對一個訊息而言，只會有一個消費者可以消費。

   2）釋出-訂閱模式
   訊息生產者（釋出）將訊息釋出到topic中，同時有多個訊息消費者（訂閱）消費該訊息。和點對點方式不同，釋出到topic的訊息會被所有訂閱者消費。

   Note : 支援訂閱組的釋出訂閱模式

6. 如果訊息佇列宕機
   持久化（儲存到檔案、儲存到資料庫）， 多個節點來備份

5、kafka 如何實現load balance &HA
1）producer 根據使用者指定的演算法，將訊息傳送到指定的partition
2）存在多個partition，每個partition存在多個副本replica，每個replica分佈在不同的broker節點上
3）每個partition需要選取lead partition，leader partition負責讀寫，並由zookeeper負責fail over 快速失敗
4）通過zookeeper管理broker與consumer的動態加入與離開

6、kafka擴容
當需要增加broker節點時，新增的broker會向zookeeper註冊，而producer及consumer會根據zookeeper上的watcher感知這些變化，並及時作出調整

7、ActiveMq 保證高可用
zookeeper + levelDB