背景

緩存是軟件開(kāi)發(fā)中一個(gè)非常有用的概念，數(shù)據(jù)庫(kù)緩存更是在項(xiàng)目中必然會(huì)遇到的場(chǎng)景。而緩存一致性的保證，更是在面試中被反復(fù)問(wèn)到，這里進(jìn)行一下總結(jié)，針對(duì)不同的要求，選擇恰到好處的一致性方案。

緩存是什么

存儲(chǔ)的速度是有區(qū)別的。緩存就是把低速存儲(chǔ)的結(jié)果，臨時(shí)保存在高速存儲(chǔ)的技術(shù)。

如圖所示，金字塔更上面的存儲(chǔ)，可以作為下面存儲(chǔ)的緩存。

我們本次的討論，主要針對(duì)數(shù)據(jù)庫(kù)緩存場(chǎng)景，將以redis作為mysql的緩存為案例來(lái)進(jìn)行。

為什么需要緩存

存儲(chǔ)如mysql通常支持完整的ACID特性，因?yàn)榭煽啃?，持久性等因素，性能普遍不高，高并發(fā)的查詢會(huì)給mysql帶來(lái)壓力，造成數(shù)據(jù)庫(kù)系統(tǒng)的不穩(wěn)定。同時(shí)也容易產(chǎn)生延遲。

根據(jù)局部性原理，80%請(qǐng)求會(huì)落到20%的熱點(diǎn)數(shù)據(jù)上，在讀多寫(xiě)少場(chǎng)景，增加一層緩存非常有助提升系統(tǒng)吞吐量和健壯性。

存在問(wèn)題

存儲(chǔ)的數(shù)據(jù)隨著時(shí)間可能會(huì)發(fā)生變化，而緩存中的數(shù)據(jù)就會(huì)不一致。具體能容忍的不一致時(shí)間，需要具體業(yè)務(wù)具體分析，但是通常的業(yè)務(wù)，都需要做到最終一致。

redis作為mysql緩存

通常的開(kāi)發(fā)模式中，都會(huì)使用mysql作為存儲(chǔ)，而redis作為緩存，加速和保護(hù)mysql。但是，當(dāng)mysql數(shù)據(jù)更新之后，redis怎么保持同步呢。

強(qiáng)一致性同步成本太高，如果追求強(qiáng)一致，那么沒(méi)必要用緩存了，直接用mysql即可。通?？紤]的，都是最終一致性。

解決方案

方案一

通過(guò)key的過(guò)期時(shí)間，mysql更新時(shí)，redis不更新。

這種方式實(shí)現(xiàn)簡(jiǎn)單，但不一致的時(shí)間會(huì)很長(zhǎng)。如果讀請(qǐng)求非常頻繁，且過(guò)期時(shí)間比較長(zhǎng)，則會(huì)產(chǎn)生很多長(zhǎng)期的臟數(shù)據(jù)。

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

• 開(kāi)發(fā)成本低，易于實(shí)現(xiàn)；

• 管理成本低，出問(wèn)題的概率會(huì)比較小。

不足：

• 完全依賴過(guò)期時(shí)間，時(shí)間太短容易緩存頻繁失效，太長(zhǎng)容易有長(zhǎng)時(shí)間更新延遲（不一致）

方案二

在方案一的基礎(chǔ)上擴(kuò)展，通過(guò)key的過(guò)期時(shí)間兜底，并且，在更新mysql時(shí)，同時(shí)更新redis。

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

• 相對(duì)方案一，更新延遲更小。

不足：

• 如果更新mysql成功，更新redis卻失敗，就退化到了方案一；

• 在高并發(fā)場(chǎng)景，業(yè)務(wù)server需要和mysql,redis同時(shí)進(jìn)行連接。這樣是損耗雙倍的連接資源，容易造成連接數(shù)過(guò)多的問(wèn)題。

方案三

針對(duì)方案二的同步寫(xiě)redis進(jìn)行優(yōu)化，增加消息隊(duì)列，將redis更新操作交給kafka，由消息隊(duì)列保證可靠性，再搭建一個(gè)消費(fèi)服務(wù)，來(lái)異步更新redis。

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

• 消息隊(duì)列可以用一個(gè)句柄，很多消息隊(duì)列客戶端還支持本地緩存發(fā)送，有效解決了方案二連接數(shù)過(guò)多的問(wèn)題；

• 使用消息隊(duì)列，實(shí)現(xiàn)了邏輯上的解耦；

• 消息隊(duì)列本身具有可靠性，通過(guò)手動(dòng)提交等手段，可以至少一次消費(fèi)到redis。

不足：

• 依舊解決不了時(shí)序性問(wèn)題，如果多臺(tái)業(yè)務(wù)服務(wù)器分別處理針對(duì)同一行數(shù)據(jù)的兩條請(qǐng)求，舉個(gè)栗子，a = 1；a = 5; 如果mysql中是第一條先執(zhí)行，而進(jìn)入kafka的順序是第二條先執(zhí)行，那么數(shù)據(jù)就會(huì)產(chǎn)生不一致。

• 引入了消息隊(duì)列，同時(shí)要增加服務(wù)消費(fèi)消息，成本較高，還有重復(fù)消費(fèi)的風(fēng)險(xiǎn)。

方案四

通過(guò)訂閱binlog來(lái)更新redis，把我們搭建的消費(fèi)服務(wù)，作為mysql的一個(gè)slave，訂閱binlog，解析出更新內(nèi)容，再更新到redis。

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

• 在mysql壓力不大情況下，延遲較低；

• 和業(yè)務(wù)完全解耦；

• 解決了時(shí)序性問(wèn)題。

缺點(diǎn)：

• 要單獨(dú)搭建一個(gè)同步服務(wù)，并且引入binlog同步機(jī)制，成本較大。

總結(jié)

方案選型

首先確認(rèn)產(chǎn)品上對(duì)延遲性的要求，如果要求極高，且數(shù)據(jù)有可能變化，別用緩存。

通常來(lái)說(shuō)，方案1就夠了，筆者咨詢過(guò)4，5個(gè)團(tuán)隊(duì)，基本都是用方案1，因?yàn)槟苡镁彺娣桨?，通常是讀多寫(xiě)少場(chǎng)景，同時(shí)業(yè)務(wù)上對(duì)延遲具有一定的包容性。方案1沒(méi)有開(kāi)發(fā)成本，其實(shí)比較實(shí)用。

如果想增加更新時(shí)的即時(shí)性，就選擇方案2，不過(guò)沒(méi)必要做重試保證之類的。

方案3，方案4針對(duì)于對(duì)延時(shí)要求比較高業(yè)務(wù)，一個(gè)是推模式，一個(gè)是拉模式，而方案4具備更強(qiáng)的可靠性，既然都愿意花功夫做處理消息的邏輯，不如一步到位，用方案4。

結(jié)論

一般情況，方案1夠用。若延時(shí)要求高，直接選擇方案4。如果是面試場(chǎng)景，從簡(jiǎn)單講到復(fù)雜，面試官會(huì)一步一步追問(wèn)，咱們就一點(diǎn)點(diǎn)推導(dǎo)，賓主盡歡。