接上一章redis面試必問（上）

7.redis 集群模式的工作原理能說一下么？在集群模式下，redis 的 key 是如何尋址的？分布式尋址都有哪些算法？了解一致性 hash 算法嗎？

考點(diǎn)分析

在前幾年，redis 如果要搞幾個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)存儲(chǔ)一部分的數(shù)據(jù)，得借助一些中間件來實(shí)現(xiàn)，比如說有 codis，或者 twemproxy，都有。有一些 redis 中間件，你讀寫 redis 中間件，redis 中間件負(fù)責(zé)將你的數(shù)據(jù)分布式存儲(chǔ)在多臺(tái)機(jī)器上的 redis 實(shí)例中。

這兩年，redis 不斷在發(fā)展，redis 也不斷的有新的版本，現(xiàn)在的 redis 集群模式，可以做到在多臺(tái)機(jī)器上，部署多個(gè) redis 實(shí)例，每個(gè)實(shí)例存儲(chǔ)一部分的數(shù)據(jù)，同時(shí)每個(gè) redis 實(shí)例可以掛 redis 從實(shí)例，自動(dòng)確保說，如果 redis 主實(shí)例掛了，會(huì)自動(dòng)切換到 redis 從實(shí)例頂上來。

現(xiàn)在 redis 的新版本，大家都是用 redis cluster 的，也就是 redis 原生支持的 redis 集群模式，那么面試官肯定會(huì)就 redis cluster 對(duì)你來個(gè)幾連炮。要是你沒用過 redis cluster，正常，以前很多人用 codis 之類的客戶端來支持集群，但是起碼你得研究一下 redis cluster 吧。

如果你的數(shù)據(jù)量很少，主要是承載高并發(fā)高性能的場(chǎng)景，比如你的緩存一般就幾個(gè) G，單機(jī)就足夠了，可以使用 replication，一個(gè) master 多個(gè) slaves，要幾個(gè) slave 跟你要求的讀吞吐量有關(guān)，然后自己搭建一個(gè) sentinel 集群去保證 redis 主從架構(gòu)的高可用性。

redis cluster，主要是針對(duì)海量數(shù)據(jù)+高并發(fā)+高可用的場(chǎng)景。redis cluster 支撐 N 個(gè) redis master node，每個(gè) master node 都可以掛載多個(gè) slave node。這樣整個(gè) redis 就可以橫向擴(kuò)容了。如果你要支撐更大數(shù)據(jù)量的緩存，那就橫向擴(kuò)容更多的 master 節(jié)點(diǎn)，每個(gè) master 節(jié)點(diǎn)就能存放更多的數(shù)據(jù)了。

面試題剖析

redis cluster 介紹

• 自動(dòng)將數(shù)據(jù)進(jìn)行分片，每個(gè) master 上放一部分?jǐn)?shù)據(jù)
• 提供內(nèi)置的高可用支持，部分 master 不可用時(shí)，還是可以繼續(xù)工作的

在 redis cluster 架構(gòu)下，每個(gè) redis 要放開兩個(gè)端口號(hào)，比如一個(gè)是 6379，另外一個(gè)就是 加1w 的端口號(hào)，比如 16379。

16379 端口號(hào)是用來進(jìn)行節(jié)點(diǎn)間通信的，也就是 cluster bus 的東西，cluster bus 的通信，用來進(jìn)行故障檢測(cè)、配置更新、故障轉(zhuǎn)移授權(quán)。cluster bus 用了另外一種二進(jìn)制的協(xié)議，gossip 協(xié)議，用于節(jié)點(diǎn)間進(jìn)行高效的數(shù)據(jù)交換，占用更少的網(wǎng)絡(luò)帶寬和處理時(shí)間。

節(jié)點(diǎn)間的內(nèi)部通信機(jī)制

基本通信原理

• redis cluster 節(jié)點(diǎn)間采用 gossip 協(xié)議進(jìn)行通信
  集中式是將集群元數(shù)據(jù)（節(jié)點(diǎn)信息、故障等等）幾種存儲(chǔ)在某個(gè)節(jié)點(diǎn)上。集中式元數(shù)據(jù)集中存儲(chǔ)的一個(gè)典型代表，就是大數(shù)據(jù)領(lǐng)域的 storm。它是分布式的大數(shù)據(jù)實(shí)時(shí)計(jì)算引擎，是集中式的元數(shù)據(jù)存儲(chǔ)的結(jié)構(gòu)，底層基于 zookeeper（分布式協(xié)調(diào)的中間件）對(duì)所有元數(shù)據(jù)進(jìn)行存儲(chǔ)維護(hù)。

zookeeper-centralized-storage

