kafka消息隊列

爲何使用消息隊列
消息隊列的優缺
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) 保證數據的完整性，以及數據丟失的方案

總結 經過以上的學習可使咱們基本瞭解消息隊列的使用。