緩存
在系統中最消耗性能的地方就是對數據庫的訪問了，一般來說，增、刪、改操作不會出現什麼性能問題，除非索引太多，並且數據量有十分龐大的情況下，這三個操作纔會導致性能問題。一般可以限制單表索引的數量來提升性能，比如單表的索引數量不能超過5個。
絕大多數情況下，性能問題都出在查詢上，select操作提供了非常豐富的語法，這些語法包括函數，子查詢，like子句，where子句等，這些查詢都是非常消耗性能的。大部分應用都是讀多寫少的應用，所以查詢慢的問題會被放大了，導致慢查詢成爲了系統性能的瓶頸，這是就需要用到緩存來提高系統的性能。
緩存爲什麼能提供系統性能？
緩存通過減少系統對數據庫的訪問量來提高系統性能。試想一下，如果有100個請求同時請求同一個數據，沒有加緩存之前，需要訪問100次數據庫，而加了緩存之後，可能只需訪問1次數據庫，剩下的99個請求的數據從緩存中取，大大的較少了數據庫的訪問量，雖然同樣需要訪問100次，但數據庫的讀取性能和緩存的讀取性能不在一個級別上，所以對系統性能提升顯著。爲什麼說可能需要訪問1次數據庫呢，這個和過期有關，後面會講。
更新模式
既然知道了緩存對系統性能提升顯著，那下面先來了解一下緩存如何更新吧。
Cache Aside（推薦）
這應該是最常用的更新模式了，這種模式大致流程如下：
-
讀取
- 如果緩存中沒有，則再從數據庫中讀取數據，得到數據之後，放入緩存。
- 如果緩存中有，取到後直接返回。
-
更新
先更新數據庫裏的數據，成功後，讓緩存失效。
爲什麼是讓緩存失效而不是更新緩存呢？
主要是因爲兩個併發寫操作導致髒數據。試想一下，有兩個線程A和B，分別要將資源A的值修改爲1和2，線程A先到達數據庫把數據更新爲1，但還沒更新緩存，由於時間片用完了，此時線程B獲得了CPU，並在這期間把數據庫資源A的值和緩存的值都更新爲2，線程B結束後，線程A重新獲得CPU，執行更新緩存，把資源A的值改爲1，線程A結束。此時，數據庫中A的值爲2，而緩存中A的值爲1，數據不一致。所以讓緩存失效就不會有這個問題，保證緩存中的數據和數據庫的保持一致。
那是不是Cache Aside模式就不會有併發問題了呢？
不是的。 比如，一個讀操作，沒有命中緩存，就去數據的讀取數據（A=1），此時一個寫操作，更新數據庫數據（A=2）並讓緩存失效，此時讀操作把讀取到的數據（A=1）寫到緩存中，導致髒數據。
這種情況理論上會出現，但現實情況中出現的機率極低。要這種情況出現必須在一個讀操作發生時，有一個併發寫操作，並且既要讀操作要於寫操作寫入前讀取，又要後於寫操作寫入緩存。滿足這種條件的概率並不大。
基於出現上面所描述的問題，目前有兩種比較合理的解決方案：
- 通過2PC這種保證數據的一致性（複雜）；
- 通過降低併發時髒數據的概率，並設置合理的過期時間（簡單，但存在一定時間內的錯誤率，一般可以接受）。
Read/Write Through
在這種模式下，對於應用程序來說，所有的讀寫請求都是直接和緩存打交道，關於數據庫的數據完全由緩存服務來更新（更新同步爲同步操作）。
這種模式下流程就相當簡單了，完全就是對緩存的讀寫。
缺點：這種模式對緩存服務有強依賴性，要求緩存具備高可用性。所以應有沒有上一種普遍。
Write Behind Caching
其實這個模式就是Read/Write Through的一個變種，區別就在於前者是異步更新，後者是同步更新。
既然是異步更新數據庫，他的相應速度比Read/Write Through還要高，並且還能合併對同一個數據的多次操作。這個有點像MySQL的buffer pool的刷盤操作。
缺點：異步就代表數據不是強一致性的，還存在數據丟失的風險，實現邏輯也較爲複雜。
設計思路
無狀態的服務
在分佈式系統中，無狀態的服務有利於橫向擴展，所以緩存也應該獨立於業務服務在外，設計成一個獨立的服務，使業務服務變成無狀態的。很多公司都選擇是用Redis來搭建他們的緩存系統，取決於其高速的讀寫性能。
命中率
一個緩存服務的好壞主要看命中率，一般來說，命中率保存在80%以上已經算很高了，但我們不能爲了提高命中率而把數據庫的全部數據的寫到緩存了，這個是不符合緩存的設計理念，而且需要極大的內存空間。**通常來說，應該只有小部分熱點數據寫到緩存。**緩存是通過犧牲強一致性來換取性能的，並不是所有的業務的適合使用緩存。
有效時間
緩存數據的有效時間不易過短，不易過長，不易過於集中。
-
過短，會增加數據庫訪問的次數。
-
過長容易不使用的數據一直停留在緩存中，浪費空間，並且一旦產生髒數據，過程的有效時間會導致髒數據遲遲無法失效，進而導致影響更多的業務。
-
過於集中，會導致緩存雪崩。
淘汰策略
當內存不足時，緩存系統就要按照淘汰策略，把不適合留在緩存的數據淘汰掉，騰出位置給新數據。下面就以Redis爲例，給出了淘汰策略：
- noeviction: 不刪除策略, 達到最大內存限制時, 如果需要更多內存, 直接返回錯誤信息(有極少數會例外, 如 DEL )。
- allkeys-lru: 所有key通用，優先刪除最近最少使用(less recently used ,LRU) 的 key。（推薦）
- volatile-lru: 只限於設置了 expire 的部分，優先刪除最近最少使用(less recently used ,LRU) 的 key。
- allkeys-random: 所有key通用，隨機刪除一部分 key。
- volatile-random: 只限於設置了 expire 的部分，隨機刪除一部分 key。
- volatile-ttl: 只限於設置了 expire 的部分，優先刪除剩餘時間(time to live,TTL) 短的key。
可根據項目實際情況進行選擇。
小結
緩存是爲了加速數據的訪問，在數據庫之上的一直機制，並非所有業務都適合使用緩存，要根據具體情況選擇更新策略和淘汰策略。