redis實現(xiàn)消息隊列有兩種形式：
廣播訂閱模式：基于Redis的 Pub/Sub 機制，一旦有客戶端往某個key里面 publish一個消息，所有subscribe的客戶端都會觸發(fā)事件集群訂閱模式：基于Redis List雙向+ 原子性 + BRPOP ? ?（推薦學(xué)習(xí)：Redis視頻教程）
Redis消息隊列時，當(dāng)Redis宕機后，消息可能會丟失（也要看持久化的策略）。如果收消息方未有重發(fā)和驗證機制，Redis內(nèi)的數(shù)據(jù)會出現(xiàn)丟失。所以，使用Redis的作為消息隊列，通常是對于消息的準(zhǔn)確性并非特別高的場景。
如果絕對的保證數(shù)據(jù)最終一致性，保證消息百分百不丟，那么需要：
1.寫入時候要求啟用事務(wù)處理，保證寫一定成功。
2. redis配置成任何變更一定實時持久化，比如存儲端是磁盤的話，每次變更馬上同步寫入磁盤，才算完成。redis是支持這種方式配置的，但是這么做會使它的內(nèi)存數(shù)據(jù)庫特性完全消失，性能變得十分低下。
3. 消費端也要實現(xiàn)事務(wù)方式，處理完成后，再回來真實刪除消息。
4. 多線程或者多端同時并發(fā)處理，可以通過鎖的方式來規(guī)避。
3 4的需求需要自己實現(xiàn)，可以一起考慮，用另外一個隊列實現(xiàn)的方式也可以，但是更好的方式是在隊列內(nèi)部實現(xiàn)個計數(shù)器。hash格式的加個字段加數(shù)值，list的先推一個數(shù)值打底，String的頭上加個數(shù)值再加個分隔符，就可以做個簡單計數(shù)器了，雖然土，勝在夠?qū)嵱谩?/p>
除了特定的系統(tǒng)之外，一般不會要求這么強的一致性，實現(xiàn)倒不難，但是性能會很差很差。
銀行類支付類業(yè)務(wù)會要求嚴(yán)格的事務(wù)一致性，而互聯(lián)網(wǎng)類業(yè)務(wù)一般會用點取巧的方式，就是可以容忍極短時間內(nèi)少量數(shù)據(jù)丟失的方式，換取更高性能。
比如上面的redis處理，可以改為1000條數(shù)據(jù)變更的時候再真實落盤，即寫入磁盤。那么極限情況下，如突然斷電，存在可能丟失這1000條數(shù)據(jù)的風(fēng)險。當(dāng)然這種情況出現(xiàn)的概率也是很低的（遠(yuǎn)離藍(lán)翔挖掘機？），所以大部分場景下可以接受。
更多Redis相關(guān)技術(shù)文章，請訪問Redis視頻教程欄目進(jìn)行學(xué)習(xí)！
