本文主要討論這麼幾個問題：
（1）啥時候資料庫和快取中的資料會不一致
（2）不一致優化思路
（3）如何保證資料庫與快取的一致性
當資料發生變化時，「先淘汰快取，再修改資料庫」這個點是大家討論的最多的。
上篇文章得出這個結論的依據是，由於操作快取與運算元據庫不是原子的，非常有可能出現執行失敗。
假設先寫資料庫，再淘汰快取：第一步寫資料庫操作成功，第二步淘汰快取失敗，則會出現
db中是新資料，
cache
中是舊資料，資料不一致【如上圖：
db中是新資料，
cache
中是舊資料】。
假設先淘汰快取，再寫資料庫：第一步淘汰快取成功，第二步寫資料庫失敗，則只會引發一次
cache miss
【如上圖：
cache
中無資料，
db中是舊資料】。
結論：先淘汰快取，再寫資料庫。
引發大家熱烈討論的點是「先操作快取，在寫資料庫成功之前，如果有讀請求發生，可能導致舊資料入快取，引發資料不一致」，這就是本文要討論的主題。
寫流程：
（1）先淘汰cache
（2）再寫db
讀流程：
（1）先讀cache，如果資料命中hit則返回
（2）如果資料未命中miss則讀db
（3）將db中讀取出來的資料入快取
什麼情況下可能出現快取和資料庫中資料不一致呢？
在分布式環境下，資料的讀寫都是併發的，上游有多個應用，通過乙個服務的多個部署（為了保證可用性，一定是部署多份的），對同乙個資料進行讀寫，在資料庫層面併發的讀寫並不能保證完成順序，也就是說後發出的讀請求很可能先完成（讀出髒資料）：
（a）發生了寫請求a，a的第一步淘汰了cache（如上圖中的1）
（b）a的第二步寫資料庫，發出修改請求（如上圖中的2）
（c）發生了讀請求b，b的第一步讀取cache，發現cache中是空的（如上圖中的步驟3）
（d）b的第二步讀取資料庫，發出讀取請求，此時
a的第二步寫資料還沒完成
，讀出了乙個髒資料放入cache（如上圖中的步驟4） 即
在資料庫層面，後發出的請求4比先發出的請求2先完成了
，讀出了髒資料，髒資料又入了快取，快取與資料庫中的資料不一致出現了
能否做到先發出的請求一定先執行完成呢？
常見的思路是「序列化」，今天將和大家一起**「序列化」這個點。
先一起細看一下，在乙個服務中，併發的多個讀寫sql一般是怎麼執行的
上圖是乙個
service
服務的上下游及服務內部詳細展開，細節如下：
（1）service的上游是多個業務應用，上游發起請求對同乙個資料併發的進行讀寫操作，上例中併發進行了乙個uid=1的餘額修改（寫）操作與uid=1的餘額查詢（讀）操作
（2）service的下游是資料庫db，假設只讀寫乙個db
（3）中間是服務層service，它又分為了這麼幾個部分
（3.1）最上層是任務佇列
（3.2）中間是工作執行緒，每個工作執行緒完成實際的工作任務，典型的工作任務是通過資料庫連線池讀寫資料庫
（3.3）最下層是資料庫連線池，所有的sql語句都是通過資料庫連線池發往資料庫去執行的
工作執行緒的典型工作流是這樣的：
void work_thread_routine()
提問：任務佇列其實已經做了任務序列化的工作，能否保證任務不併發執行？
答：不行，因為
（1）1個服務有多個工作執行緒，序列彈出的任務會被並行執行
（2）1個服務有多個資料庫連線，每個工作執行緒獲取不同的資料庫連線會在db層面併發執行
提問：假設服務只部署乙份，能否保證任務不併發執行？
答：不行，原因同上
提問：假設1個服務只有1條資料庫連線，能否保證任務不併發執行？
答：不行，因為
（1）1個服務只有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()
似曾相識吧？沒錯，只要對服務連線池進行少量改動：
獲取service連線的cpool.getserviceconnection()【返回任何乙個可用service連線】改為
cpool.getserviceconnection(longid)【返回id取模相關聯的service連線】
這樣的話，就能夠保證同乙個資料例如uid的請求落到同乙個服務service上。
由於資料庫層面的讀寫併發，引發的資料庫與快取資料不一致的問題（本質是後發生的讀請求先返回了），可能通過兩個小的改動解決：
（1）修改服務service連線池，id取模選取服務連線，能夠保證同乙個資料的讀寫都落在同乙個後端服務上
（2）修改資料庫db連線池，id取模選取db連線，能夠保證同乙個資料的讀寫在資料庫層面是序列的
提問：取模訪問服務是否會影響服務的可用性？
答：不會，當有下游服務掛掉的時候，服務連線池能夠檢測到連線的可用性，取模時要把不可用的服務連線排除掉。
提問：取模訪問服務
與取模訪問db，是否會影響各連線上請求的負載均衡？
答：不會，只要資料訪問id是均衡的，從全域性來看，由id取模獲取各連線的概率也是均等的，即負載是均衡的。
資料庫與快取雙寫不一致問題分析與解決方案設計
一 說明 根據 cloud design patterns 一書中關於快取模式的 cache aside pattern 說明，其主要內容總結如下 二 資料庫與快取讀寫模式策略 2 如果寫資料庫的內容與更新到快取中的內容不一致，寫入快取中的資料需要經過幾個表的關聯計算後得到的結果插入快取中，那就沒有...
快取與資料庫不一致的問題
一 資料庫主從不一致 先回顧下，無快取時，資料庫主從不一致問題。如上圖，發生的場景是，寫後立刻讀 1 主庫乙個寫請求 主從沒同步完成 2 從庫接著乙個讀請求，讀到了舊資料 3 最後，主從同步完成 導致的結果是 主動同步完成之前，會讀取到舊資料。可以看到，主從不一致的影響時間很短，在主從同步完成後，就...
快取與資料庫雙寫不一致
在大併發下，多執行緒運算元據庫與快取會存在兩者資料不一致的問題。首先重要的是先更新資料庫，在失效快取。執行緒1先更新資料庫，將字段t改為6，然後將快取失效，執行緒結束。執行緒2過來讀資料庫，讀取到了t為6的資訊，在準備插入快取之前發生了執行緒排程，執行緒3過來更新資料庫，並且將快取失效後執行緒3結束...