### Spring IOC如何管理Bean之間的依賴關系，怎么樣避免循環依賴 ### SpringBean創建過程中的設計模式？ ### 用MQ采集消息的時候，有沒有做消息重復消費處理？怎么做的？ > 生產者在向Kafka寫數據時，每條消息會有一個offset，表示消息寫入順序的序號。當消費者消費后，**每隔一段時間會把自己已消費消息的offset通過Zookeeper提交給Kafka**，告知Kafka自己offset的位置。這樣一來，如果消費者重啟，則會從Kafka記錄的offset之后的數據開始消費，從而避免重復消費。 #### 發生重復消費后，如何**保證消息消費時的冪等性** 1. 向數據庫insert數據時，先**根據主鍵查詢，若數據存在則不insert，改為update** 2. 向Redis中寫數據可以用**set去重，天然保證冪等性** 3. 生產者發送每條消息時，增加一個全局唯一id（類似訂單id），消費者消費到時，先**根據這個id去Redis中查詢是否消費過該消息**。如果沒有消費過，就處理，將id寫入Redis；如果消費過了，那么就不處理，保證不重復處理相同消息。 4. 基于數據庫的**唯一鍵約束**來保證不會插入重復的數據，當消費者企圖插入重復數據到數據庫時，會報錯。 總結： - Kafka采取類似**斷點續傳**的策略保證消息不被重復消費。具體是通過**每隔一段時間把已消費消息的offset通過Zookeeper提交給Kafka**實現的。 - 但是當消費者**處理完成但尚未提交offset**的時間段宕機或重啟等意外情況發生時，還是可能出現消息被重復消費。 - 保證消息不被重復消費（保證消息消費時的冪等性）其實是保證數據庫中數據的正確性。幾種保證系統冪等性的思路：通過主鍵查詢，若存在則update；Redis天然set去重；根據全局id查詢，若已消費則不處理；唯一鍵約束保證不插入重復數據等。 ### RocketMQ 1. commitLog是什么？ > commtLog的存儲其實是分多層的，commitLog -> mappedFileQueue -> mappedFile，其中真正存儲數據的是mappedFile。 2. 為什么commitlog每個文件大小是1G > rocketMQ主要通過MappedByteBuffer對文件進行讀寫操作。MappedByteBuffer這種內存映射的方式有幾個限制，其中之一是一次只能映射1.5~2G 的文件至用戶態的虛擬內存，這也是為何RocketMQ默認設置單個CommitLog日志數據文件為1G的原因了 3. `nameServer`的作用是什么 > 主要功能是為整個MQ集群提供服務協調與治理，具體就是記錄維護Topic、Broker的信息，及監控Broker的運行狀態 > > Name Server是一個幾乎無狀態節點，可集群部署，節點之間無任何信息同步 4. 與`zookeeper`的區別 > NameServer是沒有leader和follower區別的，不進行數據同步，通過Broker輪訓修改信息.