作者介紹：陳斌，易寶支付 CTO，《架構即未來》、《架構真經(jīng)》等書譯者，1024 學院互聯(lián)網(wǎng) CTO 班幽谷派掌門。

正文

在商業(yè)世界中，人們常說“現(xiàn)金為王”。然而，在技術世界里，我們卻說“緩存為王”。 從瀏覽器到應用前端、應用后端、數(shù)據(jù)庫，每一層都可以通過緩存來顯著地提高系統(tǒng)的擴展能力，改善系統(tǒng)的響應能力，同時減少系統(tǒng)的負擔。

互聯(lián)網(wǎng)平臺上的內(nèi)容可以分為靜態(tài)和動態(tài)兩種。靜態(tài)內(nèi)容指那些不經(jīng)常改變的文本和圖像。動態(tài)內(nèi)容是指隨著時間的推移，不斷變化的內(nèi)容。本文主要討論靜態(tài)內(nèi)容實現(xiàn)緩存的七種不同方法。

1 利用 CDN 實現(xiàn)緩存

CDN，即內(nèi)容分發(fā)網(wǎng)絡，是通過骨干網(wǎng)絡把一組計算機連接起來，存儲客戶數(shù)據(jù)或內(nèi)容的副本。通過在不同的網(wǎng)絡，策略性地通過部署邊緣服務器和應用大量的技術和算法，把用戶的請求指定到最佳響應節(jié)點上。這種優(yōu)化的邏輯可以是基于最少網(wǎng)絡跳轉數(shù)量、最高系統(tǒng)可用性或最少的請求數(shù)量。這種優(yōu)化常常聚焦在減少最終用戶、請求者或服務可以感知的響應時間。

上圖解釋了這種方法在實際環(huán)境中的工作機制。假定某網(wǎng)站因為流量太大，決定采用 CDN 來解決問題。首先，會在域名服務器上新建一個別名把用戶的請求從www.akfpartners.com/techblog指向1107.c.cdn_vendor.net（參見上圖中的 DNS 表）。其次，當用戶瀏覽器向域名服務查詢（步驟 1）akfpartners.com時，接收到返回的 CDN 域名（步驟 2），然后，再對 CDN 域名進行另一輪域名服務查詢（步驟 3），接收到返回的與1107.c.cdn_vendor.net相關的 IP 地址（步驟 4），最后，接收請求并將其路由到服務網(wǎng)站的某個 IP（步驟 5 – 6）。網(wǎng)站的內(nèi)容緩存在 CDN 服務器上，CDN 服務器定期查詢網(wǎng)站的源服務器以便更新。

正如本例所示，在網(wǎng)站服務器前使用 CDN 的效果是，CDN 負責處理所有的請求，只有當需要查詢緩沖內(nèi)容是否更新時才會訪問源服務器。因此，只需要購買少量低配置的服務器和網(wǎng)絡帶寬，以及少數(shù)維護基礎設施的人員。無論網(wǎng)站的網(wǎng)頁是動態(tài)還是靜態(tài)，都可以考慮加入 CDN 形成混合緩存。該層緩存可以提供快速交付的好處，通常有非常高的可用性，而且網(wǎng)站服務器處理更少的流量。

2 利用 HTTP 頭來靈活管理緩存

HTTP 頭提供了有關代理緩存的有效控制，這些 HTTP 頭在 HTML 中看不到，而是由網(wǎng)絡服務器或生成頁面的代碼動態(tài)生成。通過服務器配置或代碼來控制。一個典型的 HTTP 響應頭看起來可能像這樣：

HTTP Status Code: HTTP/1.1 200 OK Date: Thu, 21 Oct 2015 20:03:38 GMT Server: Apache/2.2.9 (Fedora) X-Powered-By: PHP/5.2.6 Expires: Mon, 26 Jul 2016 05:00:00 GMT Last-Modified: Thu, 21 Oct 2015 20:03:38 GMT Cache-Control: no-cache Vary: Accept-Encoding, User-Agent Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8

與緩存最相關的頭是 Expires 和 Cache-Control，Expires 實體頭字段提供響應有效期信息。如果想要把響應標記為“永不過期”，源服務器就應發(fā)送從響應時間算起一年后的日期。在前面例子中，注意到 Expires 頭標識日期為 2017 年 5 月 12 日 05:00GMT。如果今天是 2017 年 4 月 12 日，請求的頁面將在大約一個月后過期，瀏覽器應在那個時候從服務器獲取數(shù)據(jù)以刷新內(nèi)容。

