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

（1）啥時候數(shù)據(jù)庫和緩存中的數(shù)據(jù)會不一致

（2）不一致優(yōu)化思路

（3）如何保證數(shù)據(jù)庫與緩存的一致性

一、需求緣起

---

上一篇《緩存架構(gòu)設計細節(jié)二三事》（點擊查看）引起了廣泛的討論，其中有一個結(jié)論：當數(shù)據(jù)發(fā)生變化時，“先淘汰緩存，再修改數(shù)據(jù)庫”這個點是大家討論的最多的。

上篇文章得出這個結(jié)論的依據(jù)是，由于操作緩存與操作數(shù)據(jù)庫不是原子的，非常有可能出現(xiàn)執(zhí)行失敗。

假設先寫數(shù)據(jù)庫，再淘汰緩存：第一步寫數(shù)據(jù)庫操作成功，第二步淘汰緩存失敗，則會出現(xiàn)DB中是新數(shù)據(jù)，Cache中是舊數(shù)據(jù)，數(shù)據(jù)不一致【如上圖：db中是新數(shù)據(jù)，cache中是舊數(shù)據(jù)】。

假設先淘汰緩存，再寫數(shù)據(jù)庫：第一步淘汰緩存成功，第二步寫數(shù)據(jù)庫失敗，則只會引發(fā)一次Cache miss【如上圖：cache中無數(shù)據(jù)，db中是舊數(shù)據(jù)】。

結(jié)論：先淘汰緩存，再寫數(shù)據(jù)庫。

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

二、為什么數(shù)據(jù)會不一致

---

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

寫流程：

（1）先淘汰cache

（2）再寫db

讀流程：

（1）先讀cache，如果數(shù)據(jù)命中hit則返回

（2）如果數(shù)據(jù)未命中miss則讀db

（3）將db中讀取出來的數(shù)據(jù)入緩存

什么情況下可能出現(xiàn)緩存和數(shù)據(jù)庫中數(shù)據(jù)不一致呢？

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

（a）發(fā)生了寫請求A，A的第一步淘汰了cache（如上圖中的1）

（b）A的第二步寫數(shù)據(jù)庫，發(fā)出修改請求（如上圖中的2）

（c）發(fā)生了讀請求B，B的第一步讀取cache，發(fā)現(xiàn)cache中是空的（如上圖中的步驟3）

（d）B的第二步讀取數(shù)據(jù)庫，發(fā)出讀取請求，此時A的第二步寫數(shù)據(jù)還沒完成，讀出了一個臟數(shù)據(jù)放入cache（如上圖中的步驟4）

即在數(shù)據(jù)庫層面，后發(fā)出的請求4比先發(fā)出的請求2先完成了，讀出了臟數(shù)據(jù)，臟數(shù)據(jù)又入了緩存，緩存與數(shù)據(jù)庫中的數(shù)據(jù)不一致出現(xiàn)了

三、不一致優(yōu)化思路

---

能否做到先發(fā)出的請求一定先執(zhí)行完成呢？常見的思路是“串行化”，今天將和大家一起探討“串行化”這個點。

先一起細看一下，在一個服務中，并發(fā)的多個讀寫SQL一般是怎么執(zhí)行的

上圖是一個service服務的上下游及服務內(nèi)部詳細展開，細節(jié)如下：

（1）service的上游是多個業(yè)務應用，上游發(fā)起請求對同一個數(shù)據(jù)并發(fā)的進行讀寫操作，上例中并發(fā)進行了一個uid=1的余額修改（寫）操作與uid=1的余額查詢（讀）操作

（2）service的下游是數(shù)據(jù)庫DB，假設只讀寫一個DB

（3）中間是服務層service，它又分為了這么幾個部分

     （3.1）最上層是任務隊列

     （3.2）中間是工作線程，每個工作線程完成實際的工作任務，典型的工作任務是通過數(shù)據(jù)庫連接池讀寫數(shù)據(jù)庫

     （3.3）最下層是數(shù)據(jù)庫連接池，所有的SQL語句都是通過數(shù)據(jù)庫連接池發(fā)往數(shù)據(jù)庫去執(zhí)行的

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

void work_thread_routine(){

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

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

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

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

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

}

提問：任務隊列其實已經(jīng)做了任務串行化的工作，能否保證任務不并發(fā)執(zhí)行？

答：不行，因為