redis 維護(hù)集群元數(shù)據(jù)采用另一個(gè)方式， gossip 協(xié)議，所有節(jié)點(diǎn)都持有一份元數(shù)據(jù)，不同的節(jié)點(diǎn)如果出現(xiàn)了元數(shù)據(jù)的變更，就不斷將元數(shù)據(jù)發(fā)送給其它的節(jié)點(diǎn)，讓其它節(jié)點(diǎn)也進(jìn)行元數(shù)據(jù)的變更。

redis-gossip

集中式的好處在于，元數(shù)據(jù)的讀取和更新，時(shí)效性非常好，一旦元數(shù)據(jù)出現(xiàn)了變更，就立即更新到集中式的存儲(chǔ)中，其它節(jié)點(diǎn)讀取的時(shí)候就可以感知到；不好在于，所有的元數(shù)據(jù)的更新壓力全部集中在一個(gè)地方，可能會(huì)導(dǎo)致元數(shù)據(jù)的存儲(chǔ)有壓力。

gossip 好處在于，元數(shù)據(jù)的更新比較分散，不是集中在一個(gè)地方，更新請(qǐng)求會(huì)陸陸續(xù)續(xù)，打到所有節(jié)點(diǎn)上去更新，降低了壓力；不好在于，元數(shù)據(jù)的更新有延時(shí)，可能導(dǎo)致集群中的一些操作會(huì)有一些滯后。

• 10000 端口
  每個(gè)節(jié)點(diǎn)都有一個(gè)專門用于節(jié)點(diǎn)間通信的端口，就是自己提供服務(wù)的端口號(hào)+10000，比如 7001，那么用于節(jié)點(diǎn)間通信的就是 17001 端口。每個(gè)節(jié)點(diǎn)每隔一段時(shí)間都會(huì)往另外幾個(gè)節(jié)點(diǎn)發(fā)送 ping 消息，同時(shí)其它幾個(gè)節(jié)點(diǎn)接收到 ping 之后返回 pong。

• 交換的信息
  信息包括故障信息，節(jié)點(diǎn)的增加和刪除，hash slot 信息 等等。

gossip 協(xié)議

gossip 協(xié)議包含多種消息，包含 ping,pong,meet,fail 等等。

• meet：某個(gè)節(jié)點(diǎn)發(fā)送 meet 給新加入的節(jié)點(diǎn)，讓新節(jié)點(diǎn)加入集群中，然后新節(jié)點(diǎn)就會(huì)開始與其它節(jié)點(diǎn)進(jìn)行通信。

其實(shí)內(nèi)部就是發(fā)送了一個(gè) gossip meet 消息給新加入的節(jié)點(diǎn)，通知那個(gè)節(jié)點(diǎn)去加入我們的集群。

• ping：每個(gè)節(jié)點(diǎn)都會(huì)頻繁給其它節(jié)點(diǎn)發(fā)送 ping，其中包含自己的狀態(tài)還有自己維護(hù)的集群元數(shù)據(jù)，互相通過 ping 交換元數(shù)據(jù)。
• pong：返回 ping 和 meeet，包含自己的狀態(tài)和其它信息，也用于信息廣播和更新。
• fail：某個(gè)節(jié)點(diǎn)判斷另一個(gè)節(jié)點(diǎn) fail 之后，就發(fā)送 fail 給其它節(jié)點(diǎn)，通知其它節(jié)點(diǎn)說，某個(gè)節(jié)點(diǎn)宕機(jī)啦。

ping 消息深入

ping 時(shí)要攜帶一些元數(shù)據(jù)，如果很頻繁，可能會(huì)加重網(wǎng)絡(luò)負(fù)擔(dān)。

每個(gè)節(jié)點(diǎn)每秒會(huì)執(zhí)行 10 次 ping，每次會(huì)選擇 5 個(gè)最久沒有通信的其它節(jié)點(diǎn)。當(dāng)然如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)通信延時(shí)達(dá)到了 cluster_node_timeout / 2，那么立即發(fā)送 ping，避免數(shù)據(jù)交換延時(shí)過長(zhǎng)，落后的時(shí)間太長(zhǎng)了。比如說，兩個(gè)節(jié)點(diǎn)之間都 10 分鐘沒有交換數(shù)據(jù)了，那么整個(gè)集群處于嚴(yán)重的元數(shù)據(jù)不一致的情況，就會(huì)有問題。所以 cluster_node_timeout 可以調(diào)節(jié)，如果調(diào)得比較大，那么會(huì)降低 ping 的頻率。

每次 ping，會(huì)帶上自己節(jié)點(diǎn)的信息，還有就是帶上 1/10 其它節(jié)點(diǎn)的信息，發(fā)送出去，進(jìn)行交換。至少包含 3 個(gè)其它節(jié)點(diǎn)的信息，最多包含總結(jié)點(diǎn)-2 個(gè)其它節(jié)點(diǎn)的信息。

分布式尋址算法

• hash 算法（大量緩存重建）
• 一致性 hash 算法（自動(dòng)緩存遷移）+ 虛擬節(jié)點(diǎn)（自動(dòng)負(fù)載均衡）
• redis cluster 的 hash slot 算法

