分布式系統中Redis等快取系統宕機應不應該影響正常應用系統執行?

時間 2021-05-10 22:16:43

1樓:大寬寬

首先,Redis的用法分為「快取」和「儲存」兩類。題目中的庫存,分布式鎖等屬於「儲存」。這裡說的儲存是指Redis裡存的資料不能丟,不可以從Redis集群之外的地方完全恢復。

對於「儲存」,沒有「穿透」一說。穿透是針對「快取」這個場景用的。

引入快取的原因一般就是後面的資料庫撐不住。如果能撐住就沒有必要加快取,還不如把錢給資料庫多加點記憶體當buffer pool。

而一旦引入了快取,承受絕大部分的流量,就意味著一旦快取掛了就會雪崩。此時有兩種假設,第一種是假設快取不會掛。這需要對集群做高可用部署,比如阿里雲的redis集群配置裡有這個選項,加錢就是了。

自己搭建無非也就是codis,tweeproxy,redis自己的cluster,redis sentinel等幾種方案。並且留意運維也不能出錯(運維出錯比機器出錯可怕多了……)。

另外一種就是假設Redis會掛掉,此時一方面要緊急進入限流模式,限制使用者請求量到達乙個資料庫可以接受的狀態。至於是保障使用者公平可用,還是高淨值使用者可用這個業務上自己權衡吧。同時,一般還會對快取做乙個「異構」容災方案。

比如,若redis不可用,就用單機的記憶體做快取抗。但是服務記憶體數量有限,需要提前演練確定方案可行。

至於「什麼時候才能認為集群掛了」,請自行查詢乙個叫做「請求錯誤率「的監控指標。

2樓:qingzhou

個人見解:直接報錯

比如說作為session共享,一般不會把session存到資料庫中,快取掛掉的話沒有替代儲存,業務功能完全無法正常工作,這種場景也只能報錯。

再比如說作為關係型資料庫快取,既然用快取絕大部分情況是為了降低資料庫壓力,那麼在快取完全掛掉後大概率資料庫是扛不住的,否則也沒有一定要上快取的必要了。既然快取掛掉資料庫也會扛不住,那乾脆直接報錯。

所以與其想方設法解決快取掛掉的問題,反而不如想方設法保障快取不要掛掉,而現在的三節點甚至五節點高可用方案其可靠性是可以滿足絕大部分場景的。

建議可以了解一些金融系統高效能高可用設計方案。

3樓:等待戈多的秋天

主從啊集群啊都可以解決宕機的問題,為何要開穿透。這就是偽命題啊,如果穿透可以開,那還用快取幹嘛?用快取還得解決資料一致性問題,多累。

同是分布式系統,為什麼redis不需要leader,而rocketmq和oceanbase需要?

drdr xp 所有的強一致分布式系統都有leader,或者是乙個長期維護的leader 程序,或是短暫存在的某條記錄的leader。沒有leader的,一定不是乙個強一致系統。因為達成一致本身的含義就是 某個變數的值是在某個時刻被全域性唯一的乙個程序決定的,這個程序在那個時間就是這個變數的lead...

Geode 和 redis 兩個分布式記憶體資料庫的對比,優缺點?

莊懷軒 準確的說,Geode不是記憶體資料庫 In Memory DataBase,IMDB 而是有資料庫功能的記憶體資料網格 In Memory Data Grid,IMDG 如果說最基本的優缺點,Redis最大的優勢就是上手快了,可以迅速的搭建起來。但是如果真的比較效能和功能,Redis是完全不...

分布式系統廣泛使用的zookeeper有哪些重要的概念呢?

一朵雲Q QuorumPeer 節點型別,分為 LeaderZookerServer FollowerZookeeperServer ObserverZookeeperServer leader節點對應Leader類物件,以及LearnerHandler接收處理訊息 follower節點對應Lear...