>> 面試常問問題一

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

1、面試官心理分析

在前幾年，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 對你來個(gè)幾連炮。要是你沒用過 redis cluster，正常，以前很多人用 codis 之類的客戶端來支持集群，但是起碼你得研究一下 redis cluster 吧。

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

redis cluster，主要是針對海量數(shù)據(jù)+高并發(fā)+高可用的場景。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ù)了。

2、面試題剖析

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)行故障檢測、配置更新、故障轉(zhuǎn)移授權(quán)。cluster bus 用了另外一種二進(jìn)制的協(xié)議，gossip 協(xié)議，用于節(jié)點(diǎn)間進(jìn)行高效的數(shù)據(jù)交換，占用更少的網(wǎng)絡(luò)帶寬和處理時(shí)間。

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

1）基本通信原理

集群元數(shù)據(jù)的維護(hù)有兩種方式：集中式、Gossip 協(xié)議。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)的中間件）對所有元數(shù)據(jù)進(jìn)行存儲(chǔ)維護(hù)。

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ù)的變更。

集中式的好處在于，元數(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è)地方，更新請求會(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 信息等等。

2）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)行通信。

redis-trib.rb add-node

其實(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ī)啦。

3）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í)過長，落后的時(shí)間太長了。

比如說，兩個(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)數(shù)減 2 個(gè)其它節(jié)點(diǎn)的信息。

4）分布式尋址算法

hash 算法（大量緩存重建）

一致性 hash 算法（自動(dòng)緩存遷移）+ 虛擬節(jié)點(diǎn)（自動(dòng)負(fù)載均衡）

redis cluster 的 hash slot 算法

5）hash 算法

來了一個(gè) key，首先計(jì)算 hash 值，然后對節(jié)點(diǎn)數(shù)取模。

然后打在不同的 master 節(jié)點(diǎn)上。一旦某一個(gè)master 節(jié)點(diǎn)宕機(jī)，所有請求過來，都會(huì)基于最新的剩余 master 節(jié)點(diǎn)數(shù)去取模，嘗試去取數(shù)據(jù)。

這會(huì)導(dǎo)致大部分的請求過來，全部無法拿到有效的緩存，導(dǎo)致大量的流量涌入數(shù)據(jù)庫。

6）一致性 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ī)制，即對每一個(gè)節(jié)點(diǎn)計(jì)算多個(gè) hash，每個(gè)計(jì)算結(jié)果位置都放置一個(gè)虛擬節(jié)點(diǎn)。這樣就實(shí)現(xiàn)了數(shù)據(jù)的均勻分布，負(fù)載均衡。

7）redis cluster 的 hash slot 算法

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

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

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

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

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

1）判斷節(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。

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

對宕機(jī)的 master node，從其所有的 slave node 中，選擇一個(gè)切換成 master node。檢查每個(gè) slave node 與 master node 斷開連接的時(shí)間，如果超過了 cluster-node-timeout *cluster-slave-validity-factor，那么就沒有資格切換成 master。

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

每個(gè)從節(jié)點(diǎn)，都根據(jù)自己對 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 的功能。

>> 面試常問問題二

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

1、面試官心理分析

其實(shí)這是問到緩存必問的，因?yàn)榫彺嫜┍篮痛┩福蔷彺孀畲蟮膬蓚€(gè)問題，要么不出現(xiàn)，一旦出現(xiàn)就是致命性的問題，所以面試官一定會(huì)問你。

2、面試題剖析

1）緩存雪崩

對于系統(tǒng) A，假設(shè)每天高峰期每秒 5000 個(gè)請求，本來緩存在高峰期可以扛住每秒 4000 個(gè)請求，但是緩存機(jī)器意外發(fā)生了全盤宕機(jī)。緩存掛了，此時(shí) 1 秒 5000 個(gè)請求全部落數(shù)據(jù)庫，數(shù)據(jù)庫必然扛不住，它會(huì)報(bào)一下警，然后就掛了。

此時(shí)，如果沒有采用什么特別的方案來處理這個(gè)故障，DBA 很著急，重啟數(shù)據(jù)庫，但是數(shù)據(jù)庫立馬又被新的流量給打死了。

這就是緩存雪崩。

