高併發場景下的緩存+數據庫雙寫不一致問題分析與解決方案

一、最初級的緩存不一致問題以及解決方案
問題：
先修改數據庫，再刪除緩存，若是刪除緩存失敗了，那麼會致使數據庫中是新數據，緩存中是舊數據，數據出現不一致。
解決思路：
先刪除緩存，再修改數據庫，若是刪除緩存成功了，若是修改數據庫失敗了，那麼數據庫中是舊數據，緩存中是空的，那麼數據不會不一致。由於讀的時候緩存沒有，則讀數據庫中舊數據，而後更新到緩存中

二、比較複雜的數據不一致問題分析
過程：
有數據發生了變動，先刪除了緩存，而後準備要去修改數據庫，此時還沒修改
一個請求過來，去讀緩存，發現緩存空了，去查詢數據庫，查到了修改前的舊數據，
放到了緩存中 ，以後數據變動的程序完成了數據庫的修改
完了，數據庫和緩存中的數據不同了。。。

三、爲何上億流量高併發場景下，緩存會出現這個問題？
只有在對一個數據在併發的進行讀寫的時候，纔可能會出現這種問題
其實若是說你的併發量很低的話，特別是讀併發很低，天天訪問量就1萬次，那麼不多的狀況下，會出現剛纔描述的那種不一致的場景，可是問題是，若是天天的是上億的流量，每秒併發讀是幾萬，每秒只要有數據更新的請求，就可能會出現上述的數據庫+緩存不一致的狀況。因此高併發了之後，問題是不少的

四、數據庫與緩存更新與讀取操做進行異步串行化
思路：
更新數據的時候，根據數據的惟一標識，將操做路由以後，發送到一個jvm內部的隊列中
讀取數據的時候，若是發現數據不在緩存中，那麼將從新讀取數據+更新緩存的操做，
根據惟一標識路由以後，也發送同一個jvm內部的隊列中
分析：
一個隊列對應一個工做線程，每一個工做線程串行拿到對應的操做，而後一條一條的執行
這樣的話，一個數據變動的操做，先執行刪除緩存，而後再去更新數據庫，可是還沒完成更新
此時若是一個讀請求過來，讀到了空的緩存，那麼能夠先將緩存更新的請求發送到隊列中，
此時會在隊列中積壓，而後同步等待緩存更新完成

這裏有一個優化點，一個隊列中，其實多個更新緩存請求串在一塊兒是沒意義的，所以能夠作過濾，
若是發現隊列中已經有一個更新緩存的請求了，那麼就不用再放個更新請求操做進去了，直接等待前面
的更新操做請求完成便可，待那個隊列對應的工做線程完成了上一個操做的數據庫的修改以後，纔會去
執行下一個操做，也就是緩存更新的操做，此時會從數據庫中讀取最新的值，而後寫入緩存中
若是請求還在等待時間範圍內，不斷輪詢發現能夠取到值了，那麼就直接返回; 若是請求等待的時間
超過必定時長，那麼這一次直接從數據庫中讀取當前的舊值

五、高併發的場景下，該解決方案要注意的問題

（1）讀請求長時阻塞
因爲讀請求進行了很是輕度的異步化，因此必定要注意讀超時的問題，每一個讀請求必須在超時時間範圍內返回
該解決方案，最大的風險點在於說，可能數據更新很頻繁，致使隊列中積壓了大量更新操做在裏面，而後讀請求會
發生大量的超時，最後致使大量的請求直接走數據庫

另一點，由於一個隊列中，可能會積壓針對多個數據項的更新操做，所以須要根據本身的業務狀況進行測試，
可能須要部署多個服務，每一個服務分攤一些數據的更新操做
若是一個內存隊列裏竟然會擠壓100個商品的庫存修改操做，每一個庫存修改操做要耗費10ms區完成，那麼最後 一個商品的讀請求，可能等待10 * 100 = 1000ms = 1s後，才能獲得數據，這個時候就致使讀請求的長時阻塞

