高性能網(wǎng)站規(guī)劃之緩存更新高性能網(wǎng)站規(guī)劃之緩存更新

看到好些人在寫(xiě)更新緩存數(shù)據(jù)代碼時(shí)，先刪去緩存，然后再更新數(shù)據(jù)庫(kù)，而后續(xù)的操作會(huì)把數(shù)據(jù)再裝載的緩存中。可是，這個(gè)是邏輯是差錯(cuò)的。試想，兩個(gè)并發(fā)操作，一個(gè)是更新操作，另一個(gè)是查詢(xún)操作，更新操作刪去緩存后，查詢(xún)操作沒(méi)有射中緩存，先把老數(shù)據(jù)讀出來(lái)后放到緩存中，然后更新操作更新了數(shù)據(jù)庫(kù)。所以，在緩存中的數(shù)據(jù)仍是老的數(shù)據(jù)，導(dǎo)致緩存中的數(shù)據(jù)是臟的，并且還一貫這樣臟下去了。

我不知道為什么這么多人用的都是這個(gè)邏輯，當(dāng)我在微博上發(fā)了這個(gè)貼往后，我發(fā)現(xiàn)好些人給了許多十分凌亂和古怪的方案，所以，我想寫(xiě)這篇文章說(shuō)一下幾個(gè)緩存更新的Design Pattern（讓我們多一些套路吧）。

這兒，我們先不談?wù)摳戮彺婧透聰?shù)據(jù)這兩個(gè)事是一個(gè)業(yè)務(wù)的事，或是會(huì)有失利的可能，我們先假定更新數(shù)據(jù)庫(kù)和更新緩存都能夠成功的情況（我們先把成功的代碼邏輯先寫(xiě)對(duì)）。

更新緩存的的Design Pattern有四種：Cache aside, Read through, Write through, Write behind caching，我們下面逐一來(lái)看一下這四種Pattern。

Cache Aside Pattern

這是最常用最常用的pattern了。其具體邏輯如下：

失效：運(yùn)用程序先從cache取數(shù)據(jù)，沒(méi)有得到，則從數(shù)據(jù)庫(kù)中取數(shù)據(jù)，成功后，放到緩存中。

射中：運(yùn)用程序從cache中取數(shù)據(jù)，取到后回來(lái)。

更新：先把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中，成功后，再讓緩存失效。

留心，我們的更新是先更新數(shù)據(jù)庫(kù)，成功后，讓緩存失效。那么，這種辦法是否能夠沒(méi)有文章前面提到過(guò)的那個(gè)問(wèn)題呢？我們能夠腦補(bǔ)一下。

一個(gè)是查詢(xún)操作，一個(gè)是更新操作的并發(fā)，首要，沒(méi)有了刪去cache數(shù)據(jù)的操作了，而是先更新了數(shù)據(jù)庫(kù)中的數(shù)據(jù)，此時(shí)，緩存仍然有用，所以，并發(fā)的查詢(xún)操作拿的是沒(méi)有更新的數(shù)據(jù)，可是，更新操作馬上讓緩存的失效了，后續(xù)的查詢(xún)操作再把數(shù)據(jù)從數(shù)據(jù)庫(kù)中拉出來(lái)。而不會(huì)像文章開(kāi)始的那個(gè)邏輯發(fā)作的問(wèn)題，后續(xù)的查詢(xún)操作一貫都在取老的數(shù)據(jù)。

這是標(biāo)準(zhǔn)的design pattern，包含F(xiàn)acebook的論文《Scaling Memcache at Facebook》也運(yùn)用了這個(gè)戰(zhàn)略。為什么不是寫(xiě)完數(shù)據(jù)庫(kù)后更新緩存？你能夠看一下Quora上的這個(gè)問(wèn)答《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》，主要是怕兩個(gè)并發(fā)的寫(xiě)操作導(dǎo)致臟數(shù)據(jù)。

那么，是不是Cache Aside這個(gè)就不會(huì)有并發(fā)問(wèn)題了？不是的，比方，一個(gè)是讀操作，可是沒(méi)有射中緩存，然后就到數(shù)據(jù)庫(kù)中取數(shù)據(jù)，此時(shí)來(lái)了一個(gè)寫(xiě)操作，寫(xiě)完數(shù)據(jù)庫(kù)后，讓緩存失效，然后，之前的那個(gè)讀操作再把老的數(shù)據(jù)放進(jìn)去，所以，會(huì)構(gòu)成臟數(shù)據(jù)。

