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

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

有兩種選擇。

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

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

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

有些“上古”程序員一直堅(jiān)持反對(duì)使用redis怎么辦？

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

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

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

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