關於redis的幾件小事(八)緩存與數據庫雙寫時的數據一致性

1.Cache aside pattern

這是最經典的 緩存+數據庫 讀寫模式，操做以下：
①讀的時候，先讀緩存，緩存沒有就讀數據庫，而後將取出的數據放到緩存，同時返回請求響應。

②更新的時候，先刪除緩存，而後更新數據庫。

2.爲何是刪除緩存，而不是更新緩存呢？

①由於不少時候，緩存中放的並非簡單的從數據中取出來值，可能要進行一個狀態的替換，一些數據的計算，還有可能要進行數據的組合等等。

②二八法則，即20%的數據，佔用了80%的訪問量，這個更新的數據，多是冷門數據，很久也訪問不了不了一次，這樣只會佔用緩存內存。lazy思想，數據等你第一次要的時候再去加載，避免不必的內存和時間浪費。

3.最初級的緩存不一致問題以及解決方案

問題 ：先修改數據庫，再刪除緩存，若是緩存刪除失敗了，那麼就會早上數據庫和緩存數據不一致。
解決思路 ：先刪除緩存，再修改數據庫，若是刪除緩存成功了，若是修改數據庫失敗了，那麼數據庫中是舊數據，緩存中是空的，那麼數據不會不一致。由於讀的時候緩存沒有，則讀數據庫中舊數據，而後更新到緩存中

4.比較複雜的數據不一致問題分析

問題 ：數據發生了變動，先刪除了緩存，而後要去修改數據庫，此時還沒修改。
一個請求過來，去讀緩存，發現緩存空了，去查詢數據庫，查到了修改前的舊數據，放到了緩存中。數據變動的程序完成了數據庫的修改。
這樣就又致使了數據不一致

5.爲何上億流量高併發場景下，緩存會出現這個問題？

由於只有在對一個數據在併發的進行讀寫的時候，纔可能會出現這種問題。

6.數據庫與緩存更新與讀取操做進行異步串行化

爲了解決上面的併發讀寫問題，能夠考慮將更新和讀取操做進行串行化。
①更新數據的時候，根據數據的惟一標識，將操做路由以後，發送到一個jvm內部的隊列裏面去。

②讀取數據的時候，若是發現緩存中沒有，那麼將從數據庫讀取數據的操做和更新緩存的操做一塊兒路由到同一個JVM內部的隊列中去。

③一個隊列對應一個工做線程，而後線程從隊列裏面去取請求進行操做。

這樣就能夠將同一個key的操做進行串行化，一個數據變動的操做，先執行，刪除緩存，而後再去更新數據庫，可是還沒完成更新，此時若是一個讀請求過來，讀到了空的緩存，那麼能夠先將緩存更新的請求發送到隊列中，此時會在隊列中積壓，而後同步等待緩存更新完成。

這裏有一個優化點，一個隊列中，其實多個更新緩存請求串在一塊兒是沒意義的，所以能夠作過濾，若是發現隊列中已經有一個更新緩存的請求了，那麼就不用再放個更新請求操做進去了，直接等待前面的更新操做請求完成便可。

待那個隊列對應的工做線程完成了上一個操做的數據庫的修改以後，纔會去執行下一個操做，也就是緩存更新的操做，此時會從數據庫中讀取最新的值，而後寫入緩存中。

若是請求還在等待時間範圍內，不斷輪詢發現能夠取到值了，那麼就直接返回; 若是請求等待的時間超過必定時長，那麼這一次直接從數據庫中讀取當前的舊值。

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

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

②讀請求併發量太高
還有一個風險，就是忽然間大量讀請求會在幾十毫秒的延時hang在服務上，看服務能不能抗的住，須要多少機器才能抗住最大的極限狀況的峯值。
可是由於並非全部的數據都在同一時間更新，緩存也不會同一時間失效，因此每次可能也就是少數數據的緩存失效了，而後那些數據對應的讀請求過來，併發量應該也不會特別大。

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

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