在商業的世界中，常說的一句話是“現金為王”。在網際網路或者移動網際網路乃至整個軟體技術世界中，與之相近的一個說法就是“快取為王”。什麼是快取呢？

1.1 什麼是快取？

快取：儲存在計算機上的一個原始資料複製集，以便易於訪問—— 維基百科

快取是系統快速響應中的一種關鍵技術，是一組被儲存起來以備將來使用的東西，介於應用開發和系統開發之間，是產品經理們經常顧及不到的地方，也是技術架構設計中的非功能性約束。

因為“快取為王”，很多技術都打著快取的旗號，所以談起快取往往似是而非。

例如，CPU的快取，是指位於CPU與記憶體之間的臨時儲存器，容量比記憶體小的多但交換速度卻比記憶體要快得多。由於CPU的運算速度要比記憶體讀寫速度快很多，CPU總有等待資料的時候，而快取記憶體則解決了CPU運算速度與記憶體讀寫速度不匹配的矛盾。快取中的資料是記憶體中的一部分，且這部分是短時間內CPU即將訪問的，當CPU呼叫資料時，先從快取中呼叫，從而加快讀取速度。而且，CPU 是有多級快取的，有時候也稱為幾級流水。

再例如，Linux 作業系統中的檔案快取如圖1-1所示。

我們平時在程式設計的時候，包括CPU接觸到的都是虛擬地址而不是真實的實體地址，這是虛擬記憶體的一大主要功能。假如請求一個頁的地址，需要將頁的虛擬地址轉化為頁的實體地址。頁表(page table)和記憶體管理單元（MMU）就負責將頁的虛擬地址對映到實體地址。頁表負責記錄哪些是物理頁，哪些是虛擬頁，以及這些頁的頁表條目（PTE）。而MMU是一個物理硬體，MMU負責進行虛擬地址進行實體地址的翻譯，翻譯過程中需要從頁表獲取頁的PTE，MMU也會使用翻譯後備快取器（TLB）的快取頁號，所以，在作業系統層面都有快取。

因此，快取與語境有著緊密的關係，快取在不同場景有著不同的意義，採用的技術手段也是不同的。不涉及作業系統和硬體的快取，根據快取在軟體系統中所處位置的不同，大體可以分為三類：

• 客戶端側的快取

• 伺服器側的快取

• 網路中的快取

根據快取的規模和部署方式也可以分為：

• 單體快取

• 快取叢集

• 分散式快取

可見， 在軟體系統中快取幾乎無處不在，這或許就是快取為王的一個原因吧。

1.2 為什麼使用快取？

在看這個問題之前，我們可以先看一下成功的軟體產品具備哪些特點:能解決目標使用者的痛點，能夠為企業或個人帶來利益，具有不錯的使用者粘性…… 其中一個極其重要的因素就是要有好的使用者體驗。

1.2.1 從使用者體驗說起

使用者體驗這個詞最早被廣泛認知是在20世紀90年代中期，由使用者體驗設計師唐納德•諾曼（Donald Norman）提出和推廣。 資訊科技在移動和影象處理等方面取得的進展已經使得人機互動（HCI）技術幾乎滲透到人類活動的所有領域。這導致了一個巨大轉變──系統的評價指標從單純的可用性，擴充套件到範圍更豐富的使用者體驗。使用者體驗在人機互動技術發展過程中受到了相當的重視，其關注度與傳統的三大可用性指標（即效率，效益和基本主觀滿意度）不相上下，甚至比傳統的三大可用性指標的地位更重要。

什麼是使用者體驗？

SO 9241-210標準將使用者體驗定義為 “人們對於針對使用或期望使用的產品、系統或者服務的認知印象和迴應”。因此，使用者體驗是主觀的，且注重實際應用。 ISO在定義的補充說明中有著如下解釋：使用者體驗，即使用者在使用一個產品或系統之前、使用期間和使用之後的全部感受，包括情感、信仰、喜好、認知印象、生理和心理反應、行為和成就等各個方面。 ISO標準暗示了可用性也可以作為使用者體驗的一個方面，“可用性標準可以用來評估使用者體驗一些方面”。不過，該ISO標準並沒有進一步闡述使用者體驗和系統可用性之間的具體關係。顯然，這兩者是相互重疊的概念。

有許多因素可以影響使用者體驗，這些因素被分為三大類：使用者的狀態、系統性能及環境。其中系統性能是軟體產品自身對使用者體驗的關鍵性因素之一。由於感受軟體效能的主體是人，不同的人對於同樣的軟體能有不同的主觀感受，而且不同的人對於軟體效能關心的視角也不同。系統性能是一種非功能特性，它關注的不是某種特定的功能，而是在完成該功能時所展示出來的及時性。

1.2.2 關於系統的效能

系統性能的指標一般包括響應時間、延遲時間、吞吐量，併發使用者數和資源利用率的幾個方面。

響應時間是指系統對使用者請求作出響應的時間，與人對軟體效能的主觀感受是非常一致的，它完整地記錄了整個團結系統處理請求的時間。由於一個系統通常會提供許多功能，而不同功能的處理邏輯也千差萬別，因而不同功能的響應時間也不盡相同，甚至同一功能在不同輸入資料的情況下響應時間也不相同。所以，響應時間通常是指該軟體系統所有功能的平均響應時間或者所有功能中的最大響應時間。當然，有時候也需要對每個或每組功能討論其平均響應時間和最大響應時間。

