緩存架構

05-12

上圖是最常見的緩存架構，這種架構缺點是業務方需要同時關注緩存與DB。有沒有進一步優化的可能呢？

計算機第一名言：任何一個計算機問題都可以通過一個中間層解決。

這是一種服務化的方式。中間的服務層向上游提供一個數據訪問借口，並屏蔽下游的數據訪問細節。

這種方案的實現是非同步緩存更新。所有應用的寫操作都是走資料庫，讀操作都是走緩存。

這個方案初始化時，把db中的全部數據放入緩存，然後由一個非同步工具來實現資料庫和cache之間的數據同步。

但這種方案可能華而不實，原因如下：

1）如果cache壞了，或者非同步工具壞了，那麼業務系統讀不到數據。

2）業務系統查詢的數據千姿百態，這些數據後續可能還需要計算，再存儲到cache中。非同步工具同步數據時的計算複雜度會很高。

3）如果cache中加入新key，那麼除了業務代碼修改，非同步更新模塊中的代碼也要修改，這無疑增加了複雜度。

之所以列出這種有缺陷的方案，一個原因是分析其弊端，兩一個原因是可能會獲得啟發。