hash 算法

來了一個(gè) key，首先計(jì)算 hash 值，然后對(duì)節(jié)點(diǎn)數(shù)取模。然后打在不同的 master 節(jié)點(diǎn)上。一旦某一個(gè) master 節(jié)點(diǎn)宕機(jī)，所有請(qǐng)求過來，都會(huì)基于最新的剩余 master 節(jié)點(diǎn)數(shù)去取模，嘗試去取數(shù)據(jù)。這會(huì)導(dǎo)致大部分的請(qǐng)求過來，全部無法拿到有效的緩存，導(dǎo)致大量的流量涌入數(shù)據(jù)庫。

hash

一致性 hash 算法

一致性 hash 算法將整個(gè) hash 值空間組織成一個(gè)虛擬的圓環(huán)，整個(gè)空間按順時(shí)針方向組織，下一步將各個(gè) master 節(jié)點(diǎn)（使用服務(wù)器的 ip 或主機(jī)名）進(jìn)行 hash。這樣就能確定每個(gè)節(jié)點(diǎn)在其哈希環(huán)上的位置。

來了一個(gè) key，首先計(jì)算 hash 值，并確定此數(shù)據(jù)在環(huán)上的位置，從此位置沿環(huán)順時(shí)針“行走”，遇到的第一個(gè) master 節(jié)點(diǎn)就是 key 所在位置。

在一致性哈希算法中，如果一個(gè)節(jié)點(diǎn)掛了，受影響的數(shù)據(jù)僅僅是此節(jié)點(diǎn)到環(huán)空間前一個(gè)節(jié)點(diǎn)（沿著逆時(shí)針方向行走遇到的第一個(gè)節(jié)點(diǎn)）之間的數(shù)據(jù)，其它不受影響。增加一個(gè)節(jié)點(diǎn)也同理。

燃鵝，一致性哈希算法在節(jié)點(diǎn)太少時(shí)，容易因?yàn)楣?jié)點(diǎn)分布不均勻而造成緩存熱點(diǎn)的問題。為了解決這種熱點(diǎn)問題，一致性 hash 算法引入了虛擬節(jié)點(diǎn)機(jī)制，即對(duì)每一個(gè)節(jié)點(diǎn)計(jì)算多個(gè) hash，每個(gè)計(jì)算結(jié)果位置都放置一個(gè)虛擬節(jié)點(diǎn)。這樣就實(shí)現(xiàn)了數(shù)據(jù)的均勻分布，負(fù)載均衡。

consistent-hashing-algorithm

redis cluster 的 hash slot 算法

redis cluster 有固定的 16384 個(gè) hash slot，對(duì)每個(gè) key 計(jì)算 CRC16 值，然后對(duì) 16384 取模，可以獲取 key 對(duì)應(yīng)的 hash slot。

redis cluster 中每個(gè) master 都會(huì)持有部分 slot，比如有 3 個(gè) master，那么可能每個(gè) master 持有 5000 多個(gè) hash slot。hash slot 讓 node 的增加和移除很簡(jiǎn)單，增加一個(gè) master，就將其他 master 的 hash slot 移動(dòng)部分過去，減少一個(gè) master，就將它的 hash slot 移動(dòng)到其他 master 上去。移動(dòng) hash slot 的成本是非常低的?？蛻舳说?api，可以對(duì)指定的數(shù)據(jù)，讓他們走同一個(gè) hash slot，通過 hash tag 來實(shí)現(xiàn)。

任何一臺(tái)機(jī)器宕機(jī)，另外兩個(gè)節(jié)點(diǎn)，不影響的。因?yàn)?key 找的是 hash slot，不是機(jī)器。

hash-slot

redis cluster 的高可用與主備切換原理

redis cluster 的高可用的原理，幾乎跟哨兵是類似的

判斷節(jié)點(diǎn)宕機(jī)

如果一個(gè)節(jié)點(diǎn)認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)，那么就是 pfail，主觀宕機(jī)。如果多個(gè)節(jié)點(diǎn)都認(rèn)為另外一個(gè)節(jié)點(diǎn)宕機(jī)了，那么就是 fail，客觀宕機(jī)，跟哨兵的原理幾乎一樣，sdown，odown。

在 cluster-node-timeout 內(nèi)，某個(gè)節(jié)點(diǎn)一直沒有返回 pong，那么就被認(rèn)為 pfail。

如果一個(gè)節(jié)點(diǎn)認(rèn)為某個(gè)節(jié)點(diǎn) pfail 了，那么會(huì)在 gossip ping 消息中，ping 給其他節(jié)點(diǎn)，如果超過半數(shù)的節(jié)點(diǎn)都認(rèn)為 pfail 了，那么就會(huì)變成 fail。

從節(jié)點(diǎn)過濾

對(duì)宕機(jī)的 master node，從其所有的 slave node 中，選擇一個(gè)切換成 master node。