Cache-Control 通用頭字段，用于按 RFC2616 第 14 節(jié)定義的HTTP1.1協(xié)議定義指令，沿請求/響應鏈的所有緩存機制必須遵守這些指令。該頭可以發(fā)出許多指令，包括public、private、no-cache和max-age。如果響應同時包含 Expires頭和max-age指令，即使 Expires 限制較多，max-age指令的優(yōu)先級同樣高過 Expires 頭。以下是一些 Cache-Control 指令的定義：

• public，響應可以由任何緩存、共享或非共享緩存來處理。
• private，響應針對單用戶，不能放在由共享緩存。
• no-cache，在與源服務器確認之前，不得使用緩存來滿足后續(xù)的其他請求。
• max-age，如果當前數(shù)值大于在請求時給定的值（秒），那么響應過時。

設置 HTTP 頭有幾種方式，包括通過網(wǎng)絡服務器和代碼。Apache2.2 的配置設置在httpd.conf文件。Expires 頭要求把mod_expires模塊添加到 Apache。Expires 模塊有三條基本指令，第一條 ExpiresActive 告訴服務器激活該模塊；第二條指令 ExpiresByType 設置 Expires 服務特定類型的對象（如圖片或文本）；第三個指令 ExpiresDefault 設置如何處理所有未指定類型的對象。參見下面的代碼示例：

xpiresActive On ExpiresByType image/png "access plus 1 day" ExpiresByType image/gif "modification plus 5 hours" ExpiresByType text/html "access plus 1 month 15 days 2 hours" ExpiresDefault "access plus 1 month"

在 HTTP 設置 Expires、Cache-Control 和其他頭的另外一種方法是在代碼中實現(xiàn)。PHP 直接利用header()命令發(fā)送原始的 HTTP 頭。在任何輸出前必須通過 HTML 標簽或從 PHP 代碼調(diào)用header()命令。關于頭設置，參見下面的 PHP 示例代碼。其他語言也有類似的頭設置方法。

