ActiveMQ、RocketMQ、RabbitMQ、Kafka區別

一、三大應用場景（優點）
解耦、異步、削峯
1、解耦：只需要將消息寫入消息隊列，需要消息的去消息隊列中訂閱就好
2、異步：一些非必要的邏輯可以採用異步來完成，從而提升響應速度
3、削峯：某個時間段併發量特別大的時候可以將消息發送到消息隊列中，然後從消息隊列中慢慢拉取進行消費
二、消息隊列的缺點
1、系統可用性降低：如系統原本運行的好好的，加入消息隊列後一旦消息隊列掛掉，系統直接就over了
2、增加系統的複雜度：採用消息隊列後要考慮好多問題，如一致性、如何保證消息不被重複消費、消息的可靠傳輸
三、消息隊列的選型
1、ActiveMQ：更新比較慢、java開發的、萬級吞吐量
2、RabbitMQ:相對ActiveMQ來說更新較快、erlang語言開發（erlang語言天生具有高併發的特效，但是熟悉erlang的人相對較少，好在社區比較活躍）
3、RocketMQ：支持分佈式架構、Java語言開發可以定製化開發
4、Kafka：支持分佈式架構、吞吐量十萬級
四、保證消息隊列的高可用
建立長鏈接，定時發送心跳
五、如何保證不會重複消費
1、RabbitMQ會發生一個ACK確認消息
2、RocketMQ會返回一個CONSUME_SUCCESS成功標誌
3、Kafka每條消息會有一個offset，在消費後需要提交offset，讓消息隊列知道已經消費
六、如何保證消息的可靠傳輸
三個角度：生產者弄丟數據、消息隊列弄丟數據、消費者弄丟數據
1、RabbitMQ提供transaction和confirm來保證生產者不丟消息
1.1 transaction機制就是說在發送消息的時候開啓事務<channel.txSelect()>，然後再發送消息，若發送過程中發生異常則會滾<channel.txRollback()>，成功則提交<channel.txCommit()>，缺點就是吞吐量下降
1.2 confirm模式生產上用的居多，一旦channel進入confirm模式，所有在該信道上的消息都會被指派一個唯一ID（從1開始），一旦消息投遞到所匹配的隊列都，RabbitMQ會發送一個Ack（包含消息的唯一ID）給生產者，這就知道已經消費處理了，如果RabbitMQ沒有處理這條消息，則會發送一個Nack消息給你，這就知道消費失敗，然後就可以重試了。
2、RabbitMQ消息隊列丟數據
2.1 處理消息隊列丟數據的情況，一般是開啓持久化磁盤的配置。這個持久化配置可以和confirm機制配合使用，你可以在消息持久化磁盤後，再給生產者發送一個Ack信號。這樣，如果消息持久化磁盤之前，rabbitMQ陣亡了，那麼生產者收不到Ack信號，生產者會自動重發。
2.11 那麼如何持久化呢，這裏順便說一下吧，其實也很容易，就下面兩步
2.111、將queue的持久化標識durable設置爲true,則代表是一個持久的隊列
2.112、發送消息的時候將deliveryMode=2
這樣設置以後，rabbitMQ就算掛了，重啓後也能恢復數據
3、RabbitMQ消費者丟數據
3.1 消費者丟數據一般是因爲採用了自動確認消息模式（採用手動提交即可）
4、Kafka生產丟失數據
4.1 在kafka生產中，基本都有一個leader和多個follwer。follwer會去同步leader的信息。因此，爲了避免生產者丟數據，做如下兩點配置
第一個配置要在producer端設置acks=all。這個配置保證了，follwer同步完成後，才認爲消息發送成功。
在producer端設置retries=MAX，一旦寫入失敗，這無限重試
5、Kafka消息隊列丟數據
5.1 針對消息隊列丟數據的情況，無外乎就是，數據還沒同步，leader就掛了，這時zookpeer會將其他的follwer切換爲leader,那數據就丟失了。針對這種情況，應該做兩個配置。
replication.factor參數，這個值必須大於1，即要求每個partition必須有至少2個副本
min.insync.replicas參數，這個值必須大於1，這個是要求一個leader至少感知到有至少一個follower還跟自己保持聯繫。這兩個配置加上上面生產者的配置聯合起來用，基本可確保kafka不丟數據
6、Kafka消費者丟數據
6.1 這種情況一般是自動提交了offset，然後你處理程序過程中掛了。kafka以爲你處理好了。解決方案也很簡單，改成手動提交即可。
6.2 offset介紹：
6.21 offset：指的是kafka的topic中的每個消費組消費的下標。簡單的來說就是一條消息對應一個offset下標，每次消費數據的時候如果提交offset，那麼下次消費就會從提交的offset加一那裏開始消費。
比如一個topic中有100條數據，我消費了50條並且提交了，那麼此時的kafka服務端記錄提交的offset就是49(offset從0開始)，那麼下次消費的時候offset就從50開始消費。
ActiveMQ和RocketMQ自己查閱一下就行。
不喜勿噴。