檢查每個(gè) slave node 與 master node 斷開連接的時(shí)間，如果超過了 cluster-node-timeout * cluster-slave-validity-factor，那么就沒有資格切換成 master。

從節(jié)點(diǎn)選舉

每個(gè)從節(jié)點(diǎn)，都根據(jù)自己對(duì) master 復(fù)制數(shù)據(jù)的 offset，來設(shè)置一個(gè)選舉時(shí)間，offset 越大（復(fù)制數(shù)據(jù)越多）的從節(jié)點(diǎn)，選舉時(shí)間越靠前，優(yōu)先進(jìn)行選舉。

所有的 master node 開始 slave 選舉投票，給要進(jìn)行選舉的 slave 進(jìn)行投票，如果大部分 master node（N/2 + 1）都投票給了某個(gè)從節(jié)點(diǎn)，那么選舉通過，那個(gè)從節(jié)點(diǎn)可以切換成 master。

從節(jié)點(diǎn)執(zhí)行主備切換，從節(jié)點(diǎn)切換為主節(jié)點(diǎn)。

與哨兵比較

整個(gè)流程跟哨兵相比，非常類似，所以說，redis cluster 功能強(qiáng)大，直接集成了 replication 和 sentinel 的功能。

8.了解什么是 redis 的雪崩和穿透？redis 崩潰之后會(huì)怎么樣？系統(tǒng)該如何應(yīng)對(duì)這種情況？如何處理 redis 的穿透？

面試題剖析

緩存雪崩

對(duì)于系統(tǒng) A，假設(shè)每天高峰期每秒 5000 個(gè)請(qǐng)求，本來緩存在高峰期可以扛住每秒 4000 個(gè)請(qǐng)求，但是緩存機(jī)器意外發(fā)生了全盤宕機(jī)。緩存掛了，此時(shí) 1 秒 5000 個(gè)請(qǐng)求全部落數(shù)據(jù)庫，數(shù)據(jù)庫必然扛不住，它會(huì)報(bào)一下警，然后就掛了。此時(shí)，如果沒用什么特別的方案來處理這個(gè)故障，DBA 很著急，重啟數(shù)據(jù)庫，但是數(shù)據(jù)庫立馬又被新的流量給打死了。

這就是緩存雪崩。

redis-caching-avalanche

大約在 3 年前，國(guó)內(nèi)比較知名的一個(gè)互聯(lián)網(wǎng)公司，曾因?yàn)榫彺媸鹿剩瑢?dǎo)致雪崩，后臺(tái)系統(tǒng)全部崩潰，事故從當(dāng)天下午持續(xù)到晚上凌晨 3~4 點(diǎn)，公司損失了幾千萬。

緩存雪崩的事前事中事后的解決方案如下。

• 事前：redis 高可用，主從+哨兵，redis cluster，避免全盤崩潰。
• 事中：本地 ehcache 緩存 + hystrix 限流&降級(jí)，避免 MySQL 被打死。
• 事后：redis 持久化，一旦重啟，自動(dòng)從磁盤上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。

redis-caching-avalanche-solution

用戶發(fā)送一個(gè)請(qǐng)求，系統(tǒng) A 收到請(qǐng)求后，先查本地 ehcache 緩存，如果沒查到再查 redis。如果 ehcache 和 redis 都沒有，再查數(shù)據(jù)庫，將數(shù)據(jù)庫中的結(jié)果，寫入 ehcache 和 redis 中。

限流組件，可以設(shè)置每秒的請(qǐng)求，有多少能通過組件，剩余的未通過的請(qǐng)求，怎么辦？走降級(jí)！可以返回一些默認(rèn)的值，或者友情提示，或者空白的值。

好處：

• 數(shù)據(jù)庫絕對(duì)不會(huì)死，限流組件確保了每秒只有多少個(gè)請(qǐng)求能通過。
• 只要數(shù)據(jù)庫不死，就是說，對(duì)用戶來說，2/5 的請(qǐng)求都是可以被處理的。
• 只要有 2/5 的請(qǐng)求可以被處理，就意味著你的系統(tǒng)沒死，對(duì)用戶來說，可能就是點(diǎn)擊幾次刷不出來頁面，但是多點(diǎn)幾次，就可以刷出來一次。

緩存穿透

對(duì)于系統(tǒng)A，假設(shè)一秒 5000 個(gè)請(qǐng)求，結(jié)果其中 4000 個(gè)請(qǐng)求是黑客發(fā)出的惡意攻擊。

黑客發(fā)出的那 4000 個(gè)攻擊，緩存中查不到，每次你去數(shù)據(jù)庫里查，也查不到。

舉個(gè)栗子。數(shù)據(jù)庫 id 是從 1 開始的，結(jié)果黑客發(fā)過來的請(qǐng)求 id 全部都是負(fù)數(shù)。這樣的話，緩存中不會(huì)有，請(qǐng)求每次都“視緩存于無物”，直接查詢數(shù)據(jù)庫。這種惡意攻擊場(chǎng)景的緩存穿透就會(huì)直接把數(shù)據(jù)庫給打死。

