DB讀寫分離情況下，如何解決緩存和數(shù)據(jù)庫不一致性問題？有兩種選擇。讓我們首先了解緩存和數(shù)據(jù)庫數(shù)據(jù)不一致時會發(fā)生什么。查詢數(shù)據(jù)時，優(yōu)先從緩存中獲取數(shù)據(jù)。如果緩存不存在，則查詢數(shù)據(jù)庫并寫入緩存。如果數(shù)據(jù)庫

DB讀寫分離情況下，如何解決緩存和數(shù)據(jù)庫不一致性問題？

有兩種選擇。

讓我們首先了解緩存和數(shù)據(jù)庫數(shù)據(jù)不一致時會發(fā)生什么。查詢數(shù)據(jù)時，優(yōu)先從緩存中獲取數(shù)據(jù)。如果緩存不存在，則查詢數(shù)據(jù)庫并寫入緩存。如果數(shù)據(jù)庫數(shù)據(jù)發(fā)生更改，請清除緩存。在正常情況下，沒有問題。但是，在服務的并發(fā)性非常高的情況下，如果刪除緩存，則在數(shù)據(jù)庫完成數(shù)據(jù)更新之前會有查詢請求。此時，舊數(shù)據(jù)將被讀寫到緩存中。在這種情況下，緩存和數(shù)據(jù)庫不一致。

第一種解決方案：延遲刪除。更改數(shù)據(jù)庫數(shù)據(jù)時，清除緩存的操作會延遲一段時間。這段時間可能很短。它只需要確保數(shù)據(jù)庫寫入操作已完成。但在實際環(huán)境中，我們不知道數(shù)據(jù)庫何時會寫入數(shù)據(jù)，所以很難控制這段時間。如果太短，就不行了。如果時間太長，會影響體驗。但總的來說，這種方法可以解決問題。

另一種解決方案是使用數(shù)據(jù)庫的binlog來訂閱binlog。更新數(shù)據(jù)時，該消息用于通知刪除緩存。該方案能保證數(shù)據(jù)庫更新操作的完成和緩存的及時更新。

有些“上古”程序員一直堅持反對使用redis怎么辦？

分享大人物的答案似乎合情合理。

不要告訴我們是否使用redis。你必須告訴我們你為什么要使用redis。沒有redis的業(yè)務怎么了？世界上沒有免費的午餐。如果不直接使用頭部緩存/NoSQL，可能會帶來越來越嚴重的問題。

單個數(shù)據(jù)庫的最大優(yōu)點是易于實現(xiàn)事務，并由數(shù)據(jù)庫本身保證。舉個簡單的例子，要下訂單，需要扣除庫存并插入訂單條目。如果inventory和order都是數(shù)據(jù)庫表條目，那么這個事務是無可挑剔的。如果庫存在redis中，訂單條目是mysql，通常需要先寫redis，成功后再寫數(shù)據(jù)庫。如果您寫數(shù)據(jù)庫失敗，需要回滾redis，如果由于網(wǎng)絡或其他原因回滾失敗，將再扣減一個存貨。不要認為這些事情很容易解決。事務處理的復雜性遠遠超出您的想象。例如，當您編寫mysql時，您在提交時就失去了連接。你無法判斷提交是成功還是失敗。你的redis是不是在倒退？

因此，當您引入一個新層時，您必須弄清楚您必須使用cache/NoSQL的目的以及您可以接受的一致性模型。否則，你就要出丑了。