日韩精品在线播放,99精品人妻,国产一级片内射视频播放蘑菇,影音先锋三级网址,亚洲一在线,一区二区超清无码教师,亚洲成人诱惑,欧美日韩国产一级

來源：冰河技術

緩存的讀寫策略。你可能覺得緩存的讀寫很簡單，只需要優(yōu)先讀緩存，緩存不命中就從數據庫查詢，查詢到了就回種緩存。實際上，針對不同的業(yè)務場景，緩存的讀寫策略也是不同的。

而我們在選擇策略時也需要考慮諸多的因素，比如說，緩存中是否有可能被寫入臟數據，策略的讀寫性能如何，是否存在緩存命中率下降的情況等等。

接下來，我就以標準的“緩存 + 數據庫”的場景為例，帶你剖析經典的緩存讀寫策略以及它們適用的場景。這樣一來，你就可以在日常的工作中根據不同的場景選擇不同的讀寫策略。

Cache Aside（旁路緩存）策略

我們來考慮一種最簡單的業(yè)務場景，比方說在你的電商系統(tǒng)中有一個用戶表，表中只有 ID 和年齡兩個字段，緩存中我們以 ID 為 Key 存儲用戶的年齡信息。那么當我們要把 ID 為 1 的用戶的年齡從 19 變更為 20，要如何做呢？

你可能會產生這樣的思路：先更新數據庫中 ID 為 1 的記錄，再更新緩存中 Key 為 1 的數據。

這個思路會造成緩存和數據庫中的數據不一致。比如，A 請求將數據庫中 ID 為 1 的用戶年齡從 19 變更為 20，與此同時，請求 B 也開始更新 ID 為 1 的用戶數據，它把數據庫中記錄的年齡變更為 21，然后變更緩存中的用戶年齡為 21。緊接著，A 請求開始更新緩存數據，它會把緩存中的年齡變更為 20。此時，數據庫中用戶年齡是 21，而緩存中的用戶年齡卻是 20。

為什么產生這個問題呢？因為變更數據庫和變更緩存是兩個獨立的操作，而我們并沒有對操作做任何的并發(fā)控制。那么當兩個線程并發(fā)更新它們的時候，就會因為寫入順序的不同造成數據的不一致。

另外，直接更新緩存還存在另外一個問題就是丟失更新。還是以我們的電商系統(tǒng)為例，假如電商系統(tǒng)中的賬戶表有三個字段：ID、戶名和金額，這個時候緩存中存儲的就不只是金額信息，而是完整的賬戶信息了。當更新緩存中賬戶金額時，你需要從緩存中查詢完整的賬戶數據，把金額變更后再寫入到緩存中。

這個過程中也會有并發(fā)的問題，比如說原有金額是 20，A 請求從緩存中讀到數據，并且把金額加 1，變更成 21，在未寫入緩存之前又有請求 B 也讀到緩存的數據后把金額也加 1，也變更成 21，兩個請求同時把金額寫回緩存，這時緩存里面的金額是 21，但是我們實際上預期是金額數加 2，這也是一個比較大的問題。

那我們要如何解決這個問題呢？其實，我們可以在更新數據時不更新緩存，而是刪除緩存中的數據，在讀取數據時，發(fā)現緩存中沒了數據之后，再從數據庫中讀取數據，更新到緩存中。

這個策略就是我們使用緩存最常見的策略，Cache Aside 策略（也叫旁路緩存策略），這個策略數據以數據庫中的數據為準，緩存中的數據是按需加載的。它可以分為讀策略和寫策略，其中讀策略的步驟是：

從緩存中讀取數據；
如果緩存命中，則直接返回數據；
如果緩存不命中，則從數據庫中查詢數據；
查詢到數據后，將數據寫入到緩存中，并且返回給用戶。

寫策略的步驟是：

更新數據庫中的記錄；
刪除緩存記錄。

你也許會問了，在寫策略中，能否先刪除緩存，后更新數據庫呢？答案是不行的，因為這樣也有可能出現緩存數據不一致的問題，我以用戶表的場景為例解釋一下。

