是用代碼分別更新到redis和postgresql數據庫(誰先誰後)還是隻更新到redis,然後通過隊列異步更新到數據庫?如果有詳細的做法更好,謝謝!PS:有人誰用過redis-fdw嗎?
ringa_lee
如果是同時更新redis和資料庫的話實際上就是快取更新策略問題吧。說說我的看法咯,算拋磚引玉: 這類問題常用兩種策略: 1.寫快取時更新:這是指DB寫成功以後就更新快取。這種策略能減少穿透,但容易造成數據的不一致。 2.讀取緩存時更新:這是指DB寫成功以後只刪除緩存,等到需要讀取時再重建緩存。這種策略一致性可以保證,但穿透大,容易對DB造成壓力。
(搜了一下發現快取更新的模式很多,上面說的兩種只是我所知 1.Write-through 立即寫 2.Write-behind 後寫 先寫緩存,將寫事件放入Queue,再寫資料庫 3. Eviction Policies 驅逐策略 快取更新策略 直接刪除快取中數據,等下次讀取時更新。 4. Replication 複製 5. Peer-To-Peer (P2P) )
如果是只更新redis再異步更新到資料庫的話緩存宕機後資料不好重建,如果你的資料不需要嚴格準確但需要訪問迅速的話倒是可以考慮這樣玩,比如頁面訪問人數之類。
redis-fdw沒用過。
如果是同時更新redis和資料庫的話實際上就是快取更新策略問題吧。說說我的看法咯,算拋磚引玉:
這類問題常用兩種策略:
1.寫快取時更新:這是指DB寫成功以後就更新快取。這種策略能減少穿透,但容易造成數據的不一致。
2.讀取緩存時更新:這是指DB寫成功以後只刪除緩存,等到需要讀取時再重建緩存。這種策略一致性可以保證,但穿透大,容易對DB造成壓力。
(搜了一下發現快取更新的模式很多,上面說的兩種只是我所知
1.Write-through 立即寫
2.Write-behind 後寫 先寫緩存,將寫事件放入Queue,再寫資料庫
3. Eviction Policies 驅逐策略 快取更新策略 直接刪除快取中數據,等下次讀取時更新。
4. Replication 複製
5. Peer-To-Peer (P2P)
)
如果是只更新redis再異步更新到資料庫的話緩存宕機後資料不好重建,如果你的資料不需要嚴格準確但需要訪問迅速的話倒是可以考慮這樣玩,比如頁面訪問人數之類。
redis-fdw沒用過。