redis的消息隊(duì)列防止數(shù)據(jù)丟失的方法

序言：

redis是一個(gè)key-value存儲(chǔ)系統(tǒng)。和Memcached類似，它支持存儲(chǔ)的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數(shù)據(jù)類型都支持push/pop、add/remove及取交集并集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎(chǔ)上，redis支持各種不同方式的排序。

“消息隊(duì)列”是 Microsoft 的消息處理技術(shù)，它在任何安裝 Microsoft Windows 的計(jì)算機(jī)組合中，為任何應(yīng)用程序提供消息處理和消息隊(duì)列功能，無論這些計(jì)算機(jī)是否在同一個(gè)網(wǎng)絡(luò)上或者是否同時(shí)聯(lián)機(jī)。

“消息隊(duì)列網(wǎng)絡(luò)”是能夠相互間來回發(fā)送消息的任何一組計(jì)算機(jī)。網(wǎng)絡(luò)中的不同計(jì)算機(jī)在確保消息順利處理的過程中扮演不同的角色。它們中有些提供路由信息以確定如何發(fā)送消息，有些保存整個(gè)網(wǎng)絡(luò)的重要信息，而有些只是發(fā)送和接收消息。

Redis實(shí)現(xiàn)消息隊(duì)列有兩種形式：

廣播訂閱模式：基于Redis的 Pub/Sub 機(jī)制，一旦有客戶端往某個(gè)key里面 publish一個(gè)消息，所有subscribe的客戶端都會(huì)觸發(fā)事件集群訂閱模式：基于Redis List雙向+ 原子性 + BRPOP

Redis消息隊(duì)列時(shí)，當(dāng)Redis宕機(jī)后，消息可能會(huì)丟失（也要看持久化的策略）。如果收消息方未有重發(fā)和驗(yàn)證機(jī)制，Redis內(nèi)的數(shù)據(jù)會(huì)出現(xiàn)丟失。所以，使用Redis的作為消息隊(duì)列，通常是對于消息的準(zhǔn)確性并非特別高的場景。

如果絕對的保證數(shù)據(jù)最終一致性，保證消息百分百不丟，那么需要：

1.寫入時(shí)候要求啟用事務(wù)處理，保證寫一定成功。

2. redis配置成任何變更一定實(shí)時(shí)持久化，比如存儲(chǔ)端是磁盤的話，每次變更馬上同步寫入磁盤，才算完成。redis是支持這種方式配置的，但是這么做會(huì)使它的內(nèi)存數(shù)據(jù)庫特性完全消失，性能變得十分低下。

3. 消費(fèi)端也要實(shí)現(xiàn)事務(wù)方式，處理完成后，再回來真實(shí)刪除消息。

4. 多線程或者多端同時(shí)并發(fā)處理，可以通過鎖的方式來規(guī)避。

3 4的需求需要自己實(shí)現(xiàn)，可以一起考慮，用另外一個(gè)隊(duì)列實(shí)現(xiàn)的方式也可以，但是更好的方式是在隊(duì)列內(nèi)部實(shí)現(xiàn)個(gè)計(jì)數(shù)器。hash格式的加個(gè)字段加數(shù)值，list的先推一個(gè)數(shù)值打底，string的頭上加個(gè)數(shù)值再加個(gè)分隔符，就可以做個(gè)簡單計(jì)數(shù)器了，雖然土，勝在夠?qū)嵱谩?/p>

除了特定的系統(tǒng)之外，一般不會(huì)要求這么強(qiáng)的一致性，實(shí)現(xiàn)倒不難，但是性能會(huì)很差很差。

銀行類支付類業(yè)務(wù)會(huì)要求嚴(yán)格的事務(wù)一致性，而互聯(lián)網(wǎng)類業(yè)務(wù)一般會(huì)用點(diǎn)取巧的方式，就是可以容忍極短時(shí)間內(nèi)少量數(shù)據(jù)丟失的方式，換取更高性能。

比如上面的redis處理，可以改為1000條數(shù)據(jù)變更的時(shí)候再真實(shí)落盤，即寫入磁盤。那么極限情況下，如突然斷電，存在可能丟失這1000條數(shù)據(jù)的風(fēng)險(xiǎn)。當(dāng)然這種情況出現(xiàn)的概率也是很低的（遠(yuǎn)離藍(lán)翔挖掘機(jī)？），所以大部分場景下可以接受。

以上就是redis消息隊(duì)列如何防止數(shù)據(jù)丟失的詳細(xì)內(nèi)容，更多請關(guān)注億速云其它相關(guān)文章！