<?php header("Expires: 0"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("cache-control: no-store, no-cache, must-revalidate"); header("Pragma: no-cache"); ?>

最后一個主題涉及到調(diào)整網(wǎng)絡服務器的配置，以優(yōu)化其性能與可擴展性。keep-alives 或 HTTP 持久連接允許多個 HTTP 請求復用 TCP 連接。在 HTTP1.1中，所有的連接都是持久的，大多數(shù)網(wǎng)絡服務器默認允許保持連接。根據(jù) Apache 文檔記載，使用連接保持可以使 HTML 頁面延遲減少了 50%。在 Apache 的httpd.conf文件中 keep-alives 的默認設置為打開，但 KeepAliveTimeOut 的默認值只設置為 5 秒。超時設置較長的好處是不必建立、使用和終結 TCP 連接就可以處理更多的 HTTP 請求，超時設置較短的好處是網(wǎng)絡服務器的線程不會被捆綁住，可以繼續(xù)服務其他請求。根據(jù)應用或網(wǎng)站的具體情況在兩者之間尋找平衡點很重要。

有一個實際的例子，利用 AOL 研發(fā)的開源的網(wǎng)頁測試工具webpagetest.org，對某網(wǎng)站做了一個測試。測試對象是一個運行在 2.2 版的 Apache HTTP 服務器上的簡單 MediaWiki.

上圖給出了在關閉 keep-alives 同時，不設置 Expires 頭的情況下測試 Wiki 頁面的結果。頁面初始加載時間為 3.8 秒，重復瀏覽時間為 2.3 秒。

上圖顯示的是，在打開 keep-alives 并且設置 Expires 頭的情況下測試 Wiki 頁面的結果。頁面的初始加載時間為 2.6 秒，重復瀏覽時間為 1.4 秒。此舉減少了 32% 的頁面初始加載時間和 37% 的重復頁面加載時間！

3 利用 Ajax 實現(xiàn)緩存

2005 年杰西·詹姆斯·加勒特在他的文章《 Ajax ：一種網(wǎng)絡應用的新方法》中創(chuàng)造了 Ajax 這個術語。Ajax 是 Asynchronous JavaScript and XML 的縮寫。雖然我們經(jīng)常把它作為一種技術，但更為貼切的描述是一組技巧、語言和在瀏覽器（或客戶端）上使用的方法，有助于為最終用戶帶來更豐富內(nèi)容和更實時體驗。

因為可以減少數(shù)據(jù)在網(wǎng)絡上不必要的往復傳遞，從而使用戶與瀏覽器之間的互動更容易，用戶交互因此可以更迅速地發(fā)生。用戶不用等待服務器的響應就可以放大或縮小圖片，下拉菜單可以根據(jù)以前的輸入預先安排好，當用戶在搜索欄輸入查詢關鍵詞時，就可以開始看到那些可能會感興趣并起到引導作用的潛在搜索詞。Ajax 的異步特性還可以幫助我們，在往客戶端瀏覽器加載郵件時，可以根據(jù)用戶的某些動作來判斷是否要繼續(xù)接收郵件，而不必等用戶點擊“下一頁”按鈕。

但是其中的一些動作不利于平臺的擴展，以用戶在網(wǎng)站上輸入某個特定商品的搜索關鍵詞為例。我們可能想用商品目錄來填充搜索建議，即那些當用戶鍵入搜索條件時出現(xiàn)的關鍵詞。Ajax 可以通過用戶后續(xù)的每個按鍵向服務器發(fā)送請求，根據(jù)已鍵入的詞而返回搜索結果，并在不需要用戶介入刷新瀏覽器的情況下，把搜索結果填充到下拉菜單。有可能返回的是基于用戶不完全鍵入的字符串而獲得的完整搜索結果！許多搜索引擎和電子商務網(wǎng)站都可以找到這種實施的例子。以每個后續(xù)按鍵為基礎最終形成搜索服務器需要的查詢語句，可能既昂貴也浪費我們的后臺系統(tǒng)資源。例如，當用戶輸入 “Beanie Baby” 時，可能會帶來連續(xù) 11 次的搜索，其實真正只需要一次。用戶的體驗可能很奇妙，但如果用戶按鍵速度很快，在打完字前，實際上多達 8-10 次的搜索可能永遠沒有機會返回結果。

我們的目標是減少在網(wǎng)絡上來回傳輸數(shù)據(jù)，以減少用戶感知的響應時間和降低服務器的負載。因此，響應頭中的 Expires 設置的有效期應足夠長，這樣，瀏覽器會在本地緩存第一次查詢的結果，并在后續(xù)請求中反復使用。靜態(tài)或半靜態(tài)的對象，如公司商標或者簡介圖片，其有效期應該設置成幾天或更長。某些對象的時間敏感性可能很強，如閱讀好友的狀態(tài)更新。在這些情況下，應該把 Expires 頭設置為數(shù)秒甚至數(shù)分鐘，以給用戶實時的感覺，同時降低整體的負載。

數(shù)據(jù)集是靜態(tài)甚至半動態(tài)的情況（例如，有限的或上下文敏感的產(chǎn)品目錄）很容易解決。從客戶端看，以異步的方式獲取這些結果，然后緩存起來供同一客戶端以后使用，或者更重要的是確保 CDN、中間緩存或代理存儲它們，以利于其他的用戶進行類似的搜索。

下面給出了一個不太好的 Ajax 調(diào)用案例和一個比較好的響應案例。不太好的調(diào)用案例看起來可能像下面這樣：

HTTP Status Code: HTTP/1.1 200 OK Date: Thu, 21 Oct 2015 20:03:38 GMT Server: Apache/2.2.9 (Fedora) X-Powered-By: PHP/5.2.6 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Thu, 21 Oct 2015 20:03:38 GMT Pragma: no-cache Vary: Accept-Encoding,User-Agent Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8

從上面的信息中可以發(fā)現(xiàn) Expires 頭發(fā)生在過去，完全丟失 Cache-Control 頭，Last-Modified 頭與響應發(fā)送的時間一致。這些設置迫使所有的 GETs 都得抓取新的內(nèi)容。一個更容易緩存 Ajax 結果的比較好的響應該是這樣的：

HTTP Status Code: HTTP/1.1 200 OK Date: Thu, 21 Oct 2015 20:03:38 GMT Server: Apache/2.2.9 (Fedora) X-Powered-By: PHP/5.2.6 Expires: Sun, 26 Jul 2020 05:00:00 GMT Last-Modified: Thu, 31 Dec 1970 20:03:38 GMT Cache-Control: public Pragma: no-cache Vary: Accept-Encoding,User-Agent Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8

在本例中，Expires 標頭設置為遙遠的將來，Last-Modified 頭設置為滄桑的過去，并通過 Cache-Control: public告訴中間代理，他們可以緩存并在其他系統(tǒng)復用對象。

4 利用頁面緩存

頁面緩存是部署在網(wǎng)絡服務器前面的緩存服務器，用來減少靜態(tài)和動態(tài)對象對這些服務器的請求。這樣的系統(tǒng)或服務器的其他常見名稱是反向代理緩存、反向代理服務器和反向代理。我們特別使用頁面緩存這個術語，因為代理還負責負載均衡或 SSL 加速，代理緩存的實施看起來像下圖。

頁面緩存處理某些或所有的請求，直到所存儲的頁面或者數(shù)據(jù)過時，或服務器查詢不到用戶請求需要的數(shù)據(jù)。請求失敗被稱為緩存丟失，可能是緩存池滿沒有空間存儲最近的請求或緩存池不滿但請求率很低或最近剛剛重新啟動過。緩存丟失傳遞給網(wǎng)絡服務器，后者應答請求并填充緩存，要么更新最近最少使用的記錄或填補一個未占的可用空間。

我們強調(diào)了三點。首先，在網(wǎng)絡服務器前面實施頁面緩存或反向代理，這樣做可以得到顯著的擴展效益。生成動態(tài)內(nèi)容的網(wǎng)絡服務器的工作量大為減少，因為計算結果會在適當時間內(nèi)緩存。服務靜態(tài)內(nèi)容的網(wǎng)絡服務器不需要查找內(nèi)容，因此減少服務器數(shù)量。然而，我們認為靜態(tài)頁面緩存所帶來的好處絕非動態(tài)內(nèi)容那么大。

其次，需要使用適當?shù)?HTTP 頭，以確保發(fā)揮內(nèi)容緩存和結果緩存的最大潛在（也是適合業(yè)務）作用。為此，請參考前面對 Cache-Control，Last-Modified 和 Expires 的簡要討論。RFC2616 第 14 節(jié)對這些頭文件、相關參數(shù)及其預期結果有完整的描述。

