參考：
https://www.cnblogs.com/rjzheng/p/9041659.html
https://blog.csdn.net/chang384915878/article/details/86756463
【原創】分布式之數據庫和緩存雙寫一致性方案解析
引言
為什么寫這篇文章？
首先，緩存由於其高並發和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。
但是在更新緩存方面，對於更新完數據庫，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數據庫，其實大家存在很大的爭議。目前沒有一篇全面的博客，對這幾種方案進行解析。於是博主戰戰兢兢，頂着被大家噴的風險，寫了這篇文章。
文章結構
本文由以下三個部分組成
1、講解緩存更新策略
2、對每種策略進行缺點分析
3、針對缺點給出改進方案
正文
先做一個說明，從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫為准，對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功，緩存更新失敗，那么只要到達過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴於給緩存設置過期時間這個方案。
在這里，我們討論三種更新策略：
- 先更新數據庫，再更新緩存
- 先刪除緩存，再更新數據庫
- 先更新數據庫，再刪除緩存
應該沒人問我，為什么沒有先更新緩存，再更新數據庫這種策略。
(1)先更新數據庫，再更新緩存
這套方案，大家是普遍反對的。為什么呢？有如下兩點原因。
原因一（線程安全角度）
同時有請求A和請求B進行更新操作，那么會出現
（1）線程A更新了數據庫
（2）線程B更新了數據庫
（3）線程B更新了緩存
（4）線程A更新了緩存
這就出現請求A更新緩存應該比請求B更新緩存早才對，但是因為網絡等原因，B卻比A更早更新了緩存。這就導致了臟數據，因此不考慮。
原因二（業務場景角度）
有如下兩點：
（1）如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，采用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
（2）如果你寫入數據庫的值，並不是直接寫入緩存的，而是要經過一系列復雜的計算再寫入緩存。那么，每次寫入數據庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。
接下來討論的就是爭議最大的，先刪緩存，再更新數據庫。還是先更新數據庫，再刪緩存的問題。
(2)先刪緩存，再更新數據庫
該方案會導致不一致的原因是。同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形:
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發現緩存不存在
（3）請求B去數據庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數據庫
上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。
那么，如何解決呢？采用延時雙刪策略
偽代碼如下
public void write(String key,Object data){ redis.delKey(key); db.updateData(data); Thread.sleep(1000); redis.delKey(key); } 轉化為中文描述就是
（1）先淘汰緩存
（2）再寫數據庫（這兩步和原來一樣）
（3）休眠1秒，再次淘汰緩存
這么做，可以將1秒內所造成的緩存臟數據，再次刪除。
那么，這個1秒怎么確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的項目的讀數據業務邏輯的耗時。然后寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上，加幾百ms即可。這么做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數據。
如果你用了mysql的讀寫分離架構怎么辦？
ok，在這種情況下，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
（1）請求A進行寫操作，刪除緩存
（2）請求A將數據寫入數據庫了，
（3）請求B查詢緩存發現，緩存沒有值
（4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求B將舊值寫入緩存
（6）數據庫完成主從同步，從庫變為新值
上述情形，就是數據不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。
采用這種同步淘汰策略，吞吐量降低怎么辦？
ok，那就將第二次刪除作為異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間后了，再返回。這么做，加大吞吐量。
第二次刪除,如果刪除失敗怎么辦？
這是個非常好的問題，因為第二次刪除失敗，就會出現如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，為了方便，假設是單庫：
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發現緩存不存在
（3）請求B去數據庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數據庫
（6）請求A試圖去刪除請求B寫入對緩存值，結果失敗了。
ok,這也就是說。如果第二次刪除緩存失敗，會再次出現緩存和數據庫不一致的問題。
如何解決呢？
具體解決方案，且看博主對第(3)種更新策略的解析。
(3)先更新數據庫，再刪緩存
首先，先說一下。老外提出了一個緩存更新套路，名為《Cache-Aside pattern》。其中就指出
- 失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
- 命中：應用程序從cache中取數據，取到后返回。
- 更新：先把數據存到數據庫中，成功后，再讓緩存失效。
另外，知名社交網站facebook也在論文《Scaling Memcache at Facebook》中提出，他們用的也是先更新數據庫，再刪緩存的策略。
這種情況不存在並發問題么？
不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那么會有如下情形產生
（1）緩存剛好失效
（2）請求A查詢數據庫，得一個舊值
（3）請求B將新值寫入數據庫
（4）請求B刪除緩存
（5）請求A將查到的舊值寫入緩存
ok，如果發生上述情況，確實是會發生臟數據。
然而，發生這種情況的概率又有多少呢？
發生上述情況有一個先天性條件，就是步驟（3）的寫數據庫操作比步驟（2）的讀數據庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。可是，大家想想，數據庫的讀操作的速度遠快於寫操作的（不然做讀寫分離干嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。
假設，有人非要抬杠，有強迫症，一定要解決怎么辦？
如何解決上述並發問題？
首先，給緩存設有效時間是一種方案。其次，采用策略（2）里給出的異步延時刪除策略，保證讀請求完成以后，再進行刪除操作。
還有其他造成不一致的原因么？
有的，這也是緩存更新策略（2）和緩存更新策略（3）都存在的一個問題，如果刪緩存失敗了怎么辦，那不是會有不一致的情況出現么。比如一個寫數據請求，然后寫入數據庫了，刪緩存失敗了，這會就出現不一致的情況了。這也是緩存更新策略（2）里留下的最后一個疑問。
如何解決？
提供一個保障的重試機制即可，這里給出兩套方案。
方案一：
如下圖所示
流程如下所示
（1）更新數據庫數據；
（2）緩存因為種種問題刪除失敗
（3）將需要刪除的key發送至消息隊列
（4）自己消費消息，獲得需要刪除的key
（5）繼續重試刪除操作，直到成功
然而，該方案有一個缺點，對業務線代碼造成大量的侵入。於是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
方案二：
流程如下圖所示：
（1）更新數據庫數據
（2）數據庫會將操作信息寫入binlog日志當中
（3）訂閱程序提取出所需要的數據以及key
（4）另起一段非業務代碼，獲得該信息
（5）嘗試刪除緩存操作，發現刪除失敗
（6）將這些信息發送至消息隊列
（7）重新從消息隊列中獲得該數據，重試操作。
備注說明：上述的訂閱binlog程序在mysql中有現成的中間件叫canal，可以完成訂閱binlog日志的功能。至於oracle中，博主目前不知道有沒有現成中間件可以使用。另外，重試機制，博主是采用的是消息隊列的方式。如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供一個思路。
總結
本文其實是對目前互聯網中已有的一致性方案，進行了一個總結。對於先刪緩存，再更新數據庫的更新策略，還有方案提出維護一個內存隊列的方式，博主看了一下，覺得實現異常復雜，沒有必要，因此沒有必要在文中給出。最后，希望大家有所收獲。
參考文獻
如何保證緩存與數據庫的雙寫一致性？
面試題
如何保證緩存與數據庫的雙寫一致性？
面試官心理分析
你只要用緩存，就可能會涉及到緩存與數據庫雙存儲雙寫，你只要是雙寫，就一定會有數據一致性的問題，那么你如何解決一致性問題？
面試題剖析
一般來說，如果允許緩存可以稍微的跟數據庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求 “緩存+數據庫” 必須保持一致性的話，最好不要做這個方案，即：讀請求和寫請求串行化，串到一個內存隊列里去。
串行化可以保證一定不會出現不一致的情況，但是它也會導致系統的吞吐量大幅度降低，用比正常情況下多幾倍的機器去支撐線上的一個請求。
Cache Aside Pattern
最經典的緩存+數據庫讀寫的模式，就是 Cache Aside Pattern。
- 讀的時候，先讀緩存，緩存沒有的話，就讀數據庫，然后取出數據后放入緩存，同時返回響應。
- 更新的時候，先更新數據庫，然后再刪除緩存。
為什么是刪除緩存，而不是更新緩存？
原因很簡單，很多時候，在復雜點的緩存場景，緩存不單單是數據庫中直接取出來的值。
比如可能更新了某個表的一個字段，然后其對應的緩存，是需要查詢另外兩個表的數據並進行運算，才能計算出緩存最新的值的。
另外更新緩存的代價有時候是很高的。是不是說，每次修改數據庫的時候，都一定要將其對應的緩存更新一份？也許有的場景是這樣，但是對於比較復雜的緩存數據計算的場景，就不是這樣了。如果你頻繁修改一個緩存涉及的多個表，緩存也頻繁更新。但是問題在於，這個緩存到底會不會被頻繁訪問到？
舉個栗子，一個緩存涉及的表的字段，在 1 分鍾內就修改了 20 次，或者是 100 次，那么緩存更新 20 次、100 次；但是這個緩存在 1 分鍾內只被讀取了 1 次，有大量的冷數據。實際上，如果你只是刪除緩存的話，那么在 1 分鍾內，這個緩存不過就重新計算一次而已，開銷大幅度降低。用到緩存才去算緩存。
其實刪除緩存，而不是更新緩存，就是一個 lazy 計算的思想，不要每次都重新做復雜的計算，不管它會不會用到，而是讓它到需要被使用的時候再重新計算。像 mybatis，hibernate，都有懶加載思想。查詢一個部門，部門帶了一個員工的 list，沒有必要說每次查詢部門，都里面的 1000 個員工的數據也同時查出來啊。80% 的情況，查這個部門，就只是要訪問這個部門的信息就可以了。先查部門，同時要訪問里面的員工，那么這個時候只有在你要訪問里面的員工的時候，才會去數據庫里面查詢 1000 個員工。
最初級的緩存不一致問題及解決方案
問題：先修改數據庫，再刪除緩存。如果刪除緩存失敗了，那么會導致數據庫中是新數據，緩存中是舊數據，數據就出現了不一致。
解決思路：先刪除緩存，再修改數據庫。如果數據庫修改失敗了，那么數據庫中是舊數據，緩存中是空的，那么數據不會不一致。因為讀的時候緩存沒有，則讀數據庫中舊數據，然后更新到緩存中。
比較復雜的數據不一致問題分析
數據發生了變更，先刪除了緩存，然后要去修改數據庫，此時還沒修改。一個請求過來，去讀緩存，發現緩存空了，去查詢數據庫，查到了修改前的舊數據，放到了緩存中。隨后數據變更的程序完成了數據庫的修改。完了，數據庫和緩存中的數據不一樣了...
為什么上億流量高並發場景下，緩存會出現這個問題？
只有在對一個數據在並發的進行讀寫的時候，才可能會出現這種問題。其實如果說你的並發量很低的話，特別是讀並發很低，每天訪問量就 1 萬次，那么很少的情況下，會出現剛才描述的那種不一致的場景。但是問題是，如果每天的是上億的流量，每秒並發讀是幾萬，每秒只要有數據更新的請求，就可能會出現上述的數據庫+緩存不一致的情況。
解決方案如下：
更新數據的時候，根據數據的唯一標識，將操作路由之后，發送到一個 jvm 內部隊列中。讀取數據的時候，如果發現數據不在緩存中，那么將重新讀取數據+更新緩存的操作，根據唯一標識路由之后，也發送同一個 jvm 內部隊列中。
一個隊列對應一個工作線程，每個工作線程串行拿到對應的操作，然后一條一條的執行。這樣的話，一個數據變更的操作，先刪除緩存，然后再去更新數據庫，但是還沒完成更新。此時如果一個讀請求過來，讀到了空的緩存，那么可以先將緩存更新的請求發送到隊列中，此時會在隊列中積壓，然后同步等待緩存更新完成。
這里有一個優化點，一個隊列中，其實多個更新緩存請求串在一起是沒意義的，因此可以做過濾，如果發現隊列中已經有一個更新緩存的請求了，那么就不用再放個更新請求操作進去了，直接等待前面的更新操作請求完成即可。
待那個隊列對應的工作線程完成了上一個操作的數據庫的修改之后，才會去執行下一個操作，也就是緩存更新的操作，此時會從數據庫中讀取最新的值，然后寫入緩存中。
如果請求還在等待時間范圍內，不斷輪詢發現可以取到值了，那么就直接返回；如果請求等待的時間超過一定時長，那么這一次直接從數據庫中讀取當前的舊值。
高並發的場景下，該解決方案要注意的問題：
- 讀請求長時阻塞
由於讀請求進行了非常輕度的異步化，所以一定要注意讀超時的問題，每個讀請求必須在超時時間范圍內返回。
該解決方案，最大的風險點在於說，可能數據更新很頻繁，導致隊列中積壓了大量更新操作在里面，然后讀請求會發生大量的超時，最后導致大量的請求直接走數據庫。務必通過一些模擬真實的測試，看看更新數據的頻率是怎樣的。
另外一點，因為一個隊列中，可能會積壓針對多個數據項的更新操作，因此需要根據自己的業務情況進行測試，可能需要部署多個服務，每個服務分攤一些數據的更新操作。如果一個內存隊列里居然會擠壓 100 個商品的庫存修改操作，每隔庫存修改操作要耗費 10ms 去完成，那么最后一個商品的讀請求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到數據，這個時候就導致讀請求的長時阻塞。
一定要做根據實際業務系統的運行情況，去進行一些壓力測試，和模擬線上環境，去看看最繁忙的時候，內存隊列可能會擠壓多少更新操作，可能會導致最后一個更新操作對應的讀請求，會 hang 多少時間，如果讀請求在 200ms 返回，如果你計算過后，哪怕是最繁忙的時候，積壓 10 個更新操作，最多等待 200ms，那還可以的。
如果一個內存隊列中可能積壓的更新操作特別多，那么你就要加機器，讓每個機器上部署的服務實例處理更少的數據，那么每個內存隊列中積壓的更新操作就會越少。
其實根據之前的項目經驗，一般來說，數據的寫頻率是很低的，因此實際上正常來說，在隊列中積壓的更新操作應該是很少的。像這種針對讀高並發、讀緩存架構的項目，一般來說寫請求是非常少的，每秒的 QPS 能到幾百就不錯了。
我們來實際粗略測算一下。
如果一秒有 500 的寫操作，如果分成 5 個時間片，每 200ms 就 100 個寫操作，放到 20 個內存隊列中，每個內存隊列，可能就積壓 5 個寫操作。每個寫操作性能測試后，一般是在 20ms 左右就完成，那么針對每個內存隊列的數據的讀請求，也就最多 hang 一會兒，200ms 以內肯定能返回了。
經過剛才簡單的測算，我們知道，單機支撐的寫 QPS 在幾百是沒問題的，如果寫 QPS 擴大了 10 倍，那么就擴容機器，擴容 10 倍的機器，每個機器 20 個隊列。
- 讀請求並發量過高
這里還必須做好壓力測試，確保恰巧碰上上述情況的時候，還有一個風險，就是突然間大量讀請求會在幾十毫秒的延時 hang 在服務上，看服務能不能扛的住，需要多少機器才能扛住最大的極限情況的峰值。
但是因為並不是所有的數據都在同一時間更新，緩存也不會同一時間失效，所以每次可能也就是少數數據的緩存失效了，然后那些數據對應的讀請求過來，並發量應該也不會特別大。
- 多服務實例部署的請求路由
可能這個服務部署了多個實例，那么必須保證說，執行數據更新操作，以及執行緩存更新操作的請求，都通過 Nginx 服務器路由到相同的服務實例上。
比如說，對同一個商品的讀寫請求，全部路由到同一台機器上。可以自己去做服務間的按照某個請求參數的 hash 路由，也可以用 Nginx 的 hash 路由功能等等。
- 熱點商品的路由問題，導致請求的傾斜
萬一某個商品的讀寫請求特別高，全部打到相同的機器的相同的隊列里面去了，可能會造成某台機器的壓力過大。就是說，因為只有在商品數據更新的時候才會清空緩存，然后才會導致讀寫並發，所以其實要根據業務系統去看，如果更新頻率不是太高的話，這個問題的影響並不是特別大，但是的確可能某些機器的負載會高一些。