假設某個用戶的年齡是 20，請求 A 要更新用戶年齡為 21，所以它會刪除緩存中的內容。這時，另一個請求 B 要讀取這個用戶的年齡，它查詢緩存發(fā)現未命中后，會從數據庫中讀取到年齡為 20，并且寫入到緩存中，然后請求 A 繼續(xù)更改數據庫，將用戶的年齡更新為 21，這就造成了緩存和數據庫的不一致。

那么像 Cache Aside 策略這樣先更新數據庫，后刪除緩存就沒有問題了嗎？其實在理論上還是有缺陷的。

假如某個用戶數據在緩存中不存在，請求 A 讀取數據時從數據庫中查詢到年齡為 20，在未寫入緩存中時另一個請求 B 更新數據。它更新數據庫中的年齡為 21，并且清空緩存。這時請求 A 把從數據庫中讀到的年齡為 20 的數據寫入到緩存中，造成緩存和數據庫數據不一致。

不過這種問題出現的幾率并不高，原因是緩存的寫入通常遠遠快于數據庫的寫入，所以在實際中很難出現請求 B 已經更新了數據庫并且清空了緩存，請求 A 才更新完緩存的情況。而一旦請求 A 早于請求 B 清空緩存之前更新了緩存，那么接下來的請求就會因為緩存為空而從數據庫中重新加載數據，所以不會出現這種不一致的情況。

Cache Aside 策略是我們日常開發(fā)中最經常使用的緩存策略，不過我們在使用時也要學會依情況而變。比如說當新注冊一個用戶，按照這個更新策略，你要寫數據庫，然后清理緩存（當然緩存中沒有數據給你清理）。可當我注冊用戶后立即讀取用戶信息，并且數據庫主從分離時，會出現因為主從延遲所以讀不到用戶信息的情況。

而解決這個問題的辦法恰恰是在插入新數據到數據庫之后寫入緩存，這樣后續(xù)的讀請求就會從緩存中讀到數據了。并且因為是新注冊的用戶，所以不會出現并發(fā)更新用戶信息的情況。

Cache Aside 存在的最大的問題是當寫入比較頻繁時，緩存中的數據會被頻繁地清理，這樣會對緩存的命中率有一些影響。如果你的業(yè)務對緩存命中率有嚴格的要求，那么可以考慮兩種解決方案：

一種做法是在更新數據時也更新緩存，只是在更新緩存前先加一個分布式鎖，因為這樣在同一時間只允許一個線程更新緩存，就不會產生并發(fā)問題了。當然這么做對于寫入的性能會有一些影響；
另一種做法同樣也是在更新數據時更新緩存，只是給緩存加一個較短的過期時間，這樣即使出現緩存不一致的情況，緩存的數據也會很快過期，對業(yè)務的影響也是可以接受。

當然了，除了這個策略，在計算機領域還有其他幾種經典的緩存策略，它們也有各自適用的使用場景。

Read/Write Through（讀穿 / 寫穿）策略

這個策略的核心原則是用戶只與緩存打交道，由緩存和數據庫通信，寫入或者讀取數據。這就好比你在匯報工作的時候只對你的直接上級匯報，再由你的直接上級匯報給他的上級，你是不能越級匯報的。

Write Through 的策略是這樣的：先查詢要寫入的數據在緩存中是否已經存在，如果已經存在，則更新緩存中的數據，并且由緩存組件同步更新到數據庫中，如果緩存中數據不存在，我們把這種情況叫做“Write Miss（寫失效）”。

一般來說，我們可以選擇兩種“Write Miss”方式：

一個是“Write Allocate（按寫分配）”，做法是寫入緩存相應位置，再由緩存組件同步更新到數據庫中；
另一個是“No-write allocate（不按寫分配）”，做法是不寫入緩存中，而是直接更新到數據庫中。