第三點是盡可能包括 RFC2616 中另外的 HTTP 頭，這有助于最大限度地提高內(nèi)容緩存。這個新的頭被稱為 ETag。定義 ETag 或實體標記的目的是方便 If-None-Match 方法，用戶對服務器有條件的 GET 請求。ETags 是服務器在瀏覽器首次請求時，為對象發(fā)出的唯一標識。如果服務器的資源發(fā)生變化，就會分配新的 ETag 給。假設瀏覽器（客戶端）提供適當?shù)闹С?#xff0c;對象及其 ETag 由瀏覽器緩存，后續(xù)瀏覽器向網(wǎng)絡服務器發(fā)出的 If-None-Match 請求將包含此標簽。如果標簽相符，服務器會返回 HTTP304，內(nèi)容未修改的響應。如果標簽與服務器上的不一致，服務器將會發(fā)出更新后的對象及其相應的 ETag.

5 利用應用緩存

緩存要想長期有效，必須從系統(tǒng)架構視角出發(fā)來制定方案。對平臺架構我們可以從功能上按照服務或資源拆分（Y 軸拆分），或者按照請求者或客戶的某些屬性拆分（Z 軸拆分），會在服務請求的數(shù)據(jù)緩存能力上受益匪淺。問題是實施哪種拆分可以獲得最大利益。隨著新功能或新特性的開發(fā)而產(chǎn)生新的數(shù)據(jù)要求，所以這個問題的答案可能隨著時間的推移而改變。實施的方法，也需要隨著時間的推移而改變，以適應業(yè)務需求的不斷變化。需要不斷地分析生產(chǎn)流量、每筆交易的成本、用戶感知的響應時間，以識別在生產(chǎn)環(huán)境中出現(xiàn)瓶頸的早期跡象，并將數(shù)據(jù)交給負責架構的團隊。

