作用
1.應用解耦
2.異步處理
3.流量削峯
4.日誌處理
5.消息通訊
不足
1.系統可用性降低： 系統可用性在某種程度上降低，爲什麼這樣說呢？在加入MQ之前，你不用考慮消息丟失或者說MQ掛掉等等的情況，但是，引入MQ之後你就需要去考慮了！
2.系統複雜性提高： 加入MQ之後，你需要保證消息沒有被重複消費、處理消息丟失的情況、保證消息傳遞的順序性等等問題！
3.一致性問題： 我上面講了消息隊列可以實現異步，消息隊列帶來的異步確實可以提高系統響應速度。但是，萬一消息的真正消費者並沒有正確消費消息怎麼辦？這樣就會導致數據不一致的情況了!
如何保證高可用
集羣 鏡像模式
單純集羣只會有一條queue，多臺機器訪問同一臺機器的queue只是提高了吞吐量。
主從複製(鏡像模式)則會把消息複製到所有或者某幾個queue中，單獨某個或者某幾個掛了不會影響可用性，只是會增加網絡帶寬的壓力和複製時的時間。
如何保證冪等性
給消息一個唯一key
1.數據庫先查詢，存在直接update
2.數據庫設置唯一主鍵
3.redis的set自帶去重
4.其他情況可以存在redis，消費時先查詢redis中是否存在
可靠性
https://blog.csdn.net/alinshen/article/details/80583214
1.生產者弄丟數據
transaction和confirm模式
transaction類似事務，丟失可以回滾，但是會使吞吐量下降
confirm模式用的較多，信道上面發佈的消息都將會被指派一個唯一的ID(從1開始)，一旦消息被投遞到所有匹配的隊列之後，rabbitMQ就會發送一個Ack給生產者(包含消息的唯一ID)，這就使得生產者知道消息已經正確到達目的隊列了.如果rabiitMQ沒能處理該消息，則會發送一個Nack消息給你，你可以進行重試操作。
2.消息隊列丟數據
開啓持久化，和confirm配合使用。
持久化成功後才返回ack。
3.消費者丟數據
自動消息確認改爲手動消息確認
有序性
分析:其實並非所有的公司都有這種業務需求，但是還是對這個問題要有所複習。
回答:針對這個問題，通過某種算法，將需要保持先後順序的消息放到同一個消息隊列中(kafka中就是partition,rabbitMq中就是queue)。然後只用一個消費者去消費該隊列。
有的人會問:那如果爲了吞吐量，有多個消費者去消費怎麼辦？
這個問題，沒有固定回答的套路。比如我們有一個微博的操作，發微博、寫評論、刪除微博，這三個異步操作。如果是這樣一個業務場景，那隻要重試就行。比如你一個消費者先執行了寫評論的操作，但是這時候，微博都還沒發，寫評論一定是失敗的，等一段時間。等另一個消費者，先執行寫評論的操作後，再執行，就可以成功。
總之，針對這個問題，我的觀點是保證入隊有序就行，出隊以後的順序交給消費者自己去保證，沒有固定套路。