但，這個(gè)case理論上會(huì)出現(xiàn)，不過(guò)，實(shí)際上出現(xiàn)的概率可能十分低，由于這個(gè)條件需求發(fā)作在讀緩存時(shí)緩存失效，并且并發(fā)著有一個(gè)寫(xiě)操作。而實(shí)際上數(shù)據(jù)庫(kù)的寫(xiě)操作會(huì)比讀操作慢得多，并且還要鎖表，而讀操作必需在寫(xiě)操作跋涉入數(shù)據(jù)庫(kù)操作，而又要晚于寫(xiě)操作更新緩存，一切的這些條件都具有的概率根柢并不大。

所以，這也就是Quora上的那個(gè)答案里說(shuō)的，要么通過(guò)2PC或是Paxos協(xié)議保證一致性，要么就是拼命的下降并發(fā)時(shí)臟數(shù)據(jù)的概率，而Facebook運(yùn)用了這個(gè)下降概率的玩法，由于2PC太慢，而Paxos太凌亂。當(dāng)然，最好仍是為緩存設(shè)置上過(guò)期時(shí)間。

Read/Write Through Pattern

我們能夠看到，在上面的Cache Aside套路中，我們的運(yùn)用代碼需求維護(hù)兩個(gè)數(shù)據(jù)存儲(chǔ)，一個(gè)是緩存（Cache），一個(gè)是數(shù)據(jù)庫(kù)（Repository）。所以，運(yùn)用程序比較煩瑣。而Read/Write Through套路是把更新數(shù)據(jù)庫(kù)（Repository）的操作由緩存自己代理了，所以，關(guān)于運(yùn)用層來(lái)說(shuō)，就簡(jiǎn)略許多了。能夠理解為，運(yùn)用認(rèn)為后端就是一個(gè)單一的存儲(chǔ)，而存儲(chǔ)自己維護(hù)自己的Cache。

Read Through

Read Through 套路就是在查詢(xún)操作中更新緩存，也就是說(shuō)，當(dāng)緩存失效的時(shí)分（過(guò)期或LRU換出），Cache Aside是由調(diào)用方擔(dān)任把數(shù)據(jù)加載入緩存，而Read Through則用緩存效能自己來(lái)加載，然后對(duì)運(yùn)用方是透明的。

Write Through

Write Through 套路和Read Through相仿，不過(guò)是在更新數(shù)據(jù)時(shí)發(fā)作。當(dāng)有數(shù)據(jù)更新的時(shí)分，假定沒(méi)有射中緩存，直接更新數(shù)據(jù)庫(kù)，然后回來(lái)。假定射中了緩存，則更新緩存，然后再由Cache自己更新數(shù)據(jù)庫(kù)（這是一個(gè)同步操作）

下圖自來(lái)Wikipedia的Cache詞條。其間的Memory你能夠理解為就是我們比方里的數(shù)據(jù)庫(kù)。

Write Behind Caching Pattern

Write Behind 又名 Write Back。一些了解Linux操作體系內(nèi)核的同學(xué)對(duì)write back應(yīng)該十分了解，這不就是Linux文件體系的Page Cache的算法嗎？是的，你看根底這玩意全都是相通的。所以，根底很重要，我現(xiàn)已不是一次說(shuō)過(guò)根底很重要這事了。

Write Back套路，一句說(shuō)就是，在更新數(shù)據(jù)的時(shí)分，只更新緩存，不更新數(shù)據(jù)庫(kù)，而我們的緩存會(huì)異步地批量更新數(shù)據(jù)庫(kù)。這個(gè)規(guī)劃的利益就是讓數(shù)據(jù)的I/O操作飛快無(wú)比（由于直接操作內(nèi)存嘛 ），由于異步，write backg還能夠吞并對(duì)同一個(gè)數(shù)據(jù)的多次操作，所以功用的跋涉是相當(dāng)可觀(guān)的。

可是，其帶來(lái)的問(wèn)題是，數(shù)據(jù)不是強(qiáng)一致性的，并且可能會(huì)丟掉（我們知道Unix/Linux非正常關(guān)機(jī)遇導(dǎo)致數(shù)據(jù)丟掉，就是由于這個(gè)事）。在軟件規(guī)劃上，我們根柢上不可能做出一個(gè)沒(méi)有缺陷的規(guī)劃，就像算法規(guī)劃中的時(shí)間換空間，空間換時(shí)間一個(gè)道理，有時(shí)分，強(qiáng)一致性和高功用，高可用和高性性是有沖突的。軟件規(guī)劃向來(lái)都是取舍Trade-Off。

