手機版 網站建設 網站設計 網站開發 網站制作 16年專業品質
  • 微信
    微信二維碼
  • 微博
  • 商城

緩存與數據庫一致性保證

作者:admin  發布時間:2020-07-16 09:19:13

本文主要討論這么幾個問題:

1)啥時候數據庫和緩存中的數據會不一致

2)不一致優化思路

3)如何保證數據庫與緩存的一致性

一、需求緣起

有一個結論:當數據發生變化時,“先淘汰緩存,再修改數據庫”這個點是大家討論的最多的。


得出這個結論的依據是,由于操作緩存與操作數據庫不是原子的,非常有可能出現執行失敗。


假設先寫數據庫,再淘汰緩存:第一步寫數據庫操作成功,第二步淘汰緩存失敗,則會出現DB中是新數據,Cache中是舊數據,數據不一致。

 


假設先淘汰緩存,再寫數據庫:第一步淘汰緩存成功,第二步寫數據庫失敗,則只會引發一次Cache miss

 

結論:先淘汰緩存,再寫數據庫。

 

引發大家熱烈討論的點是“先操作緩存,在寫數據庫成功之前,如果有讀請求發生,可能導致舊數據入緩存,引發數據不一致”,這就是本文要討論的主題。

 

二、為什么數據會不一致

回顧一下上一篇文章中對緩存、數據庫進行讀寫操作的流程。

寫流程:

1)先淘汰cache

2)再寫db

讀流程:

1)先讀cache,如果數據命中hit則返回

2)如果數據未命中miss則讀db

3)將db中讀取出來的數據入緩存

 

什么情況下可能出現緩存和數據庫中數據不一致呢?


在分布式環境下,數據的讀寫都是并發的,上游有多個應用,通過一個服務的多個部署(為了保證可用性,一定是部署多份的),對同一個數據進行讀寫,在數據庫層面并發的讀寫并不能保證完成順序,也就是說后發出的讀請求很可能先完成(讀出臟數據):

a)發生了寫請求AA的第一步淘汰了cache

bA的第二步寫數據庫,發出修改請求

c)發生了讀請求BB的第一步讀取cache,發現cache中是空的

dB的第二步讀取數據庫,發出讀取請求,此時A的第二步寫數據還沒完成,讀出了一個臟數據放入cache

在數據庫層面,后發出的請求4比先發出的請求2先完成了,讀出了臟數據,臟數據又入了緩存,緩存與數據庫中的數據不一致出現了

 

三、不一致優化思路

能否做到先發出的請求一定先執行完成呢?常見的思路是串行化,今天將和大家一起探討串行化這個點。

先一起細看一下,在一個服務中,并發的多個讀寫SQL一般是怎么執行的


上圖是一個service服務的上下游及服務內部詳細展開,細節如下:

1service的上游是多個業務應用,上游發起請求對同一個數據并發的進行讀寫操作,上例中并發進行了一個uid=1的余額修改(寫)操作與uid=1的余額查詢(讀)操作

2service的下游是數據庫DB,假設只讀寫一個DB

3)中間是服務層service,它又分為了這么幾個部分

3.1)最上層是任務隊列

3.2)中間是工作線程,每個工作線程完成實際的工作任務,典型的工作任務是通過數據庫連接池讀寫數據庫

3.3)最下層是數據庫連接池,所有的SQL語句都是通過數據庫連接池發往數據庫去執行的

 

工作線程的典型工作流是這樣的:

void work_thread_routine(){

Task t = TaskQueue.pop(); // 獲取任務

// 任務邏輯處理,生成sql語句

DBConnection c = CPool.GetDBConnection(); // DB連接池獲取一個DB連接

c.execSQL(sql); // 通過DB連接執行sql語句

CPool.PutDBConnection(c); // DB連接放回DB連接池

}

 

提問:任務隊列其實已經做了任務串行化的工作,能否保證任務不并發執行?

答:不行,因為

11個服務有多個工作線程,串行彈出的任務會被并行執行

21個服務有多個數據庫連接,每個工作線程獲取不同的數據庫連接會在DB層面并發執行

 

提問:假設服務只部署一份,能否保證任務不并發執行?

答:不行,原因同上

 

提問:假設1個服務只有1條數據庫連接,能否保證任務不并發執行?

答:不行,因為

11個服務只有1條數據庫連接,只能保證在一個服務器上的請求在數據庫層面是串行執行的

2)因為服務是分布式部署的,多個服務上的請求在數據庫層面仍可能是并發執行的

 

提問:假設服務只部署一份,且1個服務只有1條連接,能否保證任務不并發執行?

答:可以,全局來看請求是串行執行的,吞吐量很低,并且服務無法保證可用性

 

完了,看似無望了,

