一致性概述
在分布式系統中,可以理解為多個節點中數據的值相同.
強一致性:這種一致性級別是最符合用戶直覺的,它要求系統寫入什么,讀出來的就是什么,用戶體驗好,但往往對系統的性能影響很大.
弱一致性:這種一致性級別約束了系統在寫入成功后,不承諾立即可以讀到寫入的值,也不承諾多久以后數據能夠達到一致,但會盡可能地保證到某個時間級別(比如秒級別)后,數據能夠達到一致狀態.
最終一致性:最終一致性是弱一致性的一個特例,系統會保證在一定時間內,能夠達到一個數據一致的狀態.將最終一致性單獨提出來,是因為它是弱一致性中非常推崇的一致性模型,也是業界在大型分布式系統的數據一致性上比較推崇的模型.
緩存的模式
緩存可以提升性能,緩解數據庫壓力,但使用緩存也會導致數據不一致性的問題.我們是如何使用緩存呢,有三種經典的緩存模式:
Cache-Aside Pattern Read-Through/Write through Write behind
Cache-Aside Pattern
Cache-Aside Pattern,即旁路緩存模式,它的提出是為了盡可能地解決緩存與數據庫的數據不一致問題.
Cache-Aside Pattern讀流程
Cache-Aside Pattern讀請求流程如下:
讀的時候,先讀緩存,緩存命中的話,直接返回數據.
緩存沒有命中的話,就去讀數據庫,從數據庫取出數據,放入緩存后,同時返回響應.
Cache-Aside Pattern寫流程
更新的時候,先更新數據庫,然后再刪除緩存.
Read/Write Through模式中,服務端把緩存作為主要數據存儲.應用程序跟數據庫緩存交互,都是通過抽象緩存層完成的.
Read-Through
Read-Through的簡要流程如下:
從緩存讀取數據,讀到直接返回如果讀取不到的話,從數據庫加載,寫入緩存后,再返回響應.
這個簡要流程是不是跟Cache-Aside很像,其實Read-Through就是多了一層Cache-Provider,流程如下:
Write-Through
Write-Through模式下,當發生寫請求時,由緩存抽象層完成數據源和緩存數據的更新,流程如下:
Write behind(異步緩存寫入)
Write behind跟Read-Through/Write-Through有相似的地方,都是Cache Provider來負責緩存和數據庫的讀寫.兩者的不同:Read/Write Through是同步更新緩存和數據的,Write Behind則是只更新緩存,不直接更新數據庫,通過批量異步的方式來更新數據庫.
這種方式下,緩存和數據庫的一致性不強,對一致性要求高的系統要謹慎使用.但是它適合頻繁寫的場景,mysql的innodb buffer pool機制就使用到這種模式.
數據的處理
操作緩存時,是刪除緩存呢,還是更新緩存呢.
一般場景,我們使用Cache-Aside模式.有人可能會問,Cache-Aside在寫入請求時,為什么是刪除緩存而不是更新緩存呢.
我們先來看個例子:
線程A先發起一個寫操作,第一步先更新數據庫.
線程B再發起一個寫操作,第二步更新了數據庫
由於網絡等原因,線程B先更新了緩存,線程A后更新緩存.
這時候,緩存保存的是A的數據(老數據),數據庫保存的是B的數據(新數據),數據不一致了,臟數據出現.如果是刪除緩存取代更新緩存則不會出現這個臟數據問題.
更新緩存相對於刪除緩存,還有兩點劣勢:
如果你寫入的緩存值,是經過復雜計算才得到的話,更新緩存頻率高的話,就浪費性能啦.
在寫數據庫場景多,讀數據場景少的情況下,數據很多時候還沒被讀取到,又被更新了,浪費了性能(實際上,寫多的場景,用緩存不很划算)
雙寫情況下,先操作數據庫還是先操作緩存呢.
Cache-Aside緩存模式中,在寫入請求時,為什么是先操作數據庫呢,而不是先操作緩存呢.
假設有A,B兩個請求,請求A做更新操作,請求B做查詢讀取操作.
線程a發起一個寫操作,第一步del cache
線程b發起一個讀操作,cache miss
線程b繼續讀db,讀出來個老數據
然后線程b把老數據設置入cache
線程a寫入db最新的數據
此時就有問題,緩存和數據庫的數據不一致.緩存保存老數據,數據庫保存新數據.因此,Cache-Aside緩存模式,選擇了先操作數據庫而不是先操作緩存.
緩存延時雙刪
先刪除緩存,再更新數據庫.采用緩存延時雙刪策略.
先刪除緩存再更新數據庫休眠一會(比如1秒),再次刪除緩存.
這個休眠一會,一般多久呢,都是1秒.
休眠時間=讀業務邏輯數據的耗時+幾百毫秒.為了確保讀請求結束,寫請求可以刪除讀請求可能帶來的緩存臟數據.
延時雙刪的方案的思路是,為了避免更新數據庫時,其他線程從緩存中讀取不到數據,就在更新完數據庫后,再sleep一段時間,然后再次刪除緩存.sleep的時間要對業務讀寫緩存的時間做出評估,sleep時間大於讀寫緩存的時間即可.
流程如下:
線程1刪除緩存,然后去更新數據庫.
線程2來讀緩存,發現緩存已經被刪除,所以直接從數據庫中讀取,這時候由於線程1還沒有更新完成,所以讀到的是舊值,然后把舊值寫入緩存.
線程1,根據估算的時間sleep,由於sleep的時間大於線程2讀數據+寫緩存的時間,所以緩存被再次刪除.
如果還有其他線程來讀取緩存的話,就會再次從數據庫中讀取到最新值.
刪除緩存重試機制
不管是延時雙刪還是Cache-Aside的先操作數據庫再刪除緩存,如果第二步的刪除緩存失敗,刪除失敗會導致臟數據.
刪除失敗就多刪除幾次,保證刪除緩存成功,所以可以引入刪除緩存重試機制.
寫請求更新數據庫
緩存因為某些原因,刪除失敗
把刪除失敗的key放到消息隊列,
消費消息隊列的消息,獲取要刪除的key
重試刪除緩存操作
讀取biglog異步刪除緩存
重試刪除緩存機制還可以通過數據庫的binlog來異步淘汰key.
以mysql為例,可以使用阿里的canal將binlog日志采集發送到MQ隊列里面,然后通過ACK機制確認處理這條更新消息,刪除緩存,保證數據緩存一致性.
通用解決方案
建議優先使用刪除緩存重試機制,即更新數據庫,再次進行刪除緩存.
如果刪除緩存失敗,那么可以在程序中重試刪除,可以將刪除緩存的數據扔到消息隊列中刪除,或者可以使用binlog異步刪除,或者可以使用延遲雙刪.上面四種方案做再次刪除確認,如果依舊刪除失敗.那么就按照緩存的失效時間讓緩存自動失效.
在程序中重試幾次刪除,刪除失敗,按照失效時間自動失效.
刪除的數據扔到消息隊列,存在延遲,業務能否接受.
使用binlog異步刪除,解除和業務的耦合.
使用延遲雙刪,其中睡眠時間和並發量是思考關鍵,導致接口性能不高,影響接口吞吐量.高並發場景不建議使用該策略.