本地緩存有什麼優缺點-tft每日頭條

背景

在業務開發過程中，對于數量較少且訪問頻繁的數據，需要使用本地緩存；對于本地緩存的失效策略，通常是超時被動失效；然後再次訪問時，通過回表，reload數據，将最新版本的數據更新至緩存中；

但是在某些場景下，需要主動刷新緩存中的内容（失效或者刷新），雖然我們可以通過設置較短的過期時間達到相同的目的，但是開銷相對較高；如何實現類似于分布式緩存監聽MQ消息，及時失效緩存呢？

類比分布式緩存的解決方案

在分布式緩存中，我們通常采用的是監聽消息隊列及時失效緩存；多實例服務的任一實例，監聽到消息後及時更新緩存，其他實例也能讀取到最新的數據；但是對于本地緩存就大不一樣，每個實例在自己的内存維護一份數據，當消息被其中一個實例消費後，就無法被其他實例感知到，所以需要解決一條消息如何被多實例消費的問題；

本地緩存有什麼優缺點（本地緩存的正确使用姿勢之主動更新）1

本地緩存主動失效策略 a

本地緩存有什麼優缺點（本地緩存的正确使用姿勢之主動更新）2

本地緩存主動失效策略 b

在這個方案中，存在兩種角色，本地緩存MQ适配器和本地緩存MQ處理器；

适配器：将MQ消息轉發成多實例消息，發送至處理器監聽的MQ中；

處理器：調用指定服務緩存更新接口，更新本地緩存；

這種方案存在的問題是

利用配置中心進行本地緩存的失效

鑒于上面的方案存在種種問題，所以需要采用一種更佳的方案，實現本地緩存的及時失效；目前市面上的配置中心都有推送的功能，對于配置發生變化時，可以及時地推送至所有實例中，因此，可以采用對配置中心指定key進行寫操作，然後監聽key進行緩存的失效；

本地緩存有什麼優缺點（本地緩存的正确使用姿勢之主動更新）3

讀寫配置中心失效本地緩存

該方案僅适用于支持推送的配置中心，對于隻支持定時拉取的配置中心，此方案的更新時間可能存在一定的延遲，效果未必優于定時任務主動失效緩存；