全是干貨！本文主要討論這么幾個(gè)問題：
（1）啥時(shí)候數(shù)據(jù)庫和緩存中的數(shù)據(jù)會(huì)不一致
（2）不一致優(yōu)化思路
（3）如何保證數(shù)據(jù)庫與緩存的一致性
****一、需求緣起****
當(dāng)數(shù)據(jù)發(fā)生變化時(shí)柏卤，“先淘汰緩存县貌，再修改數(shù)據(jù)庫”這個(gè)點(diǎn)是大家討論的最多的缸夹。
得出這個(gè)結(jié)論的依據(jù)是痪寻，由于操作緩存與操作數(shù)據(jù)庫不是原子的螺句，非常有可能出現(xiàn)執(zhí)行失敗。
假設(shè)先寫數(shù)據(jù)庫橡类，再淘汰緩存：第一步寫數(shù)據(jù)庫操作成功蛇尚，第二步淘汰緩存失敗，則會(huì)出現(xiàn)DB中是新數(shù)據(jù)顾画，Cache中是舊數(shù)據(jù)取劫，數(shù)據(jù)不一致【如上圖：db中是新數(shù)據(jù)，cache中是舊數(shù)據(jù)】亲雪。
假設(shè)先淘汰緩存勇凭，再寫數(shù)據(jù)庫：第一步淘汰緩存成功，第二步寫數(shù)據(jù)庫失敗义辕，則只會(huì)引發(fā)一次Cache miss【如上圖：cache中無數(shù)據(jù)，db中是舊數(shù)據(jù)】寓盗。
結(jié)論：先淘汰緩存灌砖，再寫數(shù)據(jù)庫。
這里的討論的點(diǎn)是“先操作緩存傀蚌，在寫數(shù)據(jù)庫成功之前基显，如果有讀請(qǐng)求發(fā)生，可能導(dǎo)致舊數(shù)據(jù)入緩存善炫，引發(fā)數(shù)據(jù)不一致”撩幽，這就是本文要討論的主題。
二箩艺、為什么數(shù)據(jù)會(huì)不一致
回想一下對(duì)緩存窜醉、數(shù)據(jù)庫進(jìn)行讀寫操作的流程。
寫流程：
（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ā)的静汤，上游有多個(gè)應(yīng)用琅催，通過一個(gè)服務(wù)的多個(gè)部署（為了保證可用性，一定是部署多份的）虫给，對(duì)同一個(gè)數(shù)據(jù)進(jìn)行讀寫藤抡，在數(shù)據(jù)庫層面并發(fā)的讀寫并不能保證完成順序，也就是說后發(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)cache中是空的（如上圖中的步驟3）
（d）B的第二步讀取數(shù)據(jù)庫嫁佳，發(fā)出讀取請(qǐng)求挨队，此時(shí)A****的第二步寫數(shù)據(jù)還沒完成，讀出了一個(gè)臟數(shù)據(jù)放入cache（如上圖中的步驟4）
即在數(shù)據(jù)庫層面蒿往，后發(fā)出的請(qǐng)求4比先發(fā)出的請(qǐng)求2先完成了盛垦，讀出了臟數(shù)據(jù)，臟數(shù)據(jù)又入了緩存瓤漏，緩存與數(shù)據(jù)庫中的數(shù)據(jù)不一致出現(xiàn)了
三腾夯、不一致優(yōu)化思路
能否做到先發(fā)出的請(qǐng)求一定先執(zhí)行完成呢？常見的思路是“串行化”蔬充，今天將和大家一起探討“串行化”這個(gè)點(diǎn)蝶俱。
先一起細(xì)看一下，在一個(gè)服務(wù)中饥漫，并發(fā)的多個(gè)讀寫SQL一般是怎么執(zhí)行的
上圖是一個(gè)service服務(wù)的上下游及服務(wù)內(nèi)部詳細(xì)展開榨呆，細(xì)節(jié)如下：
（1）service的上游是多個(gè)業(yè)務(wù)應(yīng)用，上游發(fā)起請(qǐng)求對(duì)同一個(gè)數(shù)據(jù)并發(fā)的進(jìn)行讀寫操作庸队，上例中并發(fā)進(jìn)行了一個(gè)uid=1的余額修改（寫）操作與uid=1的余額查詢（讀）操作
（2）service的下游是數(shù)據(jù)庫DB积蜻，假設(shè)只讀寫一個(gè)DB
（3）中間是服務(wù)層service，它又分為了這么幾個(gè)部分
（3.1）最上層是任務(wù)隊(duì)列
（3.2）中間是工作線程彻消，每個(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連接放回DB連接池
}
提問：任務(wù)隊(duì)列其實(shí)已經(jīng)做了任務(wù)串行化的工作丙笋，能否保證任務(wù)不并發(fā)執(zhí)行？
答：不行煌贴，因?yàn)?/p>
（1）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í)行稳吮？
答：不行，原因同上
提問：假設(shè)1****個(gè)服務(wù)只有1****條數(shù)據(jù)庫連接井濒，能否保證任務(wù)不并發(fā)執(zhí)行灶似？
答：不行，因?yàn)?/p>
（1）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í)行的
提問：假設(shè)服務(wù)只部署一份，且1****個(gè)服務(wù)只有1****條連接者甲，能否保證任務(wù)不并發(fā)執(zhí)行春感？
答：可以，全局來看請(qǐng)求是串行執(zhí)行的瘤旨，吞吐量很低笆环，并且服務(wù)無法保證可用性
完了，看似無望了但狭，
1）任務(wù)隊(duì)列不能保證串行化
2）單服務(wù)多數(shù)據(jù)庫連接不能保證串行化
3）多服務(wù)單數(shù)據(jù)庫連接不能保證串行化
4）單服務(wù)單數(shù)據(jù)庫連接可能保證串行化窥岩，但吞吐量級(jí)低甲献，且不能保證服務(wù)的可用性，幾乎不可行颂翼，那是否還有解晃洒？
退一步想，其實(shí)不需要讓全局的請(qǐng)求串行化朦乏，而只需要“讓同一個(gè)數(shù)據(jù)的訪問能串行化”就行球及。
在一個(gè)服務(wù)內(nèi)，如何做到“讓同一個(gè)數(shù)據(jù)的訪問串行化”呻疹，只需要“讓同一個(gè)數(shù)據(jù)的訪問通過同一條DB連接執(zhí)行”就行吃引。
如何做到“讓同一個(gè)數(shù)據(jù)的訪問通過同一條DB連接執(zhí)行”，只需要“在DB連接池層面稍微修改诲宇，按數(shù)據(jù)取連接即可”
獲取DB連接的CPool.GetDBConnection()【返回任何一個(gè)可用DB連接】改為
CPool.GetDBConnection(longid)【返回id取模相關(guān)聯(lián)的DB連接】
這個(gè)修改的好處是：
（1）簡單际歼，只需要修改DB連接池實(shí)現(xiàn)，以及DB連接獲取處
（2）連接池的修改不需要關(guān)注業(yè)務(wù)姑蓝，傳入的id是什么含義連接池不關(guān)注，直接按照id取模返回DB連接即可
（3）可以適用多種業(yè)務(wù)場景吕粗，取用戶數(shù)據(jù)業(yè)務(wù)傳入user-id取連接纺荧，取訂單數(shù)據(jù)業(yè)務(wù)傳入order-id取連接即可
這樣的話，就能夠保證同一個(gè)數(shù)據(jù)例如uid在數(shù)據(jù)庫層面的執(zhí)行一定是串行的
稍等稍等颅筋，服務(wù)可是部署了很多份的宙暇，上述方案只能保證同一個(gè)數(shù)據(jù)在一個(gè)服務(wù)上的訪問，在DB層面的執(zhí)行是串行化的议泵，實(shí)際上服務(wù)是分布式部署的占贫，在全局范圍內(nèi)的訪問仍是并行的，怎么解決呢先口？能不能做到同一個(gè)數(shù)據(jù)的訪問一定落到同一個(gè)服務(wù)呢型奥？
四、能否做到同一個(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é)如下：
（1）業(yè)務(wù)應(yīng)用的上游不確定是啥谐宙，可能是直接是http請(qǐng)求烫葬，可能也是一個(gè)服務(wù)的上游調(diào)用
（2）業(yè)務(wù)應(yīng)用的下游是多個(gè)服務(wù)service
（3）中間是業(yè)務(wù)應(yīng)用，它又分為了這么幾個(gè)部分
（3.1）最上層是任務(wù)隊(duì)列【或許web-server例如tomcat幫你干了這個(gè)事情了】
（3.2）中間是工作線程【或許web-server的工作線程或者cgi工作線程幫你干了線程分派這個(gè)事情了】，每個(gè)工作線程完成實(shí)際的業(yè)務(wù)任務(wù)搭综，典型的工作任務(wù)是通過服務(wù)連接池進(jìn)行RPC調(diào)用
（3.3）最下層是服務(wù)連接池垢箕，所有的RPC調(diào)用都是通過服務(wù)連接池往下游服務(wù)去發(fā)包執(zhí)行的
工作線程的典型工作流是這樣的：
voidwork_thread_routine(){
Task t = TaskQueue.pop(); // 獲取任務(wù)
// 任務(wù)邏輯處理，組成一個(gè)網(wǎng)絡(luò)包packet兑巾，調(diào)用下游RPC接口
ServiceConnection c = CPool.GetServiceConnection(); // 從Service連接池獲取一個(gè)Service連接
c.Send(packet); // 通過Service連接發(fā)送報(bào)文執(zhí)行RPC請(qǐng)求
CPool.PutServiceConnection(c); // 將Service連接放回Service連接池
}
似曾相識(shí)吧条获？沒錯(cuò)，只要對(duì)服務(wù)連接池進(jìn)行少量改動(dòng)：
獲取Service連接的CPool.GetServiceConnection()【返回任何一個(gè)可用Service連接】改為
CPool.GetServiceConnection(longid)【返回id取模相關(guān)聯(lián)的Service連接】
這樣的話闪朱，就能夠保證同一個(gè)數(shù)據(jù)例如uid的請(qǐng)求落到同一個(gè)服務(wù)Service上月匣。
五、總結(jié)
由于數(shù)據(jù)庫層面的讀寫并發(fā)奋姿，引發(fā)的數(shù)據(jù)庫與緩存數(shù)據(jù)不一致的問題（本質(zhì)是后發(fā)生的讀請(qǐng)求先返回了）锄开，可能通過兩個(gè)小的改動(dòng)解決：
（1）修改服務(wù)Service連接池，id取模選取服務(wù)連接称诗，能夠保證同一個(gè)數(shù)據(jù)的讀寫都落在同一個(gè)后端服務(wù)上
（2）修改數(shù)據(jù)庫DB連接池萍悴，id取模選取DB連接，能夠保證同一個(gè)數(shù)據(jù)的讀寫在數(shù)據(jù)庫層面是串行的
六寓免、遺留問題
提問：取模訪問服務(wù)是否會(huì)影響服務(wù)的可用性癣诱？
答：不會(huì)，當(dāng)有下游服務(wù)掛掉的時(shí)候袜香，服務(wù)連接池能夠檢測到連接的可用性撕予，取模時(shí)要把不可用的服務(wù)連接排除掉。
提問：取模訪問服務(wù)****與 ****取模訪問DB****蜈首，是否會(huì)影響各連接上請(qǐng)求的負(fù)載均衡实抡？
答：不會(huì)，只要數(shù)據(jù)訪問id是均衡的欢策，從全局來看吆寨，由id取模獲取各連接的概率也是均等的，即負(fù)載是均衡的踩寇。