要回答的關鍵問題是，從可擴展性和成本的角度來看，什么類型的拆分（或進一步的細分）可以獲得最大的利益。通過適當?shù)牟鸱趾陀纱私o應用服務器所帶來的數(shù)據(jù)緩存能力，完全有可能以較少的生產(chǎn)服務器來處理現(xiàn)有生產(chǎn)系統(tǒng)兩倍、三倍、甚至 10 倍的流量。以電商網(wǎng)站為例，電商網(wǎng)站有很多功能，包括搜索、瀏覽、圖片檢查（包括縮放）、帳戶更新、登錄、購物車、結帳、建議等。現(xiàn)有生產(chǎn)流量分析表明 80% 的交易都集中在使用搜索、瀏覽和推薦產(chǎn)品等幾個功能，并聚焦在不到 20% 的庫存上。我們可以利用 80 - 20 規(guī)則，對這些服務實施功能拆分，利用與整個用戶群相比，相對較少對象上的高命中率。可緩存性會很高，動態(tài)系統(tǒng)可以從類似的早期請求交付結果中受益。

可能我們也會發(fā)現(xiàn)有些頻繁發(fā)出請求的高級用戶。對這些特定的用戶功能，我們可能會決定針對用戶特定的功能，如登錄、購物車、帳戶更新（或其他帳戶信息）等實施按用戶屬性的拆分。另外一個例子，假設我們經(jīng)營 SaaS 業(yè)務，通過托管電話服務、電子郵件服務、聊天服務和關系管理系統(tǒng)，來支撐公司客戶支持。在系統(tǒng)中，有大量與特定業(yè)務相關的規(guī)則。以每個業(yè)務為基礎考慮，可能需要大量的內(nèi)存來緩存這些規(guī)則和一些業(yè)務操作所需的數(shù)據(jù)。如果你馬上得出結論，以客戶為導向拆分是人間正道，那么恭喜你答對了。

最后一個例子涉及到社交網(wǎng)絡或互動網(wǎng)站。你可能猜到我們會再次應用 80 - 20 原則并依靠生產(chǎn)環(huán)境的信息，來幫助我們作出決定。社交網(wǎng)絡往往涉及到少量擁有令人難以置信的大份額流量。這些用戶有時是活躍的消費者，有時是活躍的生產(chǎn)者（其他人的目的地），有時兩者兼而有之。首先確定是否有一小部分信息或者子站點有超過正常比例的“讀”流量。在社交網(wǎng)絡中這樣的節(jié)點對我們的架構考慮有指導意義，可以引導我們對這些生產(chǎn)者實施 Z 軸拆分，這樣從讀的角度他們節(jié)點的活動是高度可緩存的。假設 80 - 20 原則正確，現(xiàn)在由少數(shù)服務器服務將近 80% 的讀流量。

在社交網(wǎng)絡中，內(nèi)容或更新非常活躍的生產(chǎn)者會怎么樣？答案可能會有所不同，取決于內(nèi)容是否有很高的消費率（讀）還是大多數(shù)處于休眠狀態(tài)。當用戶既有高生產(chǎn)率（寫入/更新）又有高消費（讀）率的時候，我們可以直接把內(nèi)容發(fā)布到正在讀取的泳道或節(jié)點。如果讀寫沖突導致“節(jié)點”變熱開始成為一個問題，那么我們可以采用讀復制和水平擴展技術來解決。

6 利用對象緩存

對象緩存是用來存儲每個對象的哈希摘要的數(shù)據(jù)存儲（通常在內(nèi)存）。這些緩存主要用于存儲那些可能需要很大計算資源才能重新獲得的數(shù)據(jù)，例如數(shù)據(jù)庫復雜查詢的結果集。哈希函數(shù)將一個可變長度的大數(shù)轉換成一個小散列值。這個散列值（也稱為散列和/或校驗和）通常是一個可以用作數(shù)組中索引的整數(shù)。

# echo 'AKF Partners' | md5sum 90c9e7fd09d67219b15e730402d092eb[em][em]- # echo 'Hyper Growth Scalability AKF Partners' | md5sum faa216d21d711b81dfcddf3631cbe1ef[em][em]-

對象緩存有許多不同種，如流行的 Redis，Memcached、Apache 的 OJB 和 NCache，數(shù)不勝數(shù)。實施方式之多勝過工具選擇的多樣性。對象緩存通常部署在數(shù)據(jù)庫和應用之間，用來緩存 SQL 查詢結果集。然而，有些人把對象緩存用于復雜應用計算的結果，如用戶推薦、產(chǎn)品優(yōu)先級或基于最近表現(xiàn)的廣告重排序。最常見的實施是把對象緩存放在數(shù)據(jù)庫層前面，因為通常數(shù)據(jù)庫擴展起來最困難和最昂貴，而實施對象緩存是人間正道。