1)任務隊列不能保證串行化

2)單服務多數據庫連接不能保證串行化

3)多服務單數據庫連接不能保證串行化

4)單服務單數據庫連接可能保證串行化,但吞吐量級低,且不能保證服務的可用性,幾乎不可行,那是否還有解?

 

退一步想,其實不需要讓全局的請求串行化,而只需要“讓同一個數據的訪問能串行化”就行

在一個服務內,如何做到“讓同一個數據的訪問串行化”,只需要“讓同一個數據的訪問通過同一條DB連接執行”就行。

如何做到“讓同一個數據的訪問通過同一條DB連接執行”,只需要“在DB連接池層面稍微修改,按數據取連接即可”

獲取DB連接的CPool.GetDBConnection()【返回任何一個可用DB連接】改為

CPool.GetDBConnection(longid)【返回id取模相關聯的DB連接】

 

這個修改的好處是:

1)簡單,只需要修改DB連接池實現,以及DB連接獲取處

2)連接池的修改不需要關注業務,傳入的id是什么含義連接池不關注,直接按照id取模返回DB連接即可

3)可以適用多種業務場景,取用戶數據業務傳入user-id取連接,取訂單數據業務傳入order-id取連接即可

這樣的話,就能夠保證同一個數據例如uid在數據庫層面的執行一定是串行的

 

稍等稍等,服務可是部署了很多份的,上述方案只能保證同一個數據在一個服務上的訪問,在DB層面的執行是串行化的,實際上服務是分布式部署的,在全局范圍內的訪問仍是并行的,怎么解決呢?能不能做到同一個數據的訪問一定落到同一個服務呢?

 

四、能否做到同一個數據的訪問落在同一個服務上?

上面分析了服務層service的上下游及內部結構,再一起看一下應用層上下游及內部結構


上圖是一個業務應用的上下游及服務內部詳細展開,細節如下:

1)業務應用的上游不確定是啥,可能是直接是http請求,可能也是一個服務的上游調用

2)業務應用的下游是多個服務service

3)中間是業務應用,它又分為了這么幾個部分

3.1)最上層是任務隊列【或許web-server例如tomcat幫你干了這個事情了】

3.2)中間是工作線程【或許web-server的工作線程或者cgi工作線程幫你干了線程分派這個事情了】,每個工作線程完成實際的業務任務,典型的工作任務是通過服務連接池進行RPC調用

3.3)最下層是服務連接池,所有的RPC調用都是通過服務連接池往下游服務去發包執行的

 

工作線程的典型工作流是這樣的:

voidwork_thread_routine(){

Task t = TaskQueue.pop(); // 獲取任務

// 任務邏輯處理,組成一個網絡包packet,調用下游RPC接口

ServiceConnection c = CPool.GetServiceConnection(); // Service連接池獲取一個Service連接

c.Send(packet); // 通過Service連接發送報文執行RPC請求

CPool.PutServiceConnection(c); // Service連接放回Service連接池

}

 

似曾相識吧?沒錯,只要對服務連接池進行少量改動:

獲取Service連接的CPool.GetServiceConnection()【返回任何一個可用Service連接】改為

CPool.GetServiceConnection(longid)【返回id取模相關聯的Service連接】

這樣的話,就能夠保證同一個數據例如uid的請求落到同一個服務Service上。

                                                                                  

五、總結

由于數據庫層面的讀寫并發,引發的數據庫與緩存數據不一致的問題(本質是后發生的讀請求先返回了),可能通過兩個小的改動解決:

1)修改服務Service連接池,id取模選取服務連接,能夠保證同一個數據的讀寫都落在同一個后端服務上

2)修改數據庫DB連接池,id取模選取DB連接,能夠保證同一個數據的讀寫在數據庫層面是串行的

 

六、遺留問題

提問:取模訪問服務是否會影響服務的可用性?

答:不會,當有下游服務掛掉的時候,服務連接池能夠檢測到連接的可用性,取模時要把不可用的服務連接排除掉。

 

提問:取模訪問服務 取模訪問DB,是否會影響各連接上請求的負載均衡?

答:不會,只要數據訪問id是均衡的,從全局來看,由id取模獲取各連接的概率也是均等的,即負載是均衡的。

上一篇: MySQL使用不得不看的幾個小技巧 下一篇: MySql數據庫優化方案
返回列表
16年專業品質
互聯網品牌推廣專家
專業的建站、人機交互策劃、高端UI設計、移動應用開發公司
業務電話:020/22373839    15915747484
業務QQ:641589319
業務QQ:1375530069
廣州總部地址:廣東省廣州市越秀區先烈中路69號東山廣場2904室 郵編:510111
海極網絡微信二維碼
澳门百家乐代理_Welcome