大約在 3 年前，國內(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 限流&降級，避免 MySQL 被打死。- 事后：redis持久化，一旦重啟，自動(dòng)從磁盤上加載數(shù)據(jù)，快速恢復(fù)緩存數(shù)據(jù)。

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

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

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

2）緩存穿透

對于系統(tǒng) A，假設(shè)一秒 5000 個(gè)請求，結(jié)果其中 4000 個(gè)請求是黑客發(fā)出的惡意攻擊。黑客發(fā)出的那 4000 個(gè)攻擊，緩存中查不到，每次你去數(shù)據(jù)庫里查，也查不到。

舉個(gè)栗子。

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

解決方式很簡單，每次系統(tǒng) A 從數(shù)據(jù)庫中只要沒查到，就寫一個(gè)空值到緩存里去，比如 set -999 UNKNOWN。然后設(shè)置一個(gè)過期時(shí)間，這樣的話，下次有相同的 key 來訪問的時(shí)候，在緩存失效之前，都可以直接從緩存中取數(shù)據(jù)。

3）緩存擊穿

緩存擊穿，就是說某個(gè)key非常熱點(diǎn)，訪問非常頻繁，處于集中式高并發(fā)訪問的情況，當(dāng)這個(gè)key在失效的瞬間，大量的請求就擊穿了緩存，直接請求數(shù)據(jù)庫，就像是在一道屏障上鑿開了一個(gè)洞。

解決方式也很簡單，可以將熱點(diǎn)數(shù)據(jù)設(shè)置為永遠(yuǎn)不過期；或者基于 redis or zookeeper 實(shí)現(xiàn)互斥鎖，等待第一個(gè)請求構(gòu)建完緩存之后，再釋放鎖，進(jìn)而其它請求才能通過該 key 訪問數(shù)據(jù)。

>> 面試常問問題三：

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

1、面試官心理分析

你只要用緩存，就可能會(huì)涉及到緩存與數(shù)據(jù)庫雙存儲(chǔ)雙寫，你只要是雙寫，就一定會(huì)有數(shù)據(jù)一致性的問題，那么你如何解決一致性問題？

2、面試題剖析

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

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

1）Cache Aside Pattern

最經(jīng)典的緩存+數(shù)據(jù)庫讀寫的模式，就是 Cache Aside Pattern。- 讀的時(shí)候，先讀緩存，緩存沒有的話，就讀數(shù)據(jù)庫，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。- 更新的時(shí)候，先更新數(shù)據(jù)庫，然后再刪除緩存。

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

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

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

另外更新緩存的代價(jià)有時(shí)候是很高的。是不是說，每次修改數(shù)據(jù)庫的時(shí)候，都一定要將其對應(yīng)的緩存更新一份？也許有的場景是這樣，但是對于比較復(fù)雜的緩存數(shù)據(jù)計(jì)算的場景，就不是這樣了。

如果你頻繁修改一個(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è)員工。

2）最初級的緩存不一致問題及解決方案

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

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

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

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

完了，數(shù)據(jù)庫和緩存中的數(shù)據(jù)不一樣了……

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

只有在對一個(gè)數(shù)據(jù)在并發(fā)的進(jìn)行讀寫的時(shí)候，才可能會(huì)出現(xiàn)這種問題。其實(shí)如果說你的并發(fā)量很低的話，特別是讀并發(fā)很低，每天訪問量就 1 萬次，那么很少的情況下，會(huì)出現(xiàn)剛才描述的那種不一致的場景。

但是問題是，如果每天的是上億的流量，每秒并發(fā)讀是幾萬，每秒只要有數(shù)據(jù)更新的請求，就可能會(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ì)列對應(yīng)一個(gè)工作線程，每個(gè)工作線程串行拿到對應(yīng)的操作，然后一條一條的執(zhí)行。這樣的話一個(gè)數(shù)據(jù)變更的操作，先刪除緩存，然后再去更新數(shù)據(jù)庫，但是還沒完成更新。此時(shí)如果一個(gè)讀請求過來，沒有讀到緩存，那么可以先將緩存更新的請求發(fā)送到隊(duì)列中，此時(shí)會(huì)在隊(duì)列中積壓，然后同步等待緩存更新完成。

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

待那個(gè)隊(duì)列對應(yīng)的工作線程完成了上一個(gè)操作的數(shù)據(jù)庫的修改之后，才會(huì)去執(zhí)行下一個(gè)操作，也就是緩存更新的操作，此時(shí)會(huì)從數(shù)據(jù)庫中讀取最新的值，然后寫入緩存中。如果請求還在等待時(shí)間范圍內(nèi)，不斷輪詢發(fā)現(xiàn)可以取到值了，那么就直接返回；如果請求等待的時(shí)間超過一定時(shí)長，那么這一次直接從數(shù)據(jù)庫中讀取當(dāng)前的舊值。

4）高并發(fā)的場景下，該解決方案要注意的問題

•  讀請求長時(shí)阻塞

由于讀請求進(jìn)行了非常輕度的異步化，所以一定要注意讀超時(shí)的問題，每個(gè)讀請求必須在超時(shí)時(shí)間范圍內(nèi)返回。該解決方案，最大的風(fēng)險(xiǎn)點(diǎn)在于說，可能數(shù)據(jù)更新很頻繁，導(dǎo)致隊(duì)列中積壓了大量更新操作在里面，然后讀請求會(huì)發(fā)生大量的超時(shí)，最后導(dǎo)致大量的請求直接走數(shù)據(jù)庫。務(wù)必通過一些模擬真實(shí)的測試，看看更新數(shù)據(jù)的頻率是怎樣的。

另外一點(diǎn)，因?yàn)橐粋€(gè)隊(duì)列中，可能會(huì)積壓針對多個(gè)數(shù)據(jù)項(xiàng)的更新操作，因此需要根據(jù)自己的業(yè)務(wù)情況進(jìn)行測試，可能需要部署多個(gè)服務(wù)，每個(gè)服務(wù)分?jǐn)傄恍?shù)據(jù)的更新操作。