redis-caching-penetration

解決方式很簡(jiǎn)單，每次系統(tǒng) A 從數(shù)據(jù)庫中只要沒查到，就寫一個(gè)空值到緩存里去，比如 set -999 UNKNOWN。這樣的話，下次便能走緩存了。

9.如何保證緩存與數(shù)據(jù)庫的雙寫一致性？

面試題剖析

一般來說，如果允許緩存可以稍微的跟數(shù)據(jù)庫偶爾有不一致的情況，也就是說如果你的系統(tǒng)不是嚴(yán)格要求 “緩存+數(shù)據(jù)庫” 必須保持一致性的話，最好不要做這個(gè)方案，即：讀請(qǐng)求和寫請(qǐng)求串行化，串到一個(gè)內(nèi)存隊(duì)列里去。

串行化可以保證一定不會(huì)出現(xiàn)不一致的情況，但是它也會(huì)導(dǎo)致系統(tǒng)的吞吐量大幅度降低，用比正常情況下多幾倍的機(jī)器去支撐線上的一個(gè)請(qǐng)求。

Cache Aside Pattern

最經(jīng)典的緩存+數(shù)據(jù)庫讀寫的模式，就是 Cache Aside Pattern。

• 讀的時(shí)候，先讀緩存，緩存沒有的話，就讀數(shù)據(jù)庫，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。
• 更新的時(shí)候，先更新數(shù)據(jù)庫，然后再刪除緩存。

為什么是刪除緩存，而不是更新緩存？

原因很簡(jiǎn)單，很多時(shí)候，在復(fù)雜點(diǎn)的緩存場(chǎng)景，緩存不單單是數(shù)據(jù)庫中直接取出來的值。

比如可能更新了某個(gè)表的一個(gè)字段，然后其對(duì)應(yīng)的緩存，是需要查詢另外兩個(gè)表的數(shù)據(jù)并進(jìn)行運(yùn)算，才能計(jì)算出緩存最新的值的。

另外更新緩存的代價(jià)有時(shí)候是很高的。是不是說，每次修改數(shù)據(jù)庫的時(shí)候，都一定要將其對(duì)應(yīng)的緩存更新一份？也許有的場(chǎng)景是這樣，但是對(duì)于比較復(fù)雜的緩存數(shù)據(jù)計(jì)算的場(chǎng)景，就不是這樣了。如果你頻繁修改一個(gè)緩存涉及的多個(gè)表，緩存也頻繁更新。但是問題在于，這個(gè)緩存到底會(huì)不會(huì)被頻繁訪問到？

舉個(gè)栗子，一個(gè)緩存涉及的表的字段，在 1 分鐘內(nèi)就修改了 20 次，或者是 100 次，那么緩存更新 20 次、100 次；但是這個(gè)緩存在 1 分鐘內(nèi)只被讀取了 1 次，有大量的冷數(shù)據(jù)。實(shí)際上，如果你只是刪除緩存的話，那么在 1 分鐘內(nèi)，這個(gè)緩存不過就重新計(jì)算一次而已，開銷大幅度降低。用到緩存才去算緩存。

其實(shí)刪除緩存，而不是更新緩存，就是一個(gè) lazy 計(jì)算的思想，不要每次都重新做復(fù)雜的計(jì)算，不管它會(huì)不會(huì)用到，而是讓它到需要被使用的時(shí)候再重新計(jì)算。像 mybatis，hibernate，都有懶加載思想。查詢一個(gè)部門，部門帶了一個(gè)員工的 list，沒有必要說每次查詢部門，都里面的 1000 個(gè)員工的數(shù)據(jù)也同時(shí)查出來啊。80% 的情況，查這個(gè)部門，就只是要訪問這個(gè)部門的信息就可以了。先查部門，同時(shí)要訪問里面的員工，那么這個(gè)時(shí)候只有在你要訪問里面的員工的時(shí)候，才會(huì)去數(shù)據(jù)庫里面查詢 1000 個(gè)員工。

最初級(jí)的緩存不一致問題及解決方案

問題：先修改數(shù)據(jù)庫，再刪除緩存。如果刪除緩存失敗了，那么會(huì)導(dǎo)致數(shù)據(jù)庫中是新數(shù)據(jù)，緩存中是舊數(shù)據(jù)，數(shù)據(jù)就出現(xiàn)了不一致。

redis-junior-inconsistent

解決思路：先刪除緩存，再修改數(shù)據(jù)庫。如果數(shù)據(jù)庫修改失敗了，那么數(shù)據(jù)庫中是舊數(shù)據(jù)，緩存中是空的，那么數(shù)據(jù)不會(huì)不一致。因?yàn)樽x的時(shí)候緩存沒有，則讀數(shù)據(jù)庫中舊數(shù)據(jù)，然后更新到緩存中。

