緩存更新(同步)

緩存同步方案總結

這裏總結的緩存同步方案適合像Redis這種集中式緩存，也適合像本地緩存這種分佈式緩存。這裏按照緩存的更新及時性分爲三類

• 及時性要求很是不高
• 及時性要求比較高
• 及時性要求極高

及時性要求很是不高

適合與分佈的服務器，每隔一段時間更新內存數據或靠自定過時更新數據。

這種方式實現很是簡單，適用於少許緩存數據，但在大批量的緩存數據的場景下不適用，須要考慮下面問題：

1. 緩存對象太多，須要定時過時或按期更新的對象太多
2. 因爲上面狀況，可能出現加載緩存數據時對源數據的請求出現同時涌入的狀況

一種解決辦法就是把每一個緩存對象的失效時間設成隨機，達到緩存分散加載的目的。對於定時更新的方式也時相似解決辦法，但此種解決辦法仍是受限於緩存對象的個數限制，只能達到暫時緩解這種問題的爆發。

及時性要求比較高

適合與分佈式服務，一旦數據庫的數據發生變化，通知每一個分佈的服務更新內存數據，通知方式基於MQ，數據發送改變須要同步到緩存時就發送一個Msg到MQ，每一個分佈的服務經過監控MQ來更新緩存。

對於這種方式，須要考慮緩存對象更新失敗的狀況，主要考慮點是Msg必定能夠被處理並更新緩存成功

及時性要求極高

更新數據庫的數據時，將更新分佈服務的內存數據操做歸入同一個事物，等待全部事物完了，統一提交。適合與Redis這種集中式的緩存,基本的實現方式以下

mysql transaction begin
sql update...
redis update ...
...
commit [exception rollback]