一岳枷、數(shù)據(jù)不一致原因
先操作緩存肌割，在寫數(shù)據(jù)庫成功之前声滥，如果有讀請求發(fā)生眉撵，可能導致舊數(shù)據(jù)入緩存，引發(fā)數(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ā)的仰挣，上游有多個應用，通過一個服務(wù)的多個部署（為了保證可用性缠沈，一定是部署多份的），對同一個數(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)了
二沉帮、 問題解決思路
能否做到先發(fā)出的請求一定先執(zhí)行完成呢？常見的思路是“串行化”
上圖是一個service服務(wù)的上下游及服務(wù)內(nèi)部詳細展開贫堰，細節(jié)如下：
（1）service的上游是多個業(yè)務(wù)應用穆壕，上游發(fā)起請求對同一個數(shù)據(jù)并發(fā)的進行讀寫操作，上例中并發(fā)進行了一個uid=1的余額修改（寫）操作與uid=1的余額查詢（讀）操作
（2）service的下游是數(shù)據(jù)庫DB其屏，假設(shè)只讀寫一個DB
（3）中間是服務(wù)層service喇勋，它又分為了這么幾個部分
（3.1）最上層是任務(wù)隊列
（3.2）中間是工作線程，每個工作線程完成實際的工作任務(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連接池獲取一個DB連接
c.execSQL(sql); // 通過DB連接執(zhí)行sql語句
CPool.PutDBConnection(c); // 將DB連接放回DB連接池
}
提問：任務(wù)隊列其實已經(jīng)做了任務(wù)串行化的工作，能否保證任務(wù)不并發(fā)執(zhí)行渗常？
答：不行壮不，因為
（1）1個服務(wù)有多個工作線程，串行彈出的任務(wù)會被并行執(zhí)行
（2）1個服務(wù)有多個數(shù)據(jù)庫連接皱碘，每個工作線程獲取不同的數(shù)據(jù)庫連接會在DB層面并發(fā)執(zhí)行
提問：假設(shè)服務(wù)只部署一份询一，能否保證任務(wù)不并發(fā)執(zhí)行？
答：不行癌椿，原因同上
提問：假設(shè)1個服務(wù)只有1條數(shù)據(jù)庫連接健蕊，能否保證任務(wù)不并發(fā)執(zhí)行？
答：不行踢俄，因為
（1）1個服務(wù)只有1條數(shù)據(jù)庫連接缩功，只能保證在一個服務(wù)器上的請求在數(shù)據(jù)庫層面是串行執(zhí)行的
（2）因為服務(wù)是分布式部署的，多個服務(wù)上的請求在數(shù)據(jù)庫層面仍可能是并發(fā)執(zhí)行的
提問：假設(shè)服務(wù)只部署一份都办，且1個服務(wù)只有1條連接嫡锌，能否保證任務(wù)不并發(fā)執(zhí)行？
答：可以琳钉，全局來看請求是串行執(zhí)行的势木，吞吐量很低，并且服務(wù)無法保證可用性
完了歌懒，看似無望了啦桌，
1）任務(wù)隊列不能保證串行化
2）單服務(wù)多數(shù)據(jù)庫連接不能保證串行化
3）多服務(wù)單數(shù)據(jù)庫連接不能保證串行化
4）單服務(wù)單數(shù)據(jù)庫連接可能保證串行化，但吞吐量級低及皂，且不能保證服務(wù)的可用性甫男，幾乎不可行，那是否還有解验烧？
退一步想板驳，其實不需要讓全局的請求串行化，而只需要“讓同一個數(shù)據(jù)的訪問能串行化”就行碍拆。
在一個服務(wù)內(nèi)笋庄，如何做到“讓同一個數(shù)據(jù)的訪問串行化”，只需要“讓同一個數(shù)據(jù)的訪問通過同一條DB連接執(zhí)行”就行倔监。
如何做到“讓同一個數(shù)據(jù)的訪問通過同一條DB連接執(zhí)行”直砂，只需要“在DB連接池層面稍微修改，按數(shù)據(jù)取連接即可”
獲取DB連接的CPool.GetDBConnection()【返回任何一個可用DB連接】改為
CPool.GetDBConnection(longid)【返回id取模相關(guān)聯(lián)的DB連接】
這個修改的好處是：
（1）簡單浩习，只需要修改DB連接池實現(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取連接即可
這樣的話，就能夠保證同一個數(shù)據(jù)例如uid在數(shù)據(jù)庫層面的執(zhí)行一定是串行的
稍等稍等郊供，服務(wù)可是部署了很多份的峡碉，上述方案只能保證同一個數(shù)據(jù)在一個服務(wù)上的訪問，在DB層面的執(zhí)行是串行化的驮审，實際上服務(wù)是分布式部署的鲫寄，在全局范圍內(nèi)的訪問仍是并行的，怎么解決呢疯淫？能不能做到同一個數(shù)據(jù)的訪問一定落到同一個服務(wù)呢地来？
能否做到同一個數(shù)據(jù)的訪問落在同一個服務(wù)上？
上面分析了服務(wù)層service的上下游及內(nèi)部結(jié)構(gòu)熙掺，再一起看一下應用層上下游及內(nèi)部結(jié)構(gòu)
上圖是一個業(yè)務(wù)應用的上下游及服務(wù)內(nèi)部詳細展開未斑，細節(jié)如下：
（1）業(yè)務(wù)應用的上游不確定是啥，可能是直接是http請求币绩，可能也是一個服務(wù)的上游調(diào)用
（2）業(yè)務(wù)應用的下游是多個服務(wù)service
（3）中間是業(yè)務(wù)應用蜡秽，它又分為了這么幾個部分
（3.1）最上層是任務(wù)隊列【或許web-server例如tomcat幫你干了這個事情了】
（3.2）中間是工作線程【或許web-server的工作線程或者cgi工作線程幫你干了線程分派這個事情了】，每個工作線程完成實際的業(yè)務(wù)任務(wù)缆镣，典型的工作任務(wù)是通過服務(wù)連接池進行RPC調(diào)用
（3.3）最下層是服務(wù)連接池芽突，所有的RPC調(diào)用都是通過服務(wù)連接池往下游服務(wù)去發(fā)包執(zhí)行的
工作線程的典型工作流是這樣的：
voidwork_thread_routine(){
Task t = TaskQueue.pop(); // 獲取任務(wù)
// 任務(wù)邏輯處理，組成一個網(wǎng)絡(luò)包packet费就，調(diào)用下游RPC接口
ServiceConnection c = CPool.GetServiceConnection(); // 從Service連接池獲取一個Service連接
c.Send(packet); // 通過Service連接發(fā)送報文執(zhí)行RPC請求
CPool.PutServiceConnection(c); // 將Service連接放回Service連接池
}
似曾相識吧？沒錯川队，只要對服務(wù)連接池進行少量改動：
獲取Service連接的CPool.GetServiceConnection()【返回任何一個可用Service連接】改為
CPool.GetServiceConnection(longid)【返回id取模相關(guān)聯(lián)的Service連接】
這樣的話力细，就能夠保證同一個數(shù)據(jù)例如uid的請求落到同一個服務(wù)Service上。
由于數(shù)據(jù)庫層面的讀寫并發(fā)固额，引發(fā)的數(shù)據(jù)庫與緩存數(shù)據(jù)不一致的問題（本質(zhì)是后發(fā)生的讀請求先返回了）眠蚂，可能通過兩個小的改動解決：
（1）修改服務(wù)Service連接池，id取模選取服務(wù)連接斗躏，能夠保證同一個數(shù)據(jù)的讀寫都落在同一個后端服務(wù)上
（2）修改數(shù)據(jù)庫DB連接池逝慧，id取模選取DB連接，能夠保證同一個數(shù)據(jù)的讀寫在數(shù)據(jù)庫層面是串行的
