Redis集群部署三種方式

1. 主從復(fù)制

主機數(shù)據(jù)更新后根據(jù)配置和策略， 自動同步到備機的 master/slaver 機制，Master 以寫為主，Slaver 以讀為主。

優(yōu)點：

• 讀寫分離，性能擴展
• 容災(zāi)快速恢復(fù)
• 一主多從！

缺點：

• 單主單從的情況下，讀寫分離很好，但是如果萬一主掛了，這樣就無法寫了
• 或者單主多從時，如果主掛了，也無法進(jìn)行同步了。這樣就需要選舉出一個新的主來作為主機。

2. 哨兵模式

使用Sentinel，能夠后臺監(jiān)控主機是否故障，如果故障了根據(jù)投票數(shù)自動將從庫轉(zhuǎn)換為主庫。

優(yōu)點：

• 監(jiān)控
• 監(jiān)控服務(wù)器節(jié)點
• 提醒
• 當(dāng)監(jiān)控的節(jié)點出現(xiàn)問題時，可以通過api通知其他應(yīng)用等
• 故障轉(zhuǎn)移
• 當(dāng)主掛掉時會選舉新的從服務(wù)器為主服務(wù)器，代替原來主服務(wù)器的地位

3. redis-cluster模式

1.無中心化集群配置（ redis3.0 ）

2.集群由多個節(jié)點(Node) 組成，Redis 的數(shù)據(jù)分布在這些節(jié)點中。

3.集群中的節(jié)點分為主節(jié)點和從節(jié)點；只有主節(jié)點負(fù)責(zé)讀寫請求和集群信息的維護(hù)；從節(jié)點只進(jìn)行主節(jié)點數(shù)據(jù)和狀態(tài)信息的復(fù)制。

優(yōu)點：

• 實現(xiàn)擴容；
• 分?jǐn)倝毫Γ?/li>
• 無中心配置相對簡單。

缺點：

• 多鍵操作是不被支持的；
• 多鍵的 Redis 事務(wù)是不被支持的。lua 腳本不被支持；
• 由于集群方案出現(xiàn)較晚，很多公司已經(jīng)采用了其他的集群方案，而代理或者客戶端分片的方案想要遷移至redis cluster，需要整體遷移而不是逐步過渡，復(fù)雜度較大。

Redis應(yīng)用的三種問題，穿透、擊穿、雪崩

緩存穿透

key 對應(yīng)的數(shù)據(jù)在數(shù)據(jù)源并不存在，每次針對此 key 的請求從緩存獲取不到，請求都會壓到數(shù)據(jù)源，從而可能壓垮數(shù)據(jù)源。

比如用一個不存在的用戶 id 獲取用戶信息，不論緩存還是數(shù)據(jù)庫都沒有，若黑客利用此漏洞進(jìn)行攻擊可能壓垮數(shù)據(jù)庫。

造成：

• 應(yīng)用服務(wù)器壓力變大。
• redis 命中率下降 ? \longrightarrow ? 查詢數(shù)據(jù)庫 。

解決：

對空值緩存

• 如果一個查詢返回的數(shù)據(jù)為空（不管是數(shù)據(jù)是否不存在），仍然把這個空結(jié)果（null）進(jìn)行緩存，設(shè)置空結(jié)果的過期時間會很短，最長不超過五分鐘。

設(shè)置可訪問的名單（白名單）：

• 使用 bitmaps 類型定義一個可以訪問的名單，名單 id 作為 bitmaps 的偏移量，每次訪問和 bitmap 里面的 id 進(jìn)行比較，如果訪問 id 不在 bitmaps 里面，進(jìn)行攔截，則不允許訪問。

采用布隆過濾器

• 布隆過濾器（Bloom Filter）是1970年由布隆提出的。它實際上是一個很長的二進(jìn)制向量（位圖）和一系列隨機映射函數(shù)（哈希函數(shù)）。
• 布隆過濾器可以用于檢索一個元素是否在一個集合中。它的優(yōu)點是空間效率和查詢時間都遠(yuǎn)遠(yuǎn)超過一般的算法，缺點是有一定的誤識別率和刪除困難。
• 將所有可能存在的數(shù)據(jù)哈希到一個足夠大的 bitmaps 中，一個一定不存在的數(shù)據(jù)會被這個 bitmaps 攔截掉，從而避免了對底層存儲系統(tǒng)的查詢壓力。

進(jìn)行實時監(jiān)控

• 當(dāng)發(fā)現(xiàn) Redis 的命中率開始急速降低，需要排查訪問對象和訪問的數(shù)據(jù)，和運維人員配合，可以設(shè)置黑名單限制服務(wù)。

緩存擊穿

key 對應(yīng)的數(shù)據(jù)存在，但在 redis 中過期，此時若有大量并發(fā)請求過來，這些請求發(fā)現(xiàn)緩存過期一般都會從后端DB 加載數(shù)據(jù)并回設(shè)到緩存，這個時候大并發(fā)的請求可能會瞬間把后端 DB 壓垮。

如何解決

• 預(yù)先設(shè)置熱門數(shù)據(jù)
• 在 redis 高峰訪問之前，把一些熱門數(shù)據(jù)提前存入到 redis 里面，加大這些熱門數(shù)據(jù) key 的時長。
• 實時調(diào)整
• 現(xiàn)場監(jiān)控哪些數(shù)據(jù)熱門，實時調(diào)整 key 的過期時長。
• 使用鎖

緩存雪崩

緩存雪崩是指在我們設(shè)置緩存時采用了相同的過期時間，導(dǎo)致緩存在某一時刻同時失效，請求全部轉(zhuǎn)發(fā)到DB，DB瞬時壓力過重雪崩。 

解決

構(gòu)建多級緩存架構(gòu) 

• nginx 緩存 + redis 緩存 + 其他緩存（ehcache等）

使用鎖或隊列：

• 用加鎖或者隊列的方式保證來保證不會有大量的線程對數(shù)據(jù)庫一次性進(jìn)行讀寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。不適用高并發(fā)情況。

設(shè)置過期標(biāo)志更新緩存：

• 記錄緩存數(shù)據(jù)是否過期（設(shè)置提前量），如果過期會觸發(fā)通知另外的線程在后臺去更新實際 key 的緩存。

將緩存失效時間分散開：

• 比如我們可以在原有的失效時間基礎(chǔ)上增加一個隨機值，比如 1～5 分鐘隨機，這樣每一個緩存的過期時間的重復(fù)率就會降低，就很難引發(fā)集體失效的事件。

總結(jié)

• 穿透：緩存不存在，數(shù)據(jù)庫不存在，高并發(fā)，少量key
• 擊穿：緩存不存在，數(shù)據(jù)庫存在，高并發(fā)，少量key
• 雪崩：緩存不存在，數(shù)據(jù)庫存在，高并發(fā)，大量key

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論