緩存與數(shù)據(jù)庫一致性問題

問題:

應用中用redis或者memcached等DB緩存方案,當更新數(shù)據(jù)時,是先更新數(shù)據(jù)庫后失效緩存,還是先失效緩存,再更新數(shù)據(jù)庫?

以下分別展開描述:

1,先更新數(shù)據(jù)庫,后失效緩存:方案的優(yōu)點是緩存不miss,缺點是數(shù)據(jù)更新成功但緩存更新失敗,會導致后面讀取到的是更新前的臟數(shù)據(jù);

2,先失效緩存,后更新數(shù)據(jù)庫:方案的優(yōu)點是避免了方案1的問題;正常情況下僅僅是多了一次緩存miss;但如果在并發(fā)的情況下,連接1更新數(shù)據(jù)庫,連接2在連接1更新完成之前訪問DB并讀取到了更新前的數(shù)據(jù),并寫入緩存,這樣會導致獲取到臟數(shù)據(jù);

基于上面的情況,如果在緩存DB一致性要求不高的場景,可以允許有一個緩存周期的臟數(shù)據(jù)的話,則無需考慮;

如果是要求強一致性,則方案1的情況下,后續(xù)的讀請求會讀到cache臟數(shù)據(jù),設置全局flag強制不走cache,直接DB,且同時不斷嘗試更新緩存;直至緩存失效或更新成功;此思路簡便但具有一定不確定性;

上述方案2的話,則需要在并發(fā)寫、讀情況下,對數(shù)據(jù)庫的操作需要保證序列化,也就是保證先寫后讀,按順序執(zhí)行;改造方案:①,保證在單機應用上數(shù)據(jù)庫連接寫讀復用,GetDBConnection(longid);②,分布式應用保證相同ID的請求路由到同一服務實例上GetServiceConnection(longid);也就是分別改動獲取service連接和獲取DB連接的實現(xiàn)方式;

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯(lián)系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發(fā)布,文章內容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容