其他，Write Back完畢邏輯比較凌亂，由于他需求track有哪數(shù)據(jù)是被更新了的，需求刷到耐久層上。操作體系的write back會(huì)在僅當(dāng)這個(gè)cache需求失效的時(shí)分，才會(huì)被實(shí)在耐久起來(lái)，比方，內(nèi)存不夠了，或是進(jìn)程退出了等情況，這又名lazy write。

在wikipedia上有一張write back的流程圖，根柢邏輯如下：

再多煩瑣一些

1）上面講的這些Design Pattern，其實(shí)并不是軟件架構(gòu)里的mysql數(shù)據(jù)庫(kù)和memcache/redis的更新戰(zhàn)略，這些東西都是核算機(jī)體系結(jié)構(gòu)里的規(guī)劃，比方CPU的緩存，硬盤(pán)文件體系中的緩存，硬盤(pán)上的緩存，數(shù)據(jù)庫(kù)中的緩存。根柢上來(lái)說(shuō)，這些緩存更新的規(guī)劃辦法都是十分老古董的，并且歷經(jīng)長(zhǎng)時(shí)間檢測(cè)的戰(zhàn)略，所以這也就是，工程學(xué)上所謂的Best Practice，遵從就好了。

2）有時(shí)分，我們覺(jué)得能做微觀(guān)的體系架構(gòu)的人一定是很有經(jīng)歷的，其實(shí)，微觀(guān)體系架構(gòu)中的許多規(guī)劃都來(lái)源于這些微觀(guān)的東西。比方，云核算中的許多虛擬化技術(shù)的原理，和傳統(tǒng)的虛擬內(nèi)存不是很像么？Unix下的那些I/O模型，也擴(kuò)展到了架構(gòu)里的同步異步的模型，還有Unix創(chuàng)造的管道不就是數(shù)據(jù)流式核算架構(gòu)嗎？TCP的好些規(guī)劃也用在不同體系間的通訊中，細(xì)心看看這些微觀(guān)層面，你會(huì)發(fā)現(xiàn)有許多規(guī)劃都十分精妙……所以，請(qǐng)容許我在這兒放句觀(guān)點(diǎn)鮮明的話(huà)——假定你要做好架構(gòu)，首要你得把核算機(jī)體系結(jié)構(gòu)以及許多老古董的根底技術(shù)吃透了。

3）在軟件開(kāi)發(fā)或規(guī)劃中，我十分主張?jiān)谥跋热⒖匆幌乱延械囊?guī)劃和思路，看看相應(yīng)的guideline，best practice或design pattern，吃透了已有的這些東西，再挑選是否要從頭創(chuàng)造輪子。千萬(wàn)不要貌同實(shí)異地，想當(dāng)然的做軟件規(guī)劃。

4）上面，我們沒(méi)有考慮緩存（Cache）和耐久層（Repository）的整體業(yè)務(wù)的問(wèn)題。比方，更新Cache成功，更新數(shù)據(jù)庫(kù)失利了怎樣嗎？或是反過(guò)來(lái)。關(guān)于這個(gè)事，假定你需求強(qiáng)一致性，你需求運(yùn)用“兩階段提交協(xié)議”——prepare, commit/rollback，比方Java 7 的XAResource，還有MySQL 5.7的 XA Transaction，有些cache也支撐XA，比方EhCache。當(dāng)然，XA這樣的強(qiáng)一致性的玩法會(huì)導(dǎo)致功用下降，關(guān)于分布式的業(yè)務(wù)的相關(guān)論題，你能夠看看《分布式體系的業(yè)務(wù)處理》一文。

文章標(biāo)簽：網(wǎng)站建設(shè)|網(wǎng)站制作|網(wǎng)頁(yè)設(shè)計(jì)|網(wǎng)站建設(shè)源碼_創(chuàng)新互聯(lián)

網(wǎng)頁(yè)題目：高性能網(wǎng)站規(guī)劃之緩存更新高性能網(wǎng)站規(guī)劃之緩存更新
網(wǎng)址分享：http://www.rwnh.cn/news/128810.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、軟件開(kāi)發(fā)、網(wǎng)站制作、微信小程序、網(wǎng)站建設(shè)、網(wǎng)站導(dǎo)航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)