在 Write Through 策略中，我們一般選擇“No-write allocate”方式，原因是無論采用哪種“Write Miss”方式，我們都需要同步將數據更新到數據庫中，而“No-write allocate”方式相比“Write Allocate”還減少了一次緩存的寫入，能夠提升寫入的性能。

Read Through 策略就簡單一些，它的步驟是這樣的：先查詢緩存中數據是否存在，如果存在則直接返回，如果不存在，則由緩存組件負責從數據庫中同步加載數據。

下面是 Read Through/Write Through 策略的示意圖：

Read Through/Write Through 策略的特點是由緩存節(jié)點而非用戶來和數據庫打交道，在我們開發(fā)過程中相比 Cache Aside 策略要少見一些，原因是我們經常使用的分布式緩存組件，無論是 Memcached 還是 Redis 都不提供寫入數據庫，或者自動加載數據庫中的數據的功能。而我們在使用本地緩存的時候可以考慮使用這種策略，比如說在上一節(jié)中提到的本地緩存 Guava Cache 中的 Loading Cache 就有 Read Through 策略的影子。

我們看到 Write Through 策略中寫數據庫是同步的，這對于性能來說會有比較大的影響，因為相比于寫緩存，同步寫數據庫的延遲就要高很多了。那么我們可否異步地更新數據庫？這就是我們接下來要提到的“Write Back”策略。

Write Back（寫回）策略

這個策略的核心思想是在寫入數據時只寫入緩存，并且把緩存塊兒標記為“臟”的。而臟塊兒只有被再次使用時才會將其中的數據寫入到后端存儲中。

需要注意的是，在“Write Miss”的情況下，我們采用的是“Write Allocate”的方式，也就是在寫入后端存儲的同時要寫入緩存，這樣我們在之后的寫請求中都只需要更新緩存即可，而無需更新后端存儲了，我將 Write back 策略的示意圖放在了下面：

如果使用 Write Back 策略的話，讀的策略也有一些變化了。我們在讀取緩存時如果發(fā)現緩存命中則直接返回緩存數據。如果緩存不命中則尋找一個可用的緩存塊兒，如果這個緩存塊兒是“臟”的，就把緩存塊兒中之前的數據寫入到后端存儲中，并且從后端存儲加載數據到緩存塊兒，如果不是臟的，則由緩存組件將后端存儲中的數據加載到緩存中，最后我們將緩存設置為不是臟的，返回數據就好了。

發(fā)現了嗎？其實這種策略不能被應用到我們常用的數據庫和緩存的場景中，它是計算機體系結構中的設計，比如我們在向磁盤中寫數據時采用的就是這種策略。無論是操作系統(tǒng)層面的 Page Cache，還是日志的異步刷盤，亦或是消息隊列中消息的異步寫入磁盤，大多采用了這種策略。因為這個策略在性能上的優(yōu)勢毋庸置疑，它避免了直接寫磁盤造成的隨機寫問題，畢竟寫內存和寫磁盤的隨機 I/O 的延遲相差了幾個數量級呢。

但因為緩存一般使用內存，而內存是非持久化的，所以一旦緩存機器掉電，就會造成原本緩存中的臟塊兒數據丟失。所以你會發(fā)現系統(tǒng)在掉電之后，之前寫入的文件會有部分丟失，就是因為 Page Cache 還沒有來得及刷盤造成的。

當然，你依然可以在一些場景下使用這個策略，在使用時，我想給你的落地建議是：你在向低速設備寫入數據的時候，可以在內存里先暫存一段時間的數據，甚至做一些統(tǒng)計匯總，然后定時地刷新到低速設備上。比如說，你在統(tǒng)計你的接口響應時間的時候，需要將每次請求的響應時間打印到日志中，然后監(jiān)控系統(tǒng)收集日志后再做統(tǒng)計。但是如果每次請求都打印日志無疑會增加磁盤 I/O，那么不如把一段時間的響應時間暫存起來，經過簡單的統(tǒng)計平均耗時，每個耗時區(qū)間的請求數量等等，然后定時地，批量地打印到日志中。