針對這兩點問題，一共可以分為四種方案：
1、先更新緩存，再更新數據庫；
2、先更新數據庫，再更新緩存；
3、先淘汰緩存，再更新數據庫；
4、先更新數據庫，再淘汰緩存。
更新緩存、淘汰緩存的優缺點：
淘汰緩存
優點：操作簡單，不用關心更新操作，直接將緩存中的舊值淘汰
缺點：淘汰緩存后，下一次查詢無法命中緩存，需要重新讀取數據庫，業務復雜或者數據量大時，響應慢
更新緩存
優點：命中率高，簡單key-value更新緩存和淘汰緩存效率差不多
缺點：更新緩存消耗較大。當更新操作簡單，如只是將某個值直接修改時，更新緩存和淘汰緩存的消耗查不多；但當更新操作邏輯較復雜時，需要涉及到其他數據或者計算、比較才能得到最終結果，此時更新緩存的消耗要大於直接淘汰緩存。
所以實踐中我一般是 簡單key-value 可以依據個人習慣采用更新緩存或淘汰緩存都可以，復雜的key-value一般采用淘汰緩存機制。
單機情況下淘汰緩存和更新數據庫順序如何選擇？哪種對業務的影響最小？
1、先淘汰緩存，后更新數據庫
如果第一步先淘汰緩存成功，第二步更新數據庫失敗，此時再次查詢緩存無法命中緩存，會重新查詢數據庫。
2、先更新數據庫，在淘汰緩存
如果第一步更新數據庫成功，第二步淘汰緩存失敗，則會導致數據庫中是最新的，緩存是舊的，導致數據不一致。
解決辦法：為確保緩存刪除成功，需要增加“重試機制”邏輯，直到緩存刪除成功
單機情況下，采用 先淘汰緩存，后更新數據庫（更新失敗需要重試機制）或者先更新數據庫，在淘汰緩存（淘汰緩存失敗需要增加重試機制），在保證業務合理的條件下，倆種方式都可以使用，沒有優劣之分。
如果業務對數據一致性要求不高的話，一般更傾向於先更新數據庫，在淘汰緩存，更嚴謹一些的話 采用 先更新數據庫，在淘汰緩存；如果業務對數據的一致性要求較高的話，一般 采用先淘汰緩存，在更新數據庫，更新完成后在淘汰緩存（延時雙刪策略）。
解決方案：
1、延時雙刪策略+設置超時時間
優點：操作比較簡單，一定程度可以保證緩存和db數據的一致性
缺點：在休眠時間內數據存在不一致，而且又增加了寫請求的耗時
2、基於mysql binglog 日志進行異步更新緩存
基於mysql binglog 的日志進行分析，mysql的操作都會記錄在binglog日志中，所以進行分析binglog日志的行為，然后根據不同的行為及業務進行異步更新緩存，可以保證redis緩存和mysql數據庫的強一致性；
目前mysql binglog分析工具較多：
開源工具：mysql-binglog=connector-java
ALI Canal:Canal
3、熱點數據（或修改較少的常用數據）定時分階段刷新緩存；增加手動、定時雙機制刷新緩存功能（強制刷新緩存功能）
參考鏈接：
https://developer.aliyun.com/article/712285
https://blog.csdn.net/qq_34125349/article/details/106382286