1. 程式人生 > >布式之數據庫和緩存雙寫一致性方案解析(轉)

布式之數據庫和緩存雙寫一致性方案解析(轉)

一段時間 其他 wechat 偽代碼 sql 讀寫 適合 scene mage

引言

為什麽寫這篇文章?

首先,緩存由於其高並發和高性能的特性,已經在項目中被廣泛使用。在讀取緩存方面,大家沒啥疑問,都是按照下圖的流程來進行業務操作。
技術分享圖片
但是在更新緩存方面,對於更新完數據庫,是更新緩存呢,還是刪除緩存。又或者是先刪除緩存,再更新數據庫,其實大家存在很大的爭議。目前沒有一篇全面的博客,對這幾種方案進行解析。於是博主戰戰兢兢,頂著被大家噴的風險,寫了這篇文章。

文章結構

本文由以下三個部分組成
1、講解緩存更新策略
2、對每種策略進行缺點分析
3、針對缺點給出改進方案

正文

先做一個說明,從理論上來說,給緩存設置過期時間,是保證最終一致性的解決方案。這種方案下,我們可以對存入緩存的數據設置過期時間,所有的寫操作以數據庫為準,對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功,緩存更新失敗,那麽只要到達過期時間,則後面的讀請求自然會從數據庫中讀取新值然後回填緩存。因此,接下來討論的思路不依賴於給緩存設置過期時間這個方案。
在這裏,我們討論三種

更新策略:

  1. 先更新數據庫,再更新緩存
  2. 先刪除緩存,再更新數據庫
  3. 先更新數據庫,再刪除緩存

應該沒人問我,為什麽沒有先更新緩存,再更新數據庫這種策略。

(1)先更新數據庫,再更新緩存

這套方案,大家是普遍反對的。為什麽呢?有如下兩點原因。
原因一(線程安全角度)
同時有請求A和請求B進行更新操作,那麽會出現
(1)線程A更新了數據庫
(2)線程B更新了數據庫
(3)線程B更新了緩存
(4)線程A更新了緩存
這就出現請求A更新緩存應該比請求B更新緩存早才對,但是因為網絡等原因,B卻比A更早更新了緩存。這就導致了臟數據,因此不考慮。
原因二(業務場景角度)
有如下兩點:
(1)如果你是一個寫數據庫場景比較多,而讀數據場景比較少的業務需求,采用這種方案就會導致,數據壓根還沒讀到,緩存就被頻繁的更新,浪費性能。
(2)如果你寫入數據庫的值,並不是直接寫入緩存的,而是要經過一系列復雜的計算再寫入緩存。那麽,每次寫入數據庫後,都再次計算寫入緩存的值,無疑是浪費性能的。顯然,刪除緩存更為適合。

接下來討論的就是爭議最大的,先刪緩存,再更新數據庫。還是先更新數據庫,再刪緩存的問題。

(2)先刪緩存,再更新數據庫

該方案會導致不一致的原因是。同時有一個請求A進行更新操作,另一個請求B進行查詢操作。那麽會出現如下情形:
(1)請求A進行寫操作,刪除緩存
(2)請求B查詢發現緩存不存在
(3)請求B去數據庫查詢得到舊值
(4)請求B將舊值寫入緩存
(5)請求A將新值寫入數據庫
上述情況就會導致不一致的情形出現。而且,如果不采用給緩存設置過期時間策略,該數據永遠都是臟數據。
那麽,如何解決呢?采用延時雙刪策略
偽代碼如下

public void write(String key,Object data){
        redis.delKey(key);
        db.updateData(data);
        Thread.sleep(1000);
        redis.delKey(key);
    }

轉化為中文描述就是
(1)先淘汰緩存
(2)再寫數據庫(這兩步和原來一樣)
(3)休眠1秒,再次淘汰緩存
這麽做,可以將1秒內所造成的緩存臟數據,再次刪除。
那麽,這個1秒怎麽確定的,具體該休眠多久呢?
針對上面的情形,讀者應該自行評估自己的項目的讀數據業務邏輯的耗時。然後寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上,加幾百ms即可。這麽做的目的,就是確保讀請求結束,寫請求可以刪除讀請求造成的緩存臟數據。
如果你用了mysql的讀寫分離架構怎麽辦?
ok,在這種情況下,造成數據不一致的原因如下,還是兩個請求,一個請求A進行更新操作,另一個請求B進行查詢操作。
(1)請求A進行寫操作,刪除緩存
(2)請求A將數據寫入數據庫了,
(3)請求B查詢緩存發現,緩存沒有值
(4)請求B去從庫查詢,這時,還沒有完成主從同步,因此查詢到的是舊值
(5)請求B將舊值寫入緩存
(6)數據庫完成主從同步,從庫變為新值
上述情形,就是數據不一致的原因。還是使用雙刪延時策略。只是,睡眠時間修改為在主從同步的延時時間基礎上,加幾百ms。
采用這種同步淘汰策略,吞吐量降低怎麽辦?
ok,那就將第二次刪除作為異步的。自己起一個線程,異步刪除。這樣,寫的請求就不用沈睡一段時間後了,再返回。這麽做,加大吞吐量。
第二次刪除,如果刪除失敗怎麽辦?
這是個非常好的問題,因為第二次刪除失敗,就會出現如下情形。還是有兩個請求,一個請求A進行更新操作,另一個請求B進行查詢操作,為了方便,假設是單庫:
(1)請求A進行寫操作,刪除緩存
(2)請求B查詢發現緩存不存在
(3)請求B去數據庫查詢得到舊值
(4)請求B將舊值寫入緩存
(5)請求A將新值寫入數據庫
(6)請求A試圖去刪除請求B寫入對緩存值,結果失敗了。
ok,這也就是說。如果第二次刪除緩存失敗,會再次出現緩存和數據庫不一致的問題。
如何解決呢?
具體解決方案,且看博主對第(3)種更新策略的解析。