比較復(fù)雜的數(shù)據(jù)不一致問題分析

數(shù)據(jù)發(fā)生了變更，先刪除了緩存，然后要去修改數(shù)據(jù)庫，此時(shí)還沒修改。一個(gè)請(qǐng)求過來，去讀緩存，發(fā)現(xiàn)緩存空了，去查詢數(shù)據(jù)庫，查到了修改前的舊數(shù)據(jù)，放到了緩存中。隨后數(shù)據(jù)變更的程序完成了數(shù)據(jù)庫的修改。完了，數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一樣了...

為什么上億流量高并發(fā)場(chǎng)景下，緩存會(huì)出現(xiàn)這個(gè)問題？

只有在對(duì)一個(gè)數(shù)據(jù)在并發(fā)的進(jìn)行讀寫的時(shí)候，才可能會(huì)出現(xiàn)這種問題。其實(shí)如果說你的并發(fā)量很低的話，特別是讀并發(fā)很低，每天訪問量就 1 萬次，那么很少的情況下，會(huì)出現(xiàn)剛才描述的那種不一致的場(chǎng)景。但是問題是，如果每天的是上億的流量，每秒并發(fā)讀是幾萬，每秒只要有數(shù)據(jù)更新的請(qǐng)求，就可能會(huì)出現(xiàn)上述的數(shù)據(jù)庫+緩存不一致的情況。

解決方案如下：

更新數(shù)據(jù)的時(shí)候，根據(jù)數(shù)據(jù)的唯一標(biāo)識(shí)，將操作路由之后，發(fā)送到一個(gè) jvm 內(nèi)部隊(duì)列中。讀取數(shù)據(jù)的時(shí)候，如果發(fā)現(xiàn)數(shù)據(jù)不在緩存中，那么將重新讀取數(shù)據(jù)+更新緩存的操作，根據(jù)唯一標(biāo)識(shí)路由之后，也發(fā)送同一個(gè) jvm 內(nèi)部隊(duì)列中。

一個(gè)隊(duì)列對(duì)應(yīng)一個(gè)工作線程，每個(gè)工作線程串行拿到對(duì)應(yīng)的操作，然后一條一條的執(zhí)行。這樣的話，一個(gè)數(shù)據(jù)變更的操作，先刪除緩存，然后再去更新數(shù)據(jù)庫，但是還沒完成更新。此時(shí)如果一個(gè)讀請(qǐng)求過來，讀到了空的緩存，那么可以先將緩存更新的請(qǐng)求發(fā)送到隊(duì)列中，此時(shí)會(huì)在隊(duì)列中積壓，然后同步等待緩存更新完成。

這里有一個(gè)優(yōu)化點(diǎn)，一個(gè)隊(duì)列中，其實(shí)多個(gè)更新緩存請(qǐng)求串在一起是沒意義的，因此可以做過濾，如果發(fā)現(xiàn)隊(duì)列中已經(jīng)有一個(gè)更新緩存的請(qǐng)求了，那么就不用再放個(gè)更新請(qǐng)求操作進(jìn)去了，直接等待前面的更新操作請(qǐng)求完成即可。

待那個(gè)隊(duì)列對(duì)應(yīng)的工作線程完成了上一個(gè)操作的數(shù)據(jù)庫的修改之后，才會(huì)去執(zhí)行下一個(gè)操作，也就是緩存更新的操作，此時(shí)會(huì)從數(shù)據(jù)庫中讀取最新的值，然后寫入緩存中。

如果請(qǐng)求還在等待時(shí)間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到值了，那么就直接返回；如果請(qǐng)求等待的時(shí)間超過一定時(shí)長(zhǎng)，那么這一次直接從數(shù)據(jù)庫中讀取當(dāng)前的舊值。

高并發(fā)的場(chǎng)景下，該解決方案要注意的問題：

• 讀請(qǐng)求長(zhǎng)時(shí)阻塞

由于讀請(qǐng)求進(jìn)行了非常輕度的異步化，所以一定要注意讀超時(shí)的問題，每個(gè)讀請(qǐng)求必須在超時(shí)時(shí)間范圍內(nèi)返回。

該解決方案，最大的風(fēng)險(xiǎn)點(diǎn)在于說，可能數(shù)據(jù)更新很頻繁，導(dǎo)致隊(duì)列中積壓了大量更新操作在里面，然后讀請(qǐng)求會(huì)發(fā)生大量的超時(shí)，最后導(dǎo)致大量的請(qǐng)求直接走數(shù)據(jù)庫。務(wù)必通過一些模擬真實(shí)的測(cè)試，看看更新數(shù)據(jù)的頻率是怎樣的。

