如何保證緩存與數(shù)據(jù)庫(kù)雙寫時(shí)的數(shù)據(jù)一致性？

如何保證緩存與數(shù)據(jù)庫(kù)雙寫時(shí)的數(shù)據(jù)一致性？

• 第1級(jí)：訂單數(shù)據(jù)和支付流水?dāng)?shù)據(jù)；這兩塊數(shù)據(jù)對(duì)實(shí)時(shí)性和精確性要求很高，所以不添加任何緩存，讀寫操作將直接操作數(shù)據(jù)庫(kù)。
• 第2級(jí)：用戶相關(guān)數(shù)據(jù)；這些數(shù)據(jù)和用戶相關(guān)，具有讀多寫少的特征，所以我們使用redis進(jìn)行緩存。
• 第3級(jí)：支付配置信息；這些數(shù)據(jù)和用戶無(wú)關(guān)，具有數(shù)據(jù)量小，頻繁讀，幾乎不修改的特征，所以我們使用本地內(nèi)存進(jìn)行緩存。

但是只要使用到緩存，無(wú)論是本地內(nèi)存做緩存還是使用 redis 做緩存，那么就會(huì)存在數(shù)據(jù)同步的問(wèn)題，因?yàn)榕渲眯畔⒕彺嬖趦?nèi)存中，而內(nèi)存時(shí)無(wú)法感知到數(shù)據(jù)在數(shù)據(jù)庫(kù)的修改。這樣就會(huì)造成數(shù)據(jù)庫(kù)中的數(shù)據(jù)與緩存中數(shù)據(jù)不一致的問(wèn)題。接下來(lái)就討論一下關(guān)于保證緩存和數(shù)據(jù)庫(kù)雙寫時(shí)的數(shù)據(jù)一致性。

解決方案

那么我們這里列出來(lái)所有策略，并且討論他們優(yōu)劣性。

1. 先更新數(shù)據(jù)庫(kù)，后更新緩存

2. 先更新數(shù)據(jù)庫(kù)，后刪除緩存

3. 先更新緩存，后更新數(shù)據(jù)庫(kù)

4. 先刪除緩存，后更新數(shù)據(jù)庫(kù)

先更新數(shù)據(jù)庫(kù)，后更新緩存

先更新緩存，后更新數(shù)據(jù)庫(kù)

這一種情況應(yīng)該不需要我們考慮了吧，和第一種情況是一樣的。

先刪除緩存，后更新數(shù)據(jù)庫(kù)

該方案也會(huì)出問(wèn)題，具體出現(xiàn)的原因如下。

1. 請(qǐng)求 A 會(huì)先刪除 Redis 中的數(shù)據(jù)，然后去數(shù)據(jù)庫(kù)進(jìn)行更新操作
2. 此時(shí)請(qǐng)求 B 看到 Redis 中的數(shù)據(jù)時(shí)空的，會(huì)去數(shù)據(jù)庫(kù)中查詢?cè)撝担a(bǔ)錄到 Redis 中
3. 但是此時(shí)請(qǐng)求 A 并沒(méi)有更新成功，或者事務(wù)還未提交

1. 請(qǐng)求 A 更新操作，刪除了 Redis
2. 請(qǐng)求主庫(kù)進(jìn)行更新操作，主庫(kù)與從庫(kù)進(jìn)行同步數(shù)據(jù)的操作
3. 請(qǐng) B 查詢操作，發(fā)現(xiàn) Redis 中沒(méi)有數(shù)據(jù)
4. 去從庫(kù)中拿去數(shù)據(jù)
5. 此時(shí)同步數(shù)據(jù)還未完成，拿到的數(shù)據(jù)是舊數(shù)據(jù)

先更新數(shù)據(jù)庫(kù)，后刪除緩存

1. 請(qǐng)求 A 先對(duì)數(shù)據(jù)庫(kù)進(jìn)行更新操作
2. 在對(duì) Redis 進(jìn)行刪除操作的時(shí)候發(fā)現(xiàn)報(bào)錯(cuò)，刪除失敗
3. 此時(shí)將Redis 的 key 作為消息體發(fā)送到消息隊(duì)列中
4. 系統(tǒng)接收到消息隊(duì)列發(fā)送的消息后再次對(duì) Redis 進(jìn)行刪除操作

總結(jié)