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