Redis集群部署三種方式

1. 主從復(fù)制

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

2. 哨兵模式

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

優(yōu)點(diǎn)：

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

3. redis-cluster模式

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

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

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

優(yōu)點(diǎn)：

• 實(shí)現(xiàn)擴(kuò)容；
• 分?jǐn)倝毫Γ?/li>
• 無中心配置相對(duì)簡(jiǎn)單。

缺點(diǎn)：

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

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

緩存穿透

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

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

造成：

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

解決：

對(duì)空值緩存

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

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

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

采用布隆過濾器

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

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

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

緩存擊穿

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

如何解決

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

緩存雪崩

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

解決

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

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

使用鎖或隊(duì)列：

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

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

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

將緩存失效時(shí)間分散開：

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

總結(jié)

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

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

最新評(píng)論