關於維護乙份資料是先寫資料庫，還是先寫快取的問題，很多朋友發表了自己的看法，本文來談談我的看法。我的結論非常清晰明確：先寫資料庫再寫快取。核心思想是資料庫和快取之間追求最終一致性，不追求強一致性。
(1) 在快取作為提公升系統效能手段的背景下，不需要保證資料庫和快取的強一致性。如果非要保證二者的強一致性，會增大系統的複雜度，完全沒有必要
(2) 如果更新資料庫成功，再更新快取。此時存在兩種情況：更新快取成功則萬事大吉。更新快取失敗，沒有關係，等待快取失效，此處要合理設定失效時間
(3) 如果更新資料庫失敗，則操作失敗，重試或者等待使用者重新發起
(4) 資料庫是持久化資料，是操作成功還是失敗的判斷依據。快取是提公升效能的手段，允許短時間和資料庫的不一致
(5) 在網際網路架構中，很少追求強一致性，一般都是追求最終一致性
如果非要保證快取和資料庫的一致性，本質上是在解決分布式一致性問題。
分布式一致性問題解決方案有很多，可以選擇比如兩階段提交，tcc，本地訊息表，mq事務性訊息等方案。
產品經理應該先寫需求文件還是先畫原型？
江洋 知乎上的回答 先做模型，再畫原型，最後prd 模型 對產品形態結構的梳理，包括功能模組，邏輯關係，資訊架構，業務流程等，可以用腦 圖，use case圖，業務流程圖來表示，根據不同產品，產出物的側重點不同。但模型很必要，是可以幫助產品經理將乙個想法，或是腦子中的模型梳理清楚，在做這些工作的同時...
快取 先資料庫還是先快取 2
到底是先運算元據庫還是先操作快取，取決於哪種方案可以避免資料不一致，或者資料不一致的概率更低。下面的分析會基於cache aside策略展開，為什麼基於cache aside策略，請檢視博文 快取更新策略 先快取再資料庫的方案，在併發讀寫情況下，會出現資料不一致的情況，如下圖所示。而且，這種不一致情...
快取引入的元件 先更新資料庫，還是快取？
這一篇來聊聊快取一致性的問題，這裡討論的範圍有限，僅僅是應用快取與後端儲存的一致性，當然也會適當做下延伸 如下 4 種組合，該如何決策？標準在 一致性問題出在哪？update cache update db update db update cache delete cache update db ...