在討論軟體效能時，我們更關心所開發軟體本身的“響應時間”。也就是說，可以把使用者感受到的響應時間劃分為“呈現時間”和“系統響應時間”，前者是指客戶端在接收到系統資料時呈現頁面所需的時間，而後者是指客戶端接收到使用者請求到客戶端接收到伺服器發來的資料所需的時間。還可以把“系統響應時間”進一步分解為“網路傳輸時間”和“應用延遲時間”，其中前者是指資料在客戶端和伺服器端進行傳輸的時間，而後者是指系統實際處理請求所需的時間。

吞吐量是指系統在單位時間內處理請求的數量。對於無併發的應用系統而言，吞吐量與響應時間成嚴格的反比關係，實際上此時吞吐量就是響應時間的倒數。無併發的應用都是單機應用，對於網際網路或者移動網際網路上的產品而言，併發使用者數是指系統可以同時承載的正常使用系統功能的使用者數量。與吞吐量相比，併發使用者數是一個更直觀但也更籠統的效能指標。而資源利用率反映的是在一段時間內資源平均被佔用的情況。

從瀏覽器到網路，到應用伺服器，甚至到資料庫，通過在各個層面應用快取技術，整個系統的效能將大幅提高。例如，快取離客戶端更近，從快取請求內容比從源伺服器所用時間更少，呈現速度更快，系統就顯得更靈敏。快取資料的重複使用，大大降低了使用者的頻寬使用，其實也是一種變相的省錢（如果流量要付費的話），同時保證了頻寬請求在一個低水平上，更容易維護。所以，使用快取技術，可以降低系統的響應時間，減少網路傳輸時間和應用延遲時間，進而提高了系統的吞吐量，增加了系統的併發使用者數。利用快取還可以最小化系統的工作量，使用了快取就可以不必反覆從資料來源中查詢，快取所建立或提供的同一條資料更好利用了系統的資源。

因此，快取是系統調優時常用且行之有效的手段，無論是作業系統還是應用系統，快取策略無處不在。

音樂是時間的藝術，那麼，快取就是軟體系統中關於時間的藝術。“快取為王”本質上是系統性能為王，對使用者而言就是使用者體驗為王。

1.3 從網站的架構發展看快取

最初的網站可能就是一臺物理主機，放在IDC或者租用的是雲伺服器，上面只執行著應用伺服器和資料庫，LAMP（Linux Apache Mysql Php）就是這樣流行起來的。由於網站具備了一定的特色，吸引了部分使用者的訪問，逐漸會發現系統的壓力越來越大，響應速度越來越慢，而這個時候比較明顯的往往是資料庫與應用的互相影響，於是將應用伺服器和資料庫伺服器從物理上分離開來，變成了兩臺機器，這個時候技術上沒有什麼新的要求，系統又恢復到以前的響應速度了，並且支撐住了更高的流量，並且不會讓資料庫和應用伺服器形成互相的影響。這時網站後臺的簡單架構一般如圖1-2 所示。

圖1-2 簡單的網站架構示意圖

隨著訪問網站的人數越來越多，響應速度又開始變慢了，可能是訪問資料庫的操作太多，導致資料連線競爭激烈，因此快取開始登場。若想通過快取機制來減少資料庫連線資源的競爭和對資料庫讀的壓力，那麼可以選擇採用靜態頁面快取，這樣程式上可以不做修改，就能夠很好地減少對web伺服器的壓力以及減少對資料庫連線資源的競爭。隨後，動態快取登場，將動態頁面裡相對靜態的部分也快取起來，因此考慮採用類似的頁面片段快取策略。

隨著訪問量的持續增加，系統又開始變慢，怎麼辦？資料快取來了，將系統中重複獲取的資料資訊從資料庫載入到本地，同時降低了資料庫的負載。

隨著系統訪問量的再度增加，應用伺服器又扛不住了，開始增加web伺服器。那如何保持應用伺服器中資料快取資訊的同步呢？例如之前快取的使用者資料等，這個時候通常會開始使用快取同步機制以及共享檔案系統或共享儲存等。

在享受了一段時間的訪問量高速增長後，系統再次變慢。開始資料庫調優，優化資料庫自身的快取，接下來是採用資料庫叢集以及分庫分表的策略。分庫分表的規則是有些複雜的，考慮增加一個通用的框架來實現分庫分表的資料訪問，這個就是資料訪問層（Data Access Layer，DAL）。同時，在這個階段可能會發現之前的快取同步方案可能會出現問題，因為資料量太大，導致現在不太可能將快取儲存在本地後在同步，於是分散式快取終於來了，將大量的資料快取轉移到分散式快取上了。

至此，系統進入了無級縮放的大型網站階段，當網站流量增加時，應對的解決方案就是不斷的新增web伺服器，資料庫伺服器，以及快取伺服器了。此時，大型網站的系統架構演變為圖1-3 所示。

圖1-3 大型網站的架構示意圖

縱觀網站架構的發展歷程，業務量的增長是幸福的，但也是成長的煩惱，而快取技術就是解除煩惱的靈丹妙藥，再次證明了什麼是快取為王。

現在，可以從快取在系統中的位置來看看這一王者在系統中各個層面的應用了。

欲瞭解更多有關分散式快取方面的內容，請閱讀《深入分散式快取:從原理到實踐》一書。

京東購書，掃描二維碼：