后臺(tái)服務(wù)代碼架構(gòu)：項(xiàng)目實(shí)際應(yīng)用中redis緩存與數(shù)據(jù)庫一致性問題解決

1、redis 問題解決一、需求起因DB 中是新數(shù)據(jù)，Cache 中是新數(shù)據(jù)，cache 結(jié)論：先淘汰緩存，再寫數(shù)據(jù)庫。二、數(shù)據(jù)不一致原因不一致。寫流程：先淘汰cache再寫讀流程：先讀cache，如果數(shù)據(jù)命中hit則返回如果數(shù)據(jù)未命中missdb將db中讀取出來的數(shù)據(jù)入緩存什么情況下可能出現(xiàn)緩存和數(shù)據(jù)庫中數(shù)據(jù)不一致呢？（為了保證可用性，一定是部署多份的不能保證完成順序，也就是說后發(fā)出的讀請(qǐng)求很可能先完成（讀出臟數(shù)據(jù)：（a）發(fā)生了寫請(qǐng)求A，A 的第一步淘汰了cache（如上圖中的 1）（b）A 的第二步寫數(shù)據(jù)庫，發(fā)出修改請(qǐng)求（如上圖中的2）（c）發(fā)生了讀請(qǐng)求B，B 的第一步讀取cache，發(fā)現(xiàn)ca

2、che 中是空的（如上圖中的步驟 3）（d）B 的第二步讀取數(shù)據(jù)庫，發(fā)出讀取請(qǐng)求，此時(shí)A 的第二步寫數(shù)據(jù)還沒完成，讀出了一個(gè)臟數(shù)據(jù)放入cache（如上圖中的步驟 4）4 2 了緩存，緩存與數(shù)據(jù)庫中的數(shù)據(jù)不一致出現(xiàn)了三、問題解決思路能否做到先發(fā)出的請(qǐng)求一定先執(zhí)行完成呢？常見的思路是“串行化”上圖是一個(gè)service 服務(wù)的上下游及服務(wù)內(nèi)部詳細(xì)展開，細(xì)節(jié)如下：service 例中并發(fā)進(jìn)行了一個(gè)uid=1 的余額修改（寫）操作與uid=1 的余額查詢（讀）操作service的下游是數(shù)據(jù)庫DB，假設(shè)只讀寫一個(gè)DB中間是服務(wù)層service，它又分為了這么幾個(gè)部分（3.1）最上層是任務(wù)隊(duì)列（3.2）中間

3、是工作線程，每個(gè)工作線程完成實(shí)際的工作任務(wù)，典型的工作任務(wù)是通過數(shù)據(jù)庫連接池讀寫數(shù)據(jù)庫（3.3）最下層是數(shù)據(jù)庫連接池，所有的SQL 語句都是通過數(shù)據(jù)庫連接池發(fā)往數(shù)據(jù)庫去執(zhí)行的工作線程的典型工作流是這樣的：void work_thread_routine()Task t = TaskQueue.pop(); /獲取任務(wù)/任務(wù)邏輯處理，生成sql 語句DBConnection c = CPool.GetDBConnection(); /從 DB 連接池獲取一個(gè)DB 連接c.execSQL(sql); /通過 DB 連接執(zhí)行sql 語句CPool.PutDBConnection(c); /將 DB

4、連接放回DB 連接池提問：任務(wù)隊(duì)列其實(shí)已經(jīng)做了任務(wù)串行化的工作，能否保證任務(wù)不并發(fā)執(zhí)行？ 答：不行，因?yàn)椋?）1 個(gè)服務(wù)有多個(gè)工作線程，串行彈出的任務(wù)會(huì)被并行執(zhí)行（2）1 個(gè)服務(wù)有多個(gè)數(shù)據(jù)庫連接，每個(gè)工作線程獲取不同的數(shù)據(jù)庫連接會(huì)在DB 層面并發(fā)執(zhí)行提問：假設(shè)服務(wù)只部署一份，能否保證任務(wù)不并發(fā)執(zhí)行？ 答：不行，原因同上1 1 答：不行，因?yàn)椋?）1 個(gè)服務(wù)只有 1 條數(shù)據(jù)庫連接，只能保證在一個(gè)服務(wù)器上的請(qǐng)求在數(shù)據(jù)庫層面是串行執(zhí)行的（2）因?yàn)榉?wù)是分布式部署的，多個(gè)服務(wù)上的請(qǐng)求在數(shù)據(jù)庫層面仍可能是并發(fā)執(zhí)行的1 1 答：可以，全局來看請(qǐng)求是串行執(zhí)行的，吞吐量很低，并且服務(wù)無法保證可用性完了，看似無

5、望了，任務(wù)隊(duì)列不能保證串行化單服務(wù)多數(shù)據(jù)庫連接不能保證串行化多服務(wù)單數(shù)據(jù)庫連接不能保證串行化單服務(wù)單數(shù)據(jù)庫連接可能保證串行化，但吞吐量級(jí)低，且不能保證服務(wù)的可用性，幾乎不可行，那是否還有解？“在一個(gè)服務(wù)內(nèi)，如何做到“讓同一個(gè)數(shù)據(jù)的訪問串行化”，只需要“讓同一個(gè)數(shù)據(jù)的訪問通過 DB 就行。DB ”DB ”獲取 DB 連接的 CPool.GetDBConnection()【返回任何一個(gè)可用 DB 連接】改為CPool.GetDBConnection(longid)【返回 id 取模相關(guān)聯(lián)的 DB 連接】這個(gè)修改的好處是：DBDB連接獲取處id id DB連接即可可以適用多種業(yè)務(wù)場(chǎng)景，取用戶數(shù)據(jù)業(yè)務(wù)

6、傳入 user-id 取連接，取訂單數(shù)據(jù)業(yè)務(wù)傳入order-id 取連接即可這樣的話，就能夠保證同一個(gè)數(shù)據(jù)例如 uid 在數(shù)據(jù)庫層面的執(zhí)行一定是串行的DB 能否做到同一個(gè)數(shù)據(jù)的訪問落在同一個(gè)服務(wù)上？上面分析了服務(wù)層 service 的上下游及內(nèi)部結(jié)構(gòu)，再一起看一下應(yīng)用層上下游及內(nèi)部結(jié)構(gòu)上圖是一個(gè)業(yè)務(wù)應(yīng)用的上下游及服務(wù)內(nèi)部詳細(xì)展開，細(xì)節(jié)如下：業(yè)務(wù)應(yīng)用的上游不確定是啥，可能是直接是http請(qǐng)求，可能也是一個(gè)服務(wù)的上游調(diào)用service中間是業(yè)務(wù)應(yīng)用，它又分為了這么幾個(gè)部分（3.1）最上層是任務(wù)隊(duì)列【或許 web-server 例如 tomcat 幫你干了這個(gè)事情了】web-servercgiRPC

7、 調(diào)用（3.3）最下層是服務(wù)連接池，所有的RPC 的工作線程的典型工作流是這樣的：voidwork_thread_routine()Task t = TaskQueue.pop(); /獲取任務(wù)/任務(wù)邏輯處理，組成一個(gè)網(wǎng)絡(luò)包 packet，調(diào)用下游 RPC 接口ServiceConnection cCPool.GetServiceConnection(); 從Service 連接池獲取一個(gè)Service c.Send(packet); Service RPC 請(qǐng)求CPool.PutServiceConnection(c); /將 Service 連接放回 Service 連接池似曾相識(shí)吧？沒錯(cuò)，只要對(duì)服務(wù)連接池進(jìn)行少量改動(dòng)：Service CPool.GetServiceConnection()Service CPool.GetService