這里是Z哥的個人公眾號

每周五早8點 按時送達

當然了，也會時不時加個餐～

我的第「78」篇原創敬上

今天來加個餐，緊急糾正一個錯誤。先和大家說一聲抱歉：D

昨晚睡覺前，慣例打開「訂閱號助手」回復一些留言。有一位小伙伴提了一個問題，問題來源于《分布式系統關注點》專題的第17篇《先寫DB還是「緩存」？》中。

下面就是提出問題的這位小伙伴，@L。這次非常感謝他。

文章的原文是這樣的：

-------------原文開始-------------

先DB再緩存

數據庫操作成功，緩存操作的失敗的情況該怎么解？（主要在用到redis，memcached這種進程外緩存的時候，由于網絡因素，失敗的可能性大增）

辦法也是有的，在操作數據庫的時候帶一個事務，如果緩存操作失敗則事務回滾。大致的代碼意思如下：

begin?trans var?isDbSuccess?=?write?db; if(isDbSuccess){ var?isCacheSuccess = write?cache; if(isCacheSuccess){ return success; } else{ rollback db; return?fail; } } else{ return?fail; } catch(Exception?ex){ rollback?db; } end trans

如此一來就萬無一失了嗎？并不是。除了由于事務的引入，增加了數據庫的壓力之外，在極端場景下可能會出現rollback db失敗的情況。是不是很頭疼？

解決這個問題的方式就是write cache的時候做delete操作，而不是set操作。如此一來，用多一次cache miss的代價來換rollback db失敗的問題。

就像圖上所示，哪怕rollback失敗了，通過一次cache miss重新從db中載入舊值。

-------------原文結束-------------

如果沒看出來問題或者已經遺忘的小伙伴可以去原文地址看下：分布式系統關注點——先寫DB還是「緩存」？

也不知道當時咋了，腦子昏了。其實這里的「rollback db失敗」表述應該換成「commit db失敗」。

而且順帶圖也畫錯了……

正確邏輯圖應該是這樣。

雖然數據庫操作有XA規范的保證，但是由于需要進行二次確認，而確認又需要經過網絡，所以在網絡不穩定的情況下，的確會出現commit失敗的情況。

這個時候delete的好處就出來了。

假如真的commit失敗了，最多就是從db里再撈一份舊數據出來。

而如果使用set的話，緩存中就會存在臟數據了，必須得再多做一次set，將舊數據set回去。并且，這個操作還有可能出現失敗。

好了，這次要說的就那么多，周五早上8點再見吧：D

推薦閱讀：

• 分布式系統關注點——360°的全方位監控
  

• 8個月打磨，一份送給程序員的「分布式系統」合集

原創不易，如果你覺得這篇文章還不錯，就「在看」或者「分享」一下吧。鼓勵我的創作 ：）

如果有希望我寫一下什么主題的話，歡迎在后臺給我留言哦～

如果你有關于軟件架構、分布式系統、產品、運營的困惑

可以試試點擊「閱讀原文」

總結

以上是生活随笔為你收集整理的纠正一个错误，分布式系统关注点第17篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。