一、爲什麼寫這篇文章？
首先，緩存由於其高併發和高性能的特性，已經在項目中被廣泛使用。在讀取緩存方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作：
但是在更新緩存方面，對於更新完數據庫，是更新緩存呢，還是刪除緩存？又或者是先刪除緩存，再更新數據庫？其實大家存在很大的爭議。目前沒有一篇全面的博客，對這幾種方案進行解析，於是博主戰戰兢兢，頂着被大家噴的風險，寫了這篇文章。
二、文章結構
1、講解緩存更新策略；
2、對每種策略進行缺點分析；
3、針對缺點給出改進方案；
三、正文
先做一個說明，從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫爲準，對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功，緩存更新失敗，那麼只要到達過期時間，則後面的讀請求自然會從數據庫中讀取新值然後回填緩存。因此，接下來討論的思路不依賴於給緩存設置過期時間這個方案。在這裏，我們討論三種更新策略：
1、先更新數據庫，再更新緩存；
2、先刪除緩存，再更新數據庫；
3、先更新數據庫，再刪除緩存；
應該沒人問我，爲什麼沒有先更新緩存，再更新數據庫這種策略！
四、先更新數據庫，再更新緩存
這套方案，大家是普遍反對的，爲什麼呢？有如下兩點原因：
原因一、線程安全角度
同時有請求A和請求B進行更新操作，那麼會出現：
-
線程A更新了數據庫；
-
線程B更新了數據庫；
-
線程B更新了緩存；
-
線程A更新了緩存；
這就出現請求A更新緩存應該比請求B更新緩存早纔對，但是因爲網絡等原因，B卻比A更早更新了緩存。這就導致了髒數據，因此不考慮！
原因二、業務場景角度
有如下兩點：
（1）如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，採用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
（2）如果你寫入數據庫的值，並不是直接寫入緩存的，而是要經過一系列複雜的計算再寫入緩存。那麼，每次寫入數據庫後，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更爲適合。
接下來討論的就是爭議最大的，先刪緩存，再更新數據庫。還是先更新數據庫，再刪緩存的問題。
五、先刪緩存，再更新數據庫
該方案會導致不一致的原因是：同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那麼會出現如下情形:
（1）請求A進行寫操作，刪除緩存；
（2）請求B查詢發現緩存不存在；
（3）請求B去數據庫查詢得到舊值；
（4）請求B將舊值寫入緩存；
（5）請求A將新值寫入數據庫；
上述情況就會導致不一致的情形出現。而且，如果不採用給緩存設置過期時間策略，該數據永遠都是髒數據。
那麼，如何解決呢？採用延時雙刪策略！僞代碼如下：
轉化爲中文描述就是：
（1）先淘汰緩存；
（2）再寫數據庫（這兩步和原來一樣）；
（3）休眠1秒，再次淘汰緩存；
這麼做，可以將1秒內所造成的緩存髒數據，再次刪除！
5.1、那麼，這個1秒怎麼確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的項目的讀數據業務邏輯的耗時。然後寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存髒數據。
5.2、如果你用了MySQL的讀寫分離架構怎麼辦？
OK，在這種情況下，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
（1）請求A進行寫操作，刪除緩存；
（2）請求A將數據寫入數據庫了；
（3）請求B查詢緩存發現，緩存沒有值；
（4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值；
（5）請求B將舊值寫入緩存；
（6）數據庫完成主從同步，從庫變爲新值；
上述情形，就是數據不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改爲在主從同步的延時時間基礎上，加幾百ms。
5.3、採用這種同步淘汰策略，吞吐量降低怎麼辦？
ok，那就將第二次刪除作爲異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間後了，再返回。這麼做，加大吞吐量。
5.4、第二次刪除，如果刪除失敗怎麼辦？
這是個非常好的問題，因爲第二次刪除失敗，就會出現如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，爲了方便，假設是單庫：
（1）請求A進行寫操作，刪除緩存；
（2）請求B查詢發現緩存不存在；
（3）請求B去數據庫查詢得到舊值；
（4）請求B將舊值寫入緩存；
（5）請求A將新值寫入數據庫；
（6）請求A試圖去刪除請求B寫入對緩存值，結果失敗了；ok,這也就是說。如果第二次刪除緩存失敗，會再次出現緩存和數據庫不一致的問題。
5.5、如何解決呢？
具體解決方案，且看博主對第六節更新策略的解析！
六、先更新數據庫，再刪緩存
首先，先說一下。老外提出了一個緩存更新套路，名爲《Cache-Aside pattern》。其中就指出：
-
失效：應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功後，放到緩存中；
-
命中：應用程序從cache中取數據，取到後返回；
-
更新：先把數據存到數據庫中，成功後，再讓緩存失效；
另外，知名社交網站facebook也在論文《Scaling Memcache at Facebook》中提出，他們用的也是先更新數據庫，再刪緩存的策略。
6.1、這種情況不存在併發問題麼？
不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那麼會有如下情形產生：
（1）緩存剛好失效；
（2）請求A查詢數據庫，得一箇舊值；
（3）請求B將新值寫入數據庫；
（4）請求B刪除緩存；
（5）請求A將查到的舊值寫入緩存；
ok，如果發生上述情況，確實是會發生髒數據。
6.2、然而，發生這種情況的概率又有多少呢？
發生上述情況有一個先天性條件，就是6.1中步驟（3）的寫數據庫操作比步驟（2）的讀數據庫操作耗時更短，纔有可能使得步驟（4）先於步驟（5）。可是，大家想想，數據庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因爲讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。
假設，有人非要擡槓，有強迫症，一定要解決怎麼辦？
6.3、如何解決上述併發問題？
首先，給緩存設有效時間是一種方案。其次，採用策略2（先刪除緩存，再更新數據庫）裏給出的異步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
6.4、還有其他造成不一致的原因麼？
有的，這也是緩存更新策略2（先刪除緩存，再更新數據庫）和緩存更新策略3（先更新數據庫，再刪除緩存）都存在的一個問題，如果刪緩存失敗了怎麼辦，那不是會有不一致的情況出現麼。比如一個寫數據請求，然後寫入數據庫了，刪緩存失敗了，這會就出現不一致的情況了。這也是緩存更新策略2（先刪除緩存，再更新數據庫）裏留下的最後一個疑問。
6.5、如何解決？
提供一個保障的重試機制即可，這裏給出兩套方案。
方案一：
流程如下所示：
（1）更新數據庫數據；
（2）緩存因爲種種問題刪除失敗；
（3）將需要刪除的key發送至消息隊列；
（4）自己消費消息，獲得需要刪除的key；
（5）繼續重試刪除操作，直到成功；
然而，該方案有一個缺點，對業務線代碼造成大量的侵入。於是有了方案二，在方案二中，啓動一個訂閱程序去訂閱數據庫的binlog，獲得需要操作的數據。在應用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
方案二：
流程如下圖所示：
（1）更新數據庫數據；
（2）數據庫會將操作信息寫入binlog日誌當中；
（3）訂閱程序提取出所需要的數據以及key；
（4）另起一段非業務代碼，獲得該信息；
（5）嘗試刪除緩存操作，發現刪除失敗；
（6）將這些信息發送至消息隊列；
（7）重新從消息隊列中獲得該數據，重試操作；
備註說明：上述的訂閱binlog程序在mysql中有現成的中間件叫canal，可以完成訂閱binlog日誌的功能。至於oracle中，博主目前不知道有沒有現成中間件可以使用。另外，重試機制，博主是採用的是消息隊列的方式。如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供一個思路。
七、總結
本文其實是對目前互聯網中已有的一致性方案，進行了一個總結。對於先刪緩存，再更新數據庫的更新策略，還有方案提出維護一個內存隊列的方式，博主看了一下，覺得實現異常複雜，沒有必要，因此沒有必要在文中給出。最後，希望大家有所收穫。