除了留意數(shù)據(jù)庫的 CPU 和內(nèi)存使用率外，SQL 查詢排行榜是表明系統(tǒng)需要目標緩存的最具代表性指標。SQL 查詢排行榜是根據(jù)那些在數(shù)據(jù)庫上運行得最頻繁和資源最密集查詢所生成報表的通稱。Oracle 的 Enterprise Manager Grid Control 有個內(nèi)置的 SQL 查詢評估工具，用來識別那些 SQL 資源最密集的語句。除了可以確定執(zhí)行很慢的查詢和排定改善它們的工作優(yōu)先級外，這個數(shù)據(jù)還可以用來顯示哪個查詢可以通過添加緩存從數(shù)據(jù)庫中消除。所有常見的數(shù)據(jù)庫都有類似的報告或工具，通過內(nèi)置或附加的工具提供服務。

一旦決定了要實施對象緩存，就需要選擇最適合的方案。提醒那些可能會考慮自建解決方案的技術團隊。有太多生產(chǎn)級別的對象緩存方案可供選擇。例如，Facebook 采用 800 多臺服務器為其系統(tǒng)提供超過 28TB 的內(nèi)存。雖然可能你作出決定自建而不是購買或使用開源的對象緩存，但是這個決定需要詳細斟酌。

下一步是實施對象緩存，通常這是直截了當?shù)摹emcached 支持許多不同編程語言的客戶端，如 Java、Python 和 PHP。PHP 有 get 和 set 兩個基本命令。從下面的例子可以看到我們連接到Memcached 服務器。如果連接失敗，就通過dbquery 函數(shù)查詢數(shù)據(jù)庫，這部分沒有顯示在例子中。如果 Memcached 連接成功，就嘗試檢索與特定的$key相關聯(lián)的$data。如果 get 失敗，我們查詢 db 并把$data存入 Memcached，這樣在下次查詢時，可以期待在緩存中能夠找到它。set 命令中的 false 標識用于壓縮，90 是以秒計算的緩存有效期。

$memcache = new Memcache; If ($memcache->connect('127.0.0.1', 11211)) { [em][em]If ($data = $memcache->get('$key')) { [em]} else { [em][em][em][em]$data = dbquery($key); [em][em][em][em]$memcache->set('$key',$data, false, 90); [em][em]} } else { [em][em]$data = dbquery($key); }

實施對象緩存的最后一步是監(jiān)控緩存命中率。這是能在緩存系統(tǒng)找到請求對象的次數(shù)與請求總次數(shù)的比率。理想情況下，該比率應該是 85% 或更高，意味著請求對象不在緩存或者緩存對象過期的機會僅有 15% 或更少。如果緩存命中率下降，需要考慮添加更多對象緩存服務器。

7 獨立對象緩存

許多公司從網(wǎng)絡或應用服務器開始實施對象緩存。這樣的實施簡單有效，不必投入額外硬件或云平臺虛擬機就可以實現(xiàn)對象緩存。缺點是對象緩存占用服務器大量內(nèi)存，結果造成對象緩存無法在應用或網(wǎng)絡層外獨立擴展。

更好的選擇是把對象緩存配置在自己層的服務器上。如果使用對象緩存來存儲查詢結果集，那么將部署在應用服務器和數(shù)據(jù)庫之間。如果緩存對象創(chuàng)建在應用層，那么對象緩存層就部署在網(wǎng)絡和應用服務器之間。見下面 的架構圖。這是邏輯架構，其中的對象緩存層可能是物理服務器，用來緩存數(shù)據(jù)庫對象和應用對象。

對這些層進行分離的優(yōu)點是可以根據(jù)對內(nèi)存和 CPU 的要求適當?shù)剡x擇服務器。此外，可以在其他服務器池以外獨立地擴展對象緩存池中的服務器。正確地評估服務器可以極大地節(jié)省成本，因為對象緩存通常需要大量內(nèi)存，在內(nèi)存中存儲對象和鍵，但需要相對較低的計算能力。不必拆分應用或網(wǎng)絡服務器，在必要時添加服務器，讓對象緩存使用額外的容量。

---

轉載聲明：本文轉自「泡面辦公室」，架構真經(jīng) | 緩存為王。

總結

以上是生活随笔為你收集整理的架构真经 | 缓存为王的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。