另外一點(diǎn)，因?yàn)橐粋€(gè)隊(duì)列中，可能會(huì)積壓針對(duì)多個(gè)數(shù)據(jù)項(xiàng)的更新操作，因此需要根據(jù)自己的業(yè)務(wù)情況進(jìn)行測(cè)試，可能需要部署多個(gè)服務(wù)，每個(gè)服務(wù)分?jǐn)傄恍?shù)據(jù)的更新操作。如果一個(gè)內(nèi)存隊(duì)列里居然會(huì)擠壓 100 個(gè)商品的庫存修改操作，每隔庫存修改操作要耗費(fèi) 10ms 去完成，那么最后一個(gè)商品的讀請(qǐng)求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到數(shù)據(jù)，這個(gè)時(shí)候就導(dǎo)致讀請(qǐng)求的長(zhǎng)時(shí)阻塞。

一定要做根據(jù)實(shí)際業(yè)務(wù)系統(tǒng)的運(yùn)行情況，去進(jìn)行一些壓力測(cè)試，和模擬線上環(huán)境，去看看最繁忙的時(shí)候，內(nèi)存隊(duì)列可能會(huì)擠壓多少更新操作，可能會(huì)導(dǎo)致最后一個(gè)更新操作對(duì)應(yīng)的讀請(qǐng)求，會(huì) hang 多少時(shí)間，如果讀請(qǐng)求在 200ms 返回，如果你計(jì)算過后，哪怕是最繁忙的時(shí)候，積壓 10 個(gè)更新操作，最多等待 200ms，那還可以的。

如果一個(gè)內(nèi)存隊(duì)列中可能積壓的更新操作特別多，那么你就要加機(jī)器，讓每個(gè)機(jī)器上部署的服務(wù)實(shí)例處理更少的數(shù)據(jù)，那么每個(gè)內(nèi)存隊(duì)列中積壓的更新操作就會(huì)越少。

其實(shí)根據(jù)之前的項(xiàng)目經(jīng)驗(yàn)，一般來說，數(shù)據(jù)的寫頻率是很低的，因此實(shí)際上正常來說，在隊(duì)列中積壓的更新操作應(yīng)該是很少的。像這種針對(duì)讀高并發(fā)、讀緩存架構(gòu)的項(xiàng)目，一般來說寫請(qǐng)求是非常少的，每秒的 QPS 能到幾百就不錯(cuò)了。

我們來實(shí)際粗略測(cè)算一下。

如果一秒有 500 的寫操作，如果分成 5 個(gè)時(shí)間片，每 200ms 就 100 個(gè)寫操作，放到 20 個(gè)內(nèi)存隊(duì)列中，每個(gè)內(nèi)存隊(duì)列，可能就積壓 5 個(gè)寫操作。每個(gè)寫操作性能測(cè)試后，一般是在 20ms 左右就完成，那么針對(duì)每個(gè)內(nèi)存隊(duì)列的數(shù)據(jù)的讀請(qǐng)求，也就最多 hang 一會(huì)兒，200ms 以內(nèi)肯定能返回了。

經(jīng)過剛才簡(jiǎn)單的測(cè)算，我們知道，單機(jī)支撐的寫 QPS 在幾百是沒問題的，如果寫 QPS 擴(kuò)大了 10 倍，那么就擴(kuò)容機(jī)器，擴(kuò)容 10 倍的機(jī)器，每個(gè)機(jī)器 20 個(gè)隊(duì)列。

• 讀請(qǐng)求并發(fā)量過高

這里還必須做好壓力測(cè)試，確保恰巧碰上上述情況的時(shí)候，還有一個(gè)風(fēng)險(xiǎn)，就是突然間大量讀請(qǐng)求會(huì)在幾十毫秒的延時(shí) hang 在服務(wù)上，看服務(wù)能不能扛的住，需要多少機(jī)器才能扛住最大的極限情況的峰值。

但是因?yàn)椴⒉皇撬械臄?shù)據(jù)都在同一時(shí)間更新，緩存也不會(huì)同一時(shí)間失效，所以每次可能也就是少數(shù)數(shù)據(jù)的緩存失效了，然后那些數(shù)據(jù)對(duì)應(yīng)的讀請(qǐng)求過來，并發(fā)量應(yīng)該也不會(huì)特別大。

• 多服務(wù)實(shí)例部署的請(qǐng)求路由

可能這個(gè)服務(wù)部署了多個(gè)實(shí)例，那么必須保證說，執(zhí)行數(shù)據(jù)更新操作，以及執(zhí)行緩存更新操作的請(qǐng)求，都通過 Nginx 服務(wù)器路由到相同的服務(wù)實(shí)例上。

比如說，對(duì)同一個(gè)商品的讀寫請(qǐng)求，全部路由到同一臺(tái)機(jī)器上。可以自己去做服務(wù)間的按照某個(gè)請(qǐng)求參數(shù)的 hash 路由，也可以用 Nginx 的 hash 路由功能等等。