(3)先更新數據庫,再刪緩存

首先,先說一下。老外提出了一個緩存更新套路,名為《Cache-Aside pattern》。其中就指出

  • 失效:應用程序先從cache取數據,沒有得到,則從數據庫中取數據,成功後,放到緩存中。
  • 命中:應用程序從cache中取數據,取到後返回。
  • 更新:先把數據存到數據庫中,成功後,再讓緩存失效。

另外,知名社交網站facebook也在論文《Scaling Memcache at Facebook》中提出,他們用的也是先更新數據庫,再刪緩存的策略。
這種情況不存在並發問題麽?
不是的。假設這會有兩個請求,一個請求A做查詢操作,一個請求B做更新操作,那麽會有如下情形產生
(1)緩存剛好失效
(2)請求A查詢數據庫,得一個舊值
(3)請求B將新值寫入數據庫
(4)請求B刪除緩存
(5)請求A將查到的舊值寫入緩存
ok,如果發生上述情況,確實是會發生臟數據。
然而,發生這種情況的概率又有多少呢?
發生上述情況有一個先天性條件,就是步驟(3)的寫數據庫操作比步驟(2)的讀數據庫操作耗時更短,才有可能使得步驟(4)先於步驟(5)。可是,大家想想,數據庫的讀操作的速度遠快於寫操作的(不然做讀寫分離幹嘛,做讀寫分離的意義就是因為讀操作比較快,耗資源少),因此步驟(3)耗時比步驟(2)更短,這一情形很難出現。
假設,有人非要擡杠,有強迫癥,一定要解決怎麽辦?
如何解決上述並發問題?
首先,給緩存設有效時間是一種方案。其次,采用策略(2)裏給出的異步延時刪除策略,保證讀請求完成以後,再進行刪除操作。
還有其他造成不一致的原因麽?
有的,這也是緩存更新策略(2)和緩存更新策略(3)都存在的一個問題,如果刪緩存失敗了怎麽辦,那不是會有不一致的情況出現麽。比如一個寫數據請求,然後寫入數據庫了,刪緩存失敗了,這會就出現不一致的情況了。這也是緩存更新策略(2)裏留下的最後一個疑問。
如何解決
提供一個保障的重試機制即可,這裏給出兩套方案。
方案一
如下圖所示
技術分享圖片
流程如下所示
(1)更新數據庫數據;
(2)緩存因為種種問題刪除失敗
(3)將需要刪除的key發送至消息隊列
(4)自己消費消息,獲得需要刪除的key
(5)繼續重試刪除操作,直到成功
然而,該方案有一個缺點,對業務線代碼造成大量的侵入。於是有了方案二,在方案二中,啟動一個訂閱程序去訂閱數據庫的binlog,獲得需要操作的數據。在應用程序中,另起一段程序,獲得這個訂閱程序傳來的信息,進行刪除緩存操作。
方案二
技術分享圖片
流程如下圖所示:
(1)更新數據庫數據
(2)數據庫會將操作信息寫入binlog日誌當中
(3)訂閱程序提取出所需要的數據以及key
(4)另起一段非業務代碼,獲得該信息
(5)嘗試刪除緩存操作,發現刪除失敗
(6)將這些信息發送至消息隊列
(7)重新從消息隊列中獲得該數據,重試操作。

備註說明:上述的訂閱binlog程序在mysql中有現成的中間件叫canal,可以完成訂閱binlog日誌的功能。至於oracle中,博主目前不知道有沒有現成中間件可以使用。另外,重試機制,博主是采用的是消息隊列的方式。如果對一致性要求不是很高,直接在程序中另起一個線程,每隔一段時間去重試即可,這些大家可以靈活自由發揮,只是提供一個思路。

總結

本文其實是對目前互聯網中已有的一致性方案,進行了一個總結。對於先刪緩存,再更新數據庫的更新策略,還有方案提出維護一個內存隊列的方式,博主看了一下,覺得實現異常復雜,沒有必要,因此沒有必要在文中給出。最後,希望大家有所收獲。

參考文獻

1、主從DB與cache一致性
2、緩存更新的套路

原文 https://www.cnblogs.com/rjzheng/p/9041659.html

布式之數據庫和緩存雙寫一致性方案解析(轉)