一般來說，對於乙個新的業務，一般會經歷這幾個階段：
讀寫流量都比較小，這個時候所有的讀寫操作都在主庫就ok了
這個時候，從庫可能只是用來災備
風險分析：從資料一致性角度來說沒有風險，全走主庫美滋滋~
階段2.1：
單庫扛不住了，這個時候就會考慮到分庫分表了，通過增加資料庫的方式，把單庫的qps降下來
風險分析：從資料一致性角度來說沒有風險，全走主庫依然美滋滋~
階段2.2：
讀流量增加，主庫的讀qps偏高，這個時候我們就想著把從庫得利用起來，於是讀寫分離：寫主庫，讀從庫
風險分析：讀從庫就意味著，讀到的資料可能不是最新的，在實時性要求比較高的業務中是不能接受的，那應該如何解決呢？由於」db主從一致性」不是本系列討論的重點，所以這裡推薦一篇文章,它介紹了幾種比較不錯的解決方案，感興趣的大家可以去讀一下：db主從一致性架構優化4種方法
對於網際網路公司來說，大部分業務都面臨著讀多寫少的情況（如果你寫都有壓力的話，那你做的業務一定很賺錢吧），而資料庫資源是極其寶貴的，所以我們沒有辦法一味的新增從庫，或者說不斷的增加分庫分表來解決，一是因為老闆不會同意，二是不斷分庫分表的話，資料遷移過程也是高風險的。
所以，這個時候我們一般會通過新增的快取的方式，來解決讀壓力
風險分析：快取與資料庫資料一致性問題
這就引出本系列文章，想要討論的問題：快取與資料庫資料一致性問題，在提出解決方案之前，我們應該分析自己當前的業務和架構，看看自己的要達到的目標是什麼？不同的方案解決的問題是不一樣的
只有我們看清楚自己的系統需要達到一種怎樣的要求，才能針對性的制定對應的方案。
本系列文章，會針對不同的場景提出不同的解決方案，並從併發、容災等各方面分析其優缺點
《快取與資料庫一致性系列-01》
《快取與資料庫一致性系列-02》
《快取與資料庫一致性系列-03》
《快取與資料庫一致性系列-04》
快取與資料庫一致性
此時系統的讀寫流量很小，這個時候所有的讀寫操作都在主庫 此時，從庫的角色只是作為災備。風險分析 從資料一致性的角度來看沒有任何問題，所有讀寫操作都在主庫 隨著業務的前進和流量的激增，會出現大表和資料庫寫入效能下降的問題。我們可以通過分庫的方式，提公升資料庫單機的qps壓下來 通過分表的方式，降低單錶...
資料快取重新整理 快取與資料庫一致性系列 01
今天，我們來分析一下，快取與資料庫被使用次數最多的一種使用方法 第一步先刪除快取，刪除之後再更新db，之後再非同步將資料刷回快取 第一步先讀快取，如果快取沒讀到，則去讀db，之後再非同步將資料刷回快取 what should i say 為什麼說這也算優點呢？試想一下 如果把寫流程改一下 先更新快取...
快取與資料庫一致性保證
本文主要討論這麼幾個問題 1 啥時候資料庫和快取中的資料會不一致 2 不一致優化思路 3 如何保證資料庫與快取的一致性 當資料發生變化時，先淘汰快取，再修改資料庫 這個點是大家討論的最多的。上篇文章得出這個結論的依據是，由於操作快取與運算元據庫不是原子的，非常有可能出現執行失敗。假設先寫資料庫，再淘...