高性能網站規劃之緩存更新高性能網站規劃之緩存更新
看到好些人在寫更新緩存數據代碼時，先刪去緩存，然后再更新數據庫，而后續的操作會把數據再裝載的緩存中。可是，這個是邏輯是差錯的。試想，兩個并發操作，一個是更新操作，另一個是查詢操作，更新操作刪去緩存后，查詢操作沒有射中緩存，先把老數據讀出來后放到緩存中，然后更新操作更新了數據庫。所以，在緩存中的數據仍是老的數據，導致緩存中的數據是臟的，并且還一貫這樣臟下去了。
我不知道為什么這么多人用的都是這個邏輯，當我在微博上發了這個貼往后，我發現好些人給了許多十分凌亂和古怪的方案，所以，我想寫這篇文章說一下幾個緩存更新的design pattern（讓我們多一些套路吧）。
這兒，我們先不談論更新緩存和更新數據這兩個事是一個業務的事，或是會有失利的可能，我們先假定更新數據庫和更新緩存都能夠成功的情況（我們先把成功的代碼邏輯先寫對）。
更新緩存的的design pattern有四種：cache aside, read through, write through, write behind caching，我們下面逐一來看一下這四種pattern。
cache aside pattern
這是最常用最常用的pattern了。其具體邏輯如下：
失效：運用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功后，放到緩存中。
射中：運用程序從cache中取數據，取到后回來。
更新：先把數據存到數據庫中，成功后，再讓緩存失效。
留心，我們的更新是先更新數據庫，成功后，讓緩存失效。那么，這種辦法是否能夠沒有文章前面提到過的那個問題呢？我們能夠腦補一下。
一個是查詢操作，一個是更新操作的并發，首要，沒有了刪去cache數據的操作了，而是先更新了數據庫中的數據，此時，緩存仍然有用，所以，并發的查詢操作拿的是沒有更新的數據，可是，更新操作馬上讓緩存的失效了，后續的查詢操作再把數據從數據庫中拉出來。而不會像文章開始的那個邏輯發作的問題，后續的查詢操作一貫都在取老的數據。
這是標準的design pattern，包含facebook的論文《scaling memcache at facebook》也運用了這個戰略。為什么不是寫完數據庫后更新緩存？你能夠看一下quora上的這個問答《why does facebook use delete to remove the key-value pair in memcached instead of updating the memcached during write request to the backend?》，主要是怕兩個并發的寫操作導致臟數據。
那么，是不是cache aside這個就不會有并發問題了？不是的，比方，一個是讀操作，可是沒有射中緩存，然后就到數據庫中取數據，此時來了一個寫操作，寫完數據庫后，讓緩存失效，然后，之前的那個讀操作再把老的數據放進去，所以，會構成臟數據。
但，這個case理論上會出現，不過，實際上出現的概率可能十分低，由于這個條件需求發作在讀緩存時緩存失效，并且并發著有一個寫操作。而實際上數據庫的寫操作會比讀操作慢得多，并且還要鎖表，而讀操作必需在寫操作跋涉入數據庫操作，而又要晚于寫操作更新緩存，一切的這些條件都具有的概率根柢并不大。
所以，這也就是quora上的那個答案里說的，要么通過2pc或是paxos協議保證一致性，要么就是拼命的下降并發時臟數據的概率，而facebook運用了這個下降概率的玩法，由于2pc太慢，而paxos太凌亂。當然，最好仍是為緩存設置上過期時間。
read/write through pattern
我們能夠看到，在上面的cache aside套路中，我們的運用代碼需求維護兩個數據存儲，一個是緩存（cache），一個是數據庫（repository）。所以，運用程序比較煩瑣。而read/write through套路是把更新數據庫（repository）的操作由緩存自己代理了，所以，關于運用層來說，就簡略許多了。能夠理解為，運用認為后端就是一個單一的存儲，而存儲自己維護自己的cache。
read through
read through 套路就是在查詢操作中更新緩存，也就是說，當緩存失效的時分（過期或lru換出），cache aside是由調用方擔任把數據加載入緩存，而read through則用緩存效能自己來加載，然后對運用方是透明的。
write through
write through 套路和read through相仿，不過是在更新數據時發作。當有數據更新的時分，假定沒有射中緩存，直接更新數據庫，然后回來。假定射中了緩存，則更新緩存，然后再由cache自己更新數據庫（這是一個同步操作）
下圖自來wikipedia的cache詞條。其間的memory你能夠理解為就是我們比方里的數據庫。
write behind caching pattern
write behind 又名 write back。一些了解linux操作體系內核的同學對write back應該十分了解，這不就是linux文件體系的page cache的算法嗎？是的，你看根底這玩意全都是相通的。所以，根底很重要，我現已不是一次說過根底很重要這事了。
write back套路，一句說就是，在更新數據的時分，只更新緩存，不更新數據庫，而我們的緩存會異步地批量更新數據庫。這個規劃的利益就是讓數據的i/o操作飛快無比（由于直接操作內存嘛 ），由于異步，write backg還能夠吞并對同一個數據的多次操作，所以功用的跋涉是相當可觀的。
可是，其帶來的問題是，數據不是強一致性的，并且可能會丟掉（我們知道unix/linux非正常關機遇導致數據丟掉，就是由于這個事）。在軟件規劃上，我們根柢上不可能做出一個沒有缺陷的規劃，就像算法規劃中的時間換空間，空間換時間一個道理，有時分，強一致性和高功用，高可用和高性性是有沖突的。軟件規劃向來都是取舍trade-off。
其他，write back完畢邏輯比較凌亂，由于他需求track有哪數據是被更新了的，需求刷到耐久層上。操作體系的write back會在僅當這個cache需求失效的時分，才會被實在耐久起來，比方，內存不夠了，或是進程退出了等情況，這又名lazy write。
在wikipedia上有一張write back的流程圖，根柢邏輯如下：
再多煩瑣一些
1）上面講的這些design pattern，其實并不是軟件架構里的mysql數據庫和memcache/redis的更新戰略，這些東西都是核算機體系結構里的規劃，比方cpu的緩存，硬盤文件體系中的緩存，硬盤上的緩存，數據庫中的緩存。根柢上來說，這些緩存更新的規劃辦法都是十分老古董的，并且歷經長時間檢測的戰略，所以這也就是，工程學上所謂的best practice，遵從就好了。
2）有時分，我們覺得能做微觀的體系架構的人一定是很有經歷的，其實，微觀體系架構中的許多規劃都來源于這些微觀的東西。比方，云核算中的許多虛擬化技術的原理，和傳統的虛擬內存不是很像么？unix下的那些i/o模型，也擴展到了架構里的同步異步的模型，還有unix創造的管道不就是數據流式核算架構嗎？tcp的好些規劃也用在不同體系間的通訊中，細心看看這些微觀層面，你會發現有許多規劃都十分精妙……所以，請容許我在這兒放句觀點鮮明的話——假定你要做好架構，首要你得把核算機體系結構以及許多老古董的根底技術吃透了。
3）在軟件開發或規劃中，我十分主張在之前先去參看一下已有的規劃和思路，看看相應的guideline，best practice或design pattern，吃透了已有的這些東西，再挑選是否要從頭創造輪子。千萬不要貌同實異地，想當然的做軟件規劃。
4）上面，我們沒有考慮緩存（cache）和耐久層（repository）的整體業務的問題。比方，更新cache成功，更新數據庫失利了怎樣嗎？或是反過來。關于這個事，假定你需求強一致性，你需求運用“兩階段提交協議”——prepare, commit/rollback，比方java 7 的xaresource，還有mysql 5.7的 xa transaction，有些cache也支撐xa，比方ehcache。當然，xa這樣的強一致性的玩法會導致功用下降，關于分布式的業務的相關論題，你能夠看看《分布式體系的業務處理》一文。



電商怎樣做才能快速實現營銷？
網站優化中外鏈建設有哪些技巧？
搜索引擎市場份額排行榜
寧波網站制作令用戶反感的設計有什么
SEO基礎5個要素有哪些?
設計師如何向工程師描述你的動效？
蘭州網站seo營銷優化的5個優勢
新產品軟文推廣如何做?