Redis壞了怎麼辦？

前幾天半夜和一位朋友討論他們叢集的問題。我本人大概7年前幹過一次叢集報廢的事情（好在是實驗環境摸索）一下重啟了所有節點（當時安裝在一臺機器上了）。這種情況下機器已重啟所有節點都重啟，cluster大的特點是要半數以上存活。這種情況下開了持久化，他叢集也組合不起來了。（也許有高人有其他辦法，我當時是沒辦法，重建的）。

     當年我就在想一個問題，如果redis萬一壞了或者奔潰了。我們日子還過不過了？必然是要過的啊。redis沒發明出來之前難道系統不做了？

     這裡首先要看redis存什麼？存日誌，出去。  一般來說我們都說兩個場景A保持會話，還有B快取。其他的我個人觀點不用了。A場景如果說redis壞了，再起一個就行，這種資訊也不需要持久化，沒了就沒了，不影響什麼。B場景其實有點要命的，我們通常為了減輕RDBMS的壓力，即讓NoSQL來打輔助，關聯式資料庫集中精力做線上交易。所以高頻次讀取的放到Redis中減輕訪問關聯式資料庫的壓力。 

   這裡的快取有B1這種來源是關係型資料庫的一條記錄，反覆讀取（但是一致性不要求那麼高），那麼就放到Redis中，差一點也沒關係，比如點贊數量。B2場景是把關係型資料庫的統計結果放到Redis中。這種一旦遇到redis壞了，或者快取被擊穿了。那麼有兩種現象，一種是直接就報錯不能提供服務。還有一種就是玩命去關係型資料庫中去聚合，結果是馬上關係型資料庫也不行了。

    所以我一直主張是B2的場景再關係型資料庫中落地，redis一旦出問題了，查關係型資料庫的表，因為是點查，所以壓力其實也還好。畢竟是直接讀的結算結果，而不是實時計算。這個有本質的差別。而且Redis單執行緒，關聯式資料庫要麼是多執行緒要麼是多程式的。資料庫伺服器的配置一定是能抗住的。

   即redis壞了也不影響主流程走下去，最多是給關係型資料庫增加了一點不愉快的壓力。而redis日常是把這些輔助的壓力拿去承擔了。我們不能本末倒置，讓redis成為核心環節，這樣全壓在單執行緒上，不科學。除非業務量實在是小，單執行緒妥妥支援，另當別論。

    一定要有他萬一不能正常使用了，我們還要能繼續用下去。要相信Oracle、MySQL、PG還有TiDB等等交易資料庫處理快取的能力是足夠的，只是這些不是核心競爭力，分包一下給了一個優秀的整合商。當整合商出現問題時候，甲方自己也要能上。不能說整合商不做了，甲方自己也關門了。個人愚見。