• 熱點(diǎn)商品的路由問題，導(dǎo)致請(qǐng)求的傾斜

萬一某個(gè)商品的讀寫請(qǐng)求特別高，全部打到相同的機(jī)器的相同的隊(duì)列里面去了，可能會(huì)造成某臺(tái)機(jī)器的壓力過大。就是說，因?yàn)橹挥性谏唐窋?shù)據(jù)更新的時(shí)候才會(huì)清空緩存，然后才會(huì)導(dǎo)致讀寫并發(fā)，所以其實(shí)要根據(jù)業(yè)務(wù)系統(tǒng)去看，如果更新頻率不是太高的話，這個(gè)問題的影響并不是特別大，但是的確可能某些機(jī)器的負(fù)載會(huì)高一些。

10.redis 的并發(fā)競(jìng)爭(zhēng)問題是什么？如何解決這個(gè)問題？了解 redis 事務(wù)的 CAS 方案嗎？

考點(diǎn)分析

這個(gè)也是線上非常常見的一個(gè)問題，就是多客戶端同時(shí)并發(fā)寫一個(gè) key，可能本來應(yīng)該先到的數(shù)據(jù)后到了，導(dǎo)致數(shù)據(jù)版本錯(cuò)了；或者是多客戶端同時(shí)獲取一個(gè) key，修改值之后再寫回去，只要順序錯(cuò)了，數(shù)據(jù)就錯(cuò)了。

而且 redis 自己就有天然解決這個(gè)問題的 CAS 類的樂觀鎖方案。

面試題剖析

某個(gè)時(shí)刻，多個(gè)系統(tǒng)實(shí)例都去更新某個(gè) key?？梢曰?zookeeper 實(shí)現(xiàn)分布式鎖。每個(gè)系統(tǒng)通過 zookeeper 獲取分布式鎖，確保同一時(shí)間，只能有一個(gè)系統(tǒng)實(shí)例在操作某個(gè) key，別人都不允許讀和寫。

zookeeper-distributed-lock

你要寫入緩存的數(shù)據(jù)，都是從 mysql 里查出來的，都得寫入 mysql 中，寫入 mysql 中的時(shí)候必須保存一個(gè)時(shí)間戳，從 mysql 查出來的時(shí)候，時(shí)間戳也查出來。

每次要寫之前，先判斷一下當(dāng)前這個(gè) value 的時(shí)間戳是否比緩存里的 value 的時(shí)間戳要新。如果是的話，那么可以寫，否則，就不能用舊的數(shù)據(jù)覆蓋新的數(shù)據(jù)。

11.生產(chǎn)環(huán)境中的 redis 是怎么部署的？

面試題剖析

redis cluster，10 臺(tái)機(jī)器，5 臺(tái)機(jī)器部署了 redis 主實(shí)例，另外 5 臺(tái)機(jī)器部署了 redis 的從實(shí)例，每個(gè)主實(shí)例掛了一個(gè)從實(shí)例，5 個(gè)節(jié)點(diǎn)對(duì)外提供讀寫服務(wù)，每個(gè)節(jié)點(diǎn)的讀寫高峰qps可能可以達(dá)到每秒 5 萬，5 臺(tái)機(jī)器最多是 25 萬讀寫請(qǐng)求/s。

機(jī)器是什么配置？32G 內(nèi)存+ 8 核 CPU + 1T 磁盤，但是分配給 redis 進(jìn)程的是10g內(nèi)存，一般線上生產(chǎn)環(huán)境，redis 的內(nèi)存盡量不要超過 10g，超過 10g 可能會(huì)有問題。

5 臺(tái)機(jī)器對(duì)外提供讀寫，一共有 50g 內(nèi)存。

因?yàn)槊總€(gè)主實(shí)例都掛了一個(gè)從實(shí)例，所以是高可用的，任何一個(gè)主實(shí)例宕機(jī)，都會(huì)自動(dòng)故障遷移，redis 從實(shí)例會(huì)自動(dòng)變成主實(shí)例繼續(xù)提供讀寫服務(wù)。

你往內(nèi)存里寫的是什么數(shù)據(jù)？每條數(shù)據(jù)的大小是多少？商品數(shù)據(jù)，每條數(shù)據(jù)是 10kb。100 條數(shù)據(jù)是 1mb，10 萬條數(shù)據(jù)是 1g。常駐內(nèi)存的是 200 萬條商品數(shù)據(jù)，占用內(nèi)存是 20g，僅僅不到總內(nèi)存的 50%。目前高峰期每秒就是 3500 左右的請(qǐng)求量。

其實(shí)大型的公司，會(huì)有基礎(chǔ)架構(gòu)的 team 負(fù)責(zé)緩存集群的運(yùn)維。

關(guān)注我！這里只有干貨！
本文原創(chuàng)地址，我的博客：https:///2019/02/18/interview/interview-redis-2/，轉(zhuǎn)載請(qǐng)注明出處。