如果一個(gè)內(nèi)存隊(duì)列里居然會(huì)擠壓 100 個(gè)商品的庫存修改操作，每隔庫存修改操作要耗費(fèi) 10ms 去完成，那么最后一個(gè)商品的讀請求，可能等待 10 *100 = 1000ms = 1s后，才能得到數(shù)據(jù)，這個(gè)時(shí)候就導(dǎo)致讀請求的長時(shí)阻塞。

一定要做根據(jù)實(shí)際業(yè)務(wù)系統(tǒng)的運(yùn)行情況，去進(jìn)行一些壓力測試，和模擬線上環(huán)境，去看看最繁忙的時(shí)候，內(nèi)存隊(duì)列可能會(huì)擠壓多少更新操作，可能會(huì)導(dǎo)致最后一個(gè)更新操作對應(yīng)的讀請求，會(huì) hang 多少時(shí)間，如果讀請求在 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)該是很少的。像這種針對讀高并發(fā)、讀緩存架構(gòu)的項(xiàng)目，一般來說寫請求是非常少的，每秒的 QPS 能到幾百就不錯(cuò)了。

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

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

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

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

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

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

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

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

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

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

萬一某個(gè)商品的讀寫請求特別高，全部打到相同的機(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ì)高一些。

>> 面試常問問題四

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

1、面試官心理分析

這個(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 類的樂觀鎖方案。

2、面試題剖析

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

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

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

>> 面試常問問題五

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

1、面試官心理分析

看看你了解不了解你們公司的 redis 生產(chǎn)集群的部署架構(gòu)，如果你不了解，那么確實(shí)你就很失職了，你的redis 是主從架構(gòu)？集群架構(gòu)？用了哪種集群方案？有沒有做高可用保證？有沒有開啟持久化機(jī)制確保可以進(jìn)行數(shù)據(jù)恢復(fù)？線上 redis 給幾個(gè) G 的內(nèi)存？設(shè)置了哪些參數(shù)？壓測后你們 redis 集群承載多少Q(mào)PS？

兄弟，這些你必須是門兒清的，否則你確實(shí)是沒好好思考過。

2、面試題剖析

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)對外提供讀寫服務(wù)，每個(gè)節(jié)點(diǎn)的讀寫高峰 qps 可能可以達(dá)到每秒 5 萬，5 臺(tái)機(jī)器最多是 25 萬讀寫請求/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ī)器對外提供讀寫，一共有 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 左右的請求量。

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