（2.1）什么情況下緩存和數據庫會不一致
在高並發的情況下，如果所有的數據都從數據庫中去讀取，那再強大的數據庫系統都承受不了這個壓力，因此我們會將部分數據放入緩存中，比如放入redis中。這是典型的用空間換時間的方式。
但是這個redis相當於是真實數據的一個副本，這就意味着如果數據庫中數據發生變化的時候，就會導致緩存數據不一致的問題。
歸根結底，只要有兩份數據存在，數據一致性問題就是不可避免的。
（2.2）解決方法一：數據實時更新
當更新數據庫的時候，同步更新緩存。
優點：數據一致性強，不會出現緩存雪崩的問題。
缺點：代碼耦合度高，影響正常業務，增加一次網絡開銷。
適用環境：適用於數據一致性要求高的場景，比如銀行業務，證券交易
（2.3）解決方法二：數據准實時更新
當更新數據庫的同時，異步去更新緩存，比如更新數據庫后把一條消息發送到mq中去實現。
優點：與業務解耦，不影響正常業務，不會出現緩存雪崩。
缺點：有較短的延遲，並且無法保證最終的一致性，需要補償機制。
適用環境：寫操作不頻繁並且實時性要求不嚴格的場景。
（2.4）解決方法三：緩存失效機制
基於緩存本身的失效機制，具體實現方式為設置緩存失效時間，如果有緩存就從緩存中取數據，如果沒緩存就從數據庫中取數據，並且重新設置緩存。
優點：實現方式簡單，與業務完美解耦，不影響正常業務。
缺點：有一定延遲，並且存在緩存雪崩的情況。
（2.5）解決方法四：定時任務更新
通過定時任務，按照一定時間間隔更新緩存。
優點：不影響正常業務，在特殊場景應用廣泛。
缺點：不保證實時一致性，且需要為每個任務寫一個調度代碼。
適用環境：適用於需要復雜數據統計的緩存更新，比如展示高速車流量，五分鍾一次的統計不會影響業務使用。
（三）總結
關於緩存一致性問題，需要具體場景具體分析，沒有任何一種方案可以應用於所有場景，上述四種方式也並非全部實現方式。