備註：
務必經過一些模擬真實的測試，看看更新數據的頻繁是怎樣的
必定要作根據實際業務系統的運行狀況，去進行一些壓力測試，和模擬線上環境，去看看最繁忙的時候，內存隊列可能會擠壓多少更新操做，可能會致使最後一個更新操做對應的讀請求，會hang多少時間，若是讀請求在200ms返回，若是你計算事後，哪怕是最繁忙的時候，積壓10個更新操做，最多等待200ms，那還能夠的
    若是一個內存隊列可能積壓的更新操做特別多，那麼你就要加機器，讓每一個機器上部署的服務實例處理更少的數據，那麼每一個內存隊列中積壓的更新操做就會越少
*大部分狀況下：
應該是這樣的，大量的讀請求過來，都是直接走緩存取到數據的
*少許狀況下：
可能遇到讀跟數據更新衝突的狀況，如上所述，那麼此時更新操做若是先入隊列，以後可能會瞬間來了對這個數據大量的讀請求，可是由於作了去重的優化，因此也就一個更新緩存的操做跟在它後面，等數據更新完了，讀請求觸發的緩存更新操做也完成，而後臨時等待的讀請求所有能夠讀到緩存中的數據    。
其實根據以前的項目經驗，通常來講數據的寫頻率是很低的，所以實際上正常來講，在隊列中積壓的更新操做應該是不多的針對讀高併發，讀緩存架構的項目，通常寫請求相對讀來講，是很是很是少的，每秒的QPS能到幾百就不錯了
         一秒，500的寫操做，5份，每200ms，就100個寫操做
單機器，20個內存隊列，每一個內存隊列，可能就積壓5個寫操做，每一個寫操做性能測試後，通常在20ms左右就完成
那麼針對每一個內存隊列中的數據的讀請求，也就最多hang一下子，200ms之內確定能返回了
寫QPS擴大10倍，可是通過剛纔的測算，就知道，單機支撐寫QPS幾百沒問題，那麼就擴容機器，擴容10倍的機器，10臺機器，每一個機器20個隊列，200個隊列

（2）讀請求併發量太高

這裏還必須作好壓力測試，確保恰巧碰上上述狀況的時候，還有一個風險，就是忽然間大量讀請求會在幾十毫秒的延時hang在服務上，看服務能不能抗的住，須要多少機器才能抗住最大的極限狀況的峯值
可是由於並非全部的數據都在同一時間更新，緩存也不會同一時間失效，因此每次可能也就是少數數據的緩存失效了，而後那些數據對應的讀請求過來，併發量應該也不會特別大
按1:99的比例計算讀和寫的請求，每秒5萬的讀QPS，可能只有500次更新操做，若是一秒有500的寫QPS，那麼要測算好，可能寫操做影響的數據有500條，這500條數據在緩存中失效後，可能致使多少讀請求，發送讀請求到庫存服務來，要求更新緩存，通常來講，1:1，1:2，1:3，每秒鐘有1000個讀請求，會hang在庫存服務上，每一個讀請求最多hang多少時間，200ms就會返回，在同一時間最多hang住的可能也就是單機200個讀請求，同時hang住，單機hang200個讀請求，仍是ok的，1:20，每秒更新500條數據，這500秒數據對應的讀請求，會有20 * 500 = 1萬
1萬個讀請求所有hang在庫存服務上，就死定了

（3）多服務實例部署的請求路由
可能這個服務部署了多個實例，那麼必須保證說，執行數據更新操做，以及執行緩存更新操做的請求，都經過nginx服務器路由到相同的服務實例上

（4）熱點商品的路由問題，致使請求的傾斜 萬一某個商品的讀寫請求特別高，所有打到相同的機器的相同的隊列裏面去了，可能形成某臺機器的壓力過大 就是說，由於只有在商品數據更新的時候纔會清空緩存，而後纔會致使讀寫併發，因此更新頻率不是過高的話，這個 問題的影響並非特別大，可是的確可能某些機器的負載會高一些