Redis壞了怎麼辦?

xuexiaogang發表於2022-07-13

前幾天半夜和一位朋友討論他們叢集的問題。我本人大概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等等交易資料庫處理快取的能力是足夠的,只是這些不是核心競爭力,分包一下給了一個優秀的整合商。當整合商出現問題時候,甲方自己也要能上。不能說整合商不做了,甲方自己也關門了。個人愚見。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/637517/viewspace-2905661/,如需轉載,請註明出處,否則將追究法律責任。

相關文章