有人可能看到“本地緩存”這四個字就會覺得不屑，“哼，現在誰還用本地緩存？直接用分布式緩存不就完了嘛”。

然而，這就像你有一輛超級豪華的房車一樣，雖然它空間很大，設備很全，但你去市中心的時候，依然會開小轎車一樣，為啥？好停車啊！所以，不同的緩存類型是有不同得使用場景的。

并且，為了防止緩存雪崩問題、緩存擊穿問題，我們通常會采用多級緩存的解決方案，所謂的多級緩存就是：分布式緩存（Redis 或 Memcached）+本地緩存（Guava Cache 或 Caffeine）。因為分布式緩存可能會失效、可能會掛掉，所以為了系統的穩定性，多級緩存策略使用的非常廣泛。

那么，問題來了，怎么保證本地緩存的一致性？

所謂的一致性是指在同時使用緩存和數據庫的場景下，要確保數據在緩存與數據庫中的更新操作保持同步。也就是當對數據進行修改時，無論是先修改緩存還是先修改數據庫，最終都要保證兩者的數據是一樣的，不會出現數據不一樣的問題。

1.如何保證本地緩存的一致性？

在分布式系統中，使用本地緩存最大的問題就是一致性問題，所謂的一致性問題指的是當數據庫發生數據變更時，緩存也要跟著一起變更。而分布式系統中每臺機器都有自己的本地緩存，所以想要保證（本地緩存的）一致性是一個比較難的問題，但通過以下手段可以最大程度的保證本地緩存的一致性問題。

（1）設置本地緩存短時間內失效

設置本地緩存短時間內失效，短的存活周期，保證了數據的時效性比較高，當數據失效之后，再次訪問數據就會拉取新的數據了，這樣能盡可能的保證數據的一致性。

它的特點是：代碼實現簡單，不需要寫多余的代碼；缺點是，效果不是很明顯，不適合高并發的系統。

（2）通過配置中心協調和同步

通過微服務中的配置中心（例如 Nacos）來協調，因為所有服務器都會連接到配置中心，所以當數據修改之后，可以修改配置中心的配置，然后配置中心再把配置變更的事件推送給各個服務，各個服務感知到配置中心的配置發生更改之后，再更新自己的本地緩存，這樣就實現了本地緩存的數據一致性。

（3）本地緩存自動更新功能

使用本地緩存框架的自動更新功能，例如 Caffeine 中的 refresh 功能來自動刷新緩存，這樣就可以設置很短的時間來更新最新的數據，從而也能盡可能的保證數據的一致性，如下代碼所示：

// 創建 Caffeine 緩存實例
Cache<String, String> caffeineCache = Caffeine.newBuilder()
// 設置緩存項在 5s 后開始自動更新
.refreshAfterWrite(5, TimeUnit.SECONDS)
// 自定義緩存更新邏輯（即獲取新值邏輯）
.build(new CacheLoader<String, String>() {
    @Override
    public void reload(String key, String oldValue) throws Exception {
        // 模擬更新緩存的操作
        updateCache(key, oldValue);
    }
});

2.實際工作中會使用哪種方案？

不同的業務系統，會采用不同的解決方案，例如以下這些場景和對應的解決方案：

• 如果對數據一致性要求不是很高，并且程序的并發壓力不大的情況下，可能使用方案 1，也就是設置本地緩存短時間內失效的解決方案，因為它的實現最簡單。
• 如果對數據的一致性要求極高，且有配置中心的情況下，可使用配置中心協調和同步本地緩存。
• 相反，如果對一致性要求沒有那么高，且為高并發的系統，那么可以采用本地緩存的自動更新功能來實現。

小結

在多級緩存中，本地緩存是不可或缺的組成部分，而想要保證本地緩存的數據一致性，可能采用：設置較短的本地緩存過期時間、通過配置中心來協調和同步本地緩存，以及使用本地緩存框架的自動更新功能保證數據的一致性等解決方案，而不同的業務場景，選擇的解決方案也是不同的。