（1）1個服務有多個工作線程，串行彈出的任務會被并行執(zhí)行

（2）1個服務有多個數(shù)據(jù)庫連接，每個工作線程獲取不同的數(shù)據(jù)庫連接會在DB層面并發(fā)執(zhí)行

提問：假設服務只部署一份，能否保證任務不并發(fā)執(zhí)行？

答：不行，原因同上

提問：假設1個服務只有1條數(shù)據(jù)庫連接，能否保證任務不并發(fā)執(zhí)行？

答：不行，因為

（1）1個服務只有1條數(shù)據(jù)庫連接，只能保證在一個服務器上的請求在數(shù)據(jù)庫層面是串行執(zhí)行的

（2）因為服務是分布式部署的，多個服務上的請求在數(shù)據(jù)庫層面仍可能是并發(fā)執(zhí)行的

提問：假設服務只部署一份，且1個服務只有1條連接，能否保證任務不并發(fā)執(zhí)行？

答：可以，全局來看請求是串行執(zhí)行的，吞吐量很低，并且服務無法保證可用性

完了，看似無望了，

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

2）單服務多數(shù)據(jù)庫連接不能保證串行化

3）多服務單數(shù)據(jù)庫連接不能保證串行化

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

退一步想，其實不需要讓全局的請求串行化，而只需要“讓同一個數(shù)據(jù)的訪問能串行化”就行。

在一個服務內(nèi)，如何做到“讓同一個數(shù)據(jù)的訪問串行化”，只需要“讓同一個數(shù)據(jù)的訪問通過同一條DB連接執(zhí)行”就行。

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

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

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

這個修改的好處是：

（1）簡單，只需要修改DB連接池實現(xiàn)，以及DB連接獲取處

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

（3）可以適用多種業(yè)務場景，取用戶數(shù)據(jù)業(yè)務傳入user-id取連接，取訂單數(shù)據(jù)業(yè)務傳入order-id取連接即可

這樣的話，就能夠保證同一個數(shù)據(jù)例如uid在數(shù)據(jù)庫層面的執(zhí)行一定是串行的

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

四、能否做到同一個數(shù)據(jù)的訪問落在同一個服務上？

---

上面分析了服務層service的上下游及內(nèi)部結(jié)構(gòu)，再一起看一下應用層上下游及內(nèi)部結(jié)構(gòu)

上圖是一個業(yè)務應用的上下游及服務內(nèi)部詳細展開，細節(jié)如下：

（1）業(yè)務應用的上游不確定是啥，可能是直接是http請求，可能也是一個服務的上游調(diào)用

（2）業(yè)務應用的下游是多個服務service

（3）中間是業(yè)務應用，它又分為了這么幾個部分

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

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

    （3.3）最下層是服務連接池，所有的RPC調(diào)用都是通過服務連接池往下游服務去發(fā)包執(zhí)行的

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

voidwork_thread_routine(){

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

     // 任務邏輯處理，組成一個網(wǎng)絡包packet，調(diào)用下游RPC接口

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

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

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

}

似曾相識吧？沒錯，只要對服務連接池進行少量改動：

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

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

這樣的話，就能夠保證同一個數(shù)據(jù)例如uid的請求落到同一個服務Service上。

五、總結(jié)

---

由于數(shù)據(jù)庫層面的讀寫并發(fā)，引發(fā)的數(shù)據(jù)庫與緩存數(shù)據(jù)不一致的問題（本質(zhì)是后發(fā)生的讀請求先返回了），可能通過兩個小的改動解決：

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

（2）修改數(shù)據(jù)庫DB連接池，id取模選取DB連接，能夠保證同一個數(shù)據(jù)的讀寫在數(shù)據(jù)庫層面是串行的

六、遺留問題

---

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

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

提問：取模訪問服務與 取模訪問DB，是否會影響各連接上請求的負載均衡？

答：不會，只要數(shù)據(jù)訪問id是均衡的，從全局來看，由id取模獲取各連接的概率也是均等的，即負載是均衡的。

提問：要是數(shù)據(jù)庫的架構(gòu)做了主從同步，讀寫分離：寫請求寫主庫，讀請求讀從庫也有可能導致緩存中進入臟數(shù)據(jù)呀，這種情況怎么解決呢（讀寫請求根本不落在同一個DB上，并且讀寫DB有同步時延）？

答：下一篇文章和大家分享。