摘要：為什么使用消息隊列消息隊列的優缺優點解耦異步消峰缺點系統的可用性降低，系統引入的外部依賴越多，越容易掛掉系統復雜性提高數據一致性問題常用消息隊列的優缺點技術非常成熟，但是偶爾會出現較低概率的丟失消息，而且現在社區以及國內應用都越來越少社區相

為什么使用消息隊列
消息隊列的優缺
1優點

（1） 解耦

（2） 異步

（3） 消峰

2 缺點

（1）系統的可用性降低，系統引入的外部依賴越多，越容易掛掉

（2）系統復雜性提高

（3）數據一致性問題

常用消息隊列的優缺點

（1）activeMq 技術非常成熟，但是偶爾會出現較低概率的丟失消息，而且現在社區以及國內應用都越來越少

（2）rabbitMQ 社區相對活躍，吞吐量是萬級別，而且開元，性能極好，但是erlang語言阻止了大量的Java程序員深入研究和掌握他，對公司而言幾乎是不可控的

（3）rocketMq 10萬級別的，rockectMq 也是可以支持高吞吐的一個MQ，topic可以達到幾百，幾千的級別，可用性非常的高，分布式架構，但是社區有黃的風險。

（4）kafka 特點就是僅僅提供較少的核心功能，但是提供較高的吞吐量，極高的可用性能，而且分布式可以隨意的擴展，但是沒有重復消費，會對大數據產生一點點影響，特別適合大數據領域的實時計算，日志采集等場景，社區活躍度很高

消息隊列的高可用

（1）kafka是天然的分布式消息隊列，就是說一個topic的數據，是分散在多個機器上的，每一個機器就放其中的一部分數據，kafka0.8以后，提供了HA機制，就是replica的副本機制，，每一個partition的數據都會同步到其他的機器上，形成自己的多個replica副本，然后所有的replica就會選舉一個leader出來，那么生產者和消費者都跟這個leader打交道，然后其他的replica就是flower，leader會負責將數據同步到follower中去，讀的時候直接讀leader上的數據就行了。這么搞，就有所謂的高可用性了，因為如果摸一個broke硯機了，那么其他的機器上有他的副本，如果時某個partition的leader出現了問題，那么follower就會選舉為新的leader，大家就可以繼續讀寫那個新的leader即可，這就是所謂的高可用性。

如何保證消息不被重復消費（如何保證消息的消費時的冪等性）

kafka有個offset的概念，就是每次每個消息寫進去，都有一個offset，代表他的序號，然后，consumer 消費了數據之后，每隔一段時間，就會把自己消費了的offset提交一下，代表我已經消費過了，下一次要是重啟啥的，就會繼續從上一次的消費的offset來繼續消費，但是假如，有時候 重啟系統，就會導致有些還沒有來的及處理的消息沒有offset，就會導致有些消息會在消費一次。其實重復消費并沒有什么，最重要的是保證冪等性，如何消除冪等性的問題

（1）比如，你拿數據庫里面的數據，你先跟住主鍵進行查詢一下，如果數據都有了，你就不需要插入了，直接update一下就好了

（2）比如你是寫Redis，那就沒有問題了，反正每次都是set，天然冪等性

（3）可以使用唯一鍵進行約束

如何保證數據的可靠性傳輸

（1）消費端能丟了數據

    就是說消費者消費了消費到消息，然后消費者那邊自動提交了offset，讓kafka以為你已經消費了數據，但是其實你這邊還沒有處理，就已經掛了，那么只需要關閉自動提交offset，在處理完成以后自己手動的提交offset，就可以保證數據不會丟失了，但是此時會存在重復消費的問題，這時，只需要保證冪等問題就好了。
    

（2）kafka弄丟了數據

    這是一個比較常見的問題，就是kafka某個broke巖機，然后重新選舉某一個partition的leader時，假如此時其他的follower還有一些數據還沒有同步，結果leader就已經掛了，然后選舉某一個follower成leader后，就會少了一批數據。此時，我們要給topic設置4個參數就好了，
    
    *1 給topic設置replication.factor參數，這個值必須大于1，要求每一個partition必須至少2個副本  ？？
    
    *2 在producer端設置ACKs=all：這是要求每條數據，都必須是寫入replica之后，才能認為是寫入成功了
    
    *3 在producer端設置retries=max，這就要求一旦寫入失敗，就無限重試，卡在這里了。
    
    *4 在kafka服務器設置min.insync.replicas參數，這個值必須大于1，這是要求一個leader至少感知到有至少一個follower還和自己進行聯系，沒有掉隊，這樣才能保證leader掛了，還有一個follower
    

如何保證數據的有序性

  一個topic，一個partition，一個consumer，內部線程消費，寫N個內存queue，然后N個線程分別消費一個內存queue即可
  

如何解決消息隊列中的時效性問題，消息對列中消息滿了怎么辦

   擴容
   
    （0）將現有的consumer停掉
   
    （1）新建一個topic，partition是原來的10倍，臨時建好原先10倍或20倍的queue數量
    
    （2）寫一些臨時的分發數據的程序，將程序部署到上面進行消費
    

設計一個MQ系統架構注意點

    （1） 系統可伸縮，就是想要擴容的時候能夠擴容，我們可以采用分布式架構
    
    （2） MQ的數據怎樣落地到磁盤
    
    （3） MQ的可用性
    
     (4) 保證數據的完整性，以及數據丟失的方案
     

總結 通過以上的學習可以使我們基本了解消息隊列的使用。