【163期】面試官：你能談?wù)剶?shù)據(jù)庫實現(xiàn)緩存最終一致性的一些方法嗎？

程序員的成長之路

互聯(lián)網(wǎng)/程序員/技術(shù)/資料共享 

閱讀本文大概需要 3.5 分鐘。

來自：https://juejin.im/post/6844903929281511438

背景

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

緩存是什么

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

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

我們本次的討論，主要針對數(shù)據(jù)庫緩存場景，將以redis作為mysql的緩存為案例來進行。

為什么需要緩存

存儲如mysql通常支持完整的ACID特性，因為可靠性，持久性等因素，性能普遍不高，高并發(fā)的查詢會給mysql帶來壓力，造成數(shù)據(jù)庫系統(tǒng)的不穩(wěn)定。同時也容易產(chǎn)生延遲。根據(jù)局部性原理，80%請求會落到20%的熱點數(shù)據(jù)上，在讀多寫少場景，增加一層緩存非常有助提升系統(tǒng)吞吐量和健壯性。

存在問題

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

redis作為mysql緩存

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

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

解決方案

方案一

通過key的過期時間，mysql更新時，redis不更新。這種方式實現(xiàn)簡單，但不一致的時間會很長。如果讀請求非常頻繁，且過期時間比較長，則會產(chǎn)生很多長期的臟數(shù)據(jù)。

優(yōu)點：

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

• 管理成本低，出問題的概率會比較小。

不足

• 完全依賴過期時間，時間太短容易緩存頻繁失效，太長容易有長時間更新延遲（不一致）

方案二

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

優(yōu)點

• 相對方案一，更新延遲更小。

不足

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

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

方案三

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

優(yōu)點

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

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

• 消息隊列本身具有可靠性，通過手動提交等手段，可以至少一次消費到redis。

不足

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

• 引入了消息隊列，同時要增加服務(wù)消費消息，成本較高。

方案四

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

優(yōu)點

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

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

• 解決了時序性問題。

缺點

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

總結(jié)

方案選型

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

2. 通常來說，方案1就夠了，筆者咨詢過4，5個團隊，基本都是用方案1，因為能用緩存方案，通常是讀多寫少場景，同時業(yè)務(wù)上對延遲具有一定的包容性。方案1沒有開發(fā)成本，其實比較實用。

3. 如果想增加更新時的即時性，就選擇方案2，不過沒必要做重試保證之類的。

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

結(jié)論

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

<END>

掃碼加入技術(shù)交流群，不定時「送書」

推薦閱讀：

【162期】一些Redis面試題及分布式集群面試考點整理

【161期】面試不愁，給你一份SpringBoot常用注解

【160期】面試官：你能說出Springboot項目啟動的幾種方式嗎？

5T技術(shù)資源大放送！包括但不限于：C/C++，Linux，Python，Java，PHP，人工智能，單片機，樹莓派，等等。在公眾號內(nèi)回復(fù)「2048」，即可免費獲取??！

微信掃描二維碼，關(guān)注我的公眾號

朕已閱