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