| 方案名稱 | 技術特點 | 優點 | 缺點 | 適用 | 場景說明 |
| 數據實時同步更新 | 強一致性,更新數據庫同時更新緩存，使用緩存工具和AOP實現 | 數據一致性強，不會出現緩存雪崩問題 | 代碼耦合，運行期耦合 ，影響正常業務 ，增加一致網絡開銷 | 銀行 | 適合寫操作頻繁的細粒度緩存數據，數據一致性要求比較高場景，如:銀行業務，證券交易；不適合寫操作較少粗粒度數據； |
| 數據準實時更新 | 準一致性，更新數據庫後，異步更新緩存，使用AOP進行封裝基於多線程或者MQ實現 | 數據同步有較短延遲，與業務解耦，不影響正常業務，不會出現緩存雪崩問題 | 有較短延遲，無法保證最終一致性，需要補償機制 | 比較優雅 | 不適合寫操作平凡並且數據一致性實時性要求嚴格的場景(較短不一致，寫頻繁導致mq消息劇增) |
| 緩存失效機制 | 弱一致性，基於緩存本身失效機制 | 實現簡單，與業務完美結合，不影響正常業務 | 有一定延遲，存在緩存雪崩問題 | 互聯網大量使用 | 不適合寫操作平凡並且數據一致性實時性要求嚴格的場景，適合讀多寫少的互聯網嬋娟，能接受一定數據延時；如：電商業務,理財金融(收益第二天更新),社交類業務(點贊)等 |
| 任務調度更新 | 最終一致性，採用任務調度框架，按照一定頻率更新 | 不影響正常業務 | 不保證一致性，代碼複雜度增大(麼個value都要維護異步更新代碼)，容易堆積垃圾數據 | 統計類 | 適合複雜統計類數據緩存更新，對數據一致性實時性要求低的場景，如統計類數據，BI分析等 |
方案1：
productDao.insert(product);
redis.delete(productId);
方案2：
productDao.insert(product);
mq.sender(productId);
mq接收客戶端收到消息後，從redis獲取數據更新；
方案3：
redis.set(productId, expireTime); //例如過期3s, 但是存在緩存雪崩(緩存穿透到數據庫)
請參考“緩存雪崩和緩存擊穿”。