最后更新時間 2009-04-10    更新人 dormando@rydia.net
這里收集了經常被問到的關于memcached的問題

• 集群架構方面的問題
  • memcached是怎么工作的？
  • memcached最大的優勢是什么？
  • memcached和MySQL的query cache相比，有什么優缺點？
  • memcached和服務器的local cache（比如PHP的APC、mmap文件等）相比，有什么優缺點？
  • memcached的cache機制是怎樣的？
  • memcached如何實現冗余機制？        
  • memcached如何處理容錯的？ 
  • 如何將memcached中item批量導入導出？
  • 但是我確實需要把memcached中的item都dump出來，確實需要把數據load到memcached中，怎么辦？
  • memcached是如何做身份驗證的？
  • 如何使用memcached的多線程是什么？如何使用它們？
  • memcached能接受的key的最大長度是多少？（250bytes）
  • memcached對item的過期時間有什么限制？（為什么有30天的限制？）
  • memcached最大能存儲多大的單個item？（1M byte）
  • 為什么單個item的大小被限制在1M byte之內？
  • 為了讓memcached更有效地使用服務器的內存，可以在各個服務器上配置大小不等的緩存空間嗎？
  • 什么是binary協議？它值得關注嗎？
  • memcached是如何分配內存的？為什么不用malloc/free！？究竟為什么使用slab呢？
  • memcached能保證數據存儲的原子性嗎？

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">集群架構方面的問題

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached是怎么工作的？

Memcached的神奇來自兩階段哈希（two-stage hash）。Memcached就像一個巨大的、存儲了很多<key,value>對的哈希表。通過key，可以存儲或查詢任意的數據。

客戶端可以把數據存儲在多臺memcached上。當查詢數據時，客戶端首先參考節點列表計算出key的哈希值（階段一哈希），進而選中一個節點； 客戶端將請求發送給選中的節點，然后memcached節點通過一個內部的哈希算法（階段二哈希），查找真正的數據（item）。

舉個列子，假設有3個客戶端1, 2, 3，3臺memcached A, B, C：
Client 1想把數據"barbaz"以key "foo"存儲。Client 1首先參考節點列表（A, B, C），計算key "foo"的哈希值，假設memcached B被選中。接著，Client 1直接connect到memcached B，通過key "foo"把數據"barbaz"存儲進去。Client 2使用與Client 1相同的客戶端庫（意味著階段一的哈希算法相同），也擁有同樣的memcached列表（A, B, C）。
于是，經過相同的哈希計算（階段一），Client 2計算出key "foo"在memcached B上，然后它直接請求memcached B，得到數據"barbaz"。
各種客戶端在memcached中數據的存儲形式是不同的（perl Storable, php serialize, java hibernate, JSON等）。一些客戶端實現的哈希算法也不一樣。但是，memcached服務器端的行為總是一致的。

最后，從實現的角度看，memcached是一個非阻塞的、基于事件的服務器程序。這種架構可以很好地解決C10K problem ，并具有極佳的可擴展性。

可以參考A Story of Caching ，這篇文章簡單解釋了客戶端與memcached是如何交互的。

memcached最大的優勢是什么？

請仔細閱讀上面的問題（即memcached是如何工作的）。Memcached最大的好處就是它帶來了極佳的水平可擴展性，特別是在一個巨大的系 統中。由于客戶端自己做了一次哈希，那么我們很容易增加大量memcached到集群中。memcached之間沒有相互通信，因此不會增加 memcached的負載；沒有多播協議，不會網絡通信量爆炸（implode）。memcached的集群很好用。內存不夠了？增加幾臺 memcached吧；CPU不夠用了？再增加幾臺吧；有多余的內存？在增加幾臺吧，不要浪費了。

基于memcached的基本原則，可以相當輕松地構建出不同類型的緩存架構。除了這篇FAQ，在其他地方很容易找到詳細資料的。

看看下面的幾個問題吧，它們在memcached、服務器的local cache和MySQL的query cache之間做了比較。這幾個問題會讓您有更全面的認識。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached和MySQL的query cache相比，有什么優缺點？

把memcached引入應用中，還是需要不少工作量的。MySQL有個使用方便的query cache，可以自動地緩存SQL查詢的結果，被緩存的SQL查詢可以被反復地快速執行。Memcached與之相比，怎么樣呢？MySQL的query cache是集中式的，連接到該query cache的MySQL服務器都會受益。

• 當您修改表時，MySQL的query cache會立刻被刷新（flush）。存儲一個memcached item只需要很少的時間，但是當寫操作很頻繁時，MySQL的query cache會經常讓所有緩存數據都失效。

• 在多核CPU上，MySQL的query cache會遇到擴展問題（scalability issues）。在多核CPU上，query cache會增加一個全局鎖（global lock）, 由于需要刷新更多的緩存數據，速度會變得更慢。

• 在MySQL的query cache中，我們是不能存儲任意的數據的（只能是SQL查詢結果）。而利用memcached，我們可以搭建出各種高效的緩存。比如，可以執行多個獨立 的查詢，構建出一個用戶對象（user object），然后將用戶對象緩存到memcached中。而query cache是SQL語句級別的，不可能做到這一點。在小的網站中，query cache會有所幫助，但隨著網站規模的增加，query cache的弊將大于利。

• query cache能夠利用的內存容量受到MySQL服務器空閑內存空間的限制。給數據庫服務器增加更多的內存來緩存數據，固然是很好的。但是，有了memcached，只要您有空閑的內存，都可以用來增加memcached集群的規模，然后您就可以緩存更多的數據。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached和服務器的local cache（比如PHP的APC、mmap文件等）相比，有什么優缺點？

首先，local cache有許多與上面(query cache)相同的問題。local cache能夠利用的內存容量受到（單臺）服務器空閑內存空間的限制。不過，local cache有一點比memcached和query cache都要好，那就是它不但可以存儲任意的數據，而且沒有網絡存取的延遲。

• local cache的數據查詢更快。考慮把highly common的數據放在local cache中吧。如果每個頁面都需要加載一些數量較少的數據，考慮把它們放在local cached吧。

• local cache缺少集體失效（group invalidation）的特性。在memcached集群中，刪除或更新一個key會讓所有的觀察者覺察到。但是在local cache中, 我們只能通知所有的服務器刷新cache（很慢，不具擴展性），或者僅僅依賴緩存超時失效機制。

• local cache面臨著嚴重的內存限制，這一點上面已經提到。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached的cache機制是怎樣的？

Memcached主要的cache機制是LRU（最近最少用）算法+超時失效。當您存數據到memcached中，可以指定該數據在緩存中可以呆 多久Which is forever, or some time in the future。如果memcached的內存不夠用了，過期的slabs會優先被替換，接著就輪到最老的未被使用的slabs。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached如何實現冗余機制？
不 實現！我們對這個問題感到很驚訝。Memcached應該是應用的緩存層。它的設計本身就不帶有任何冗余機制。如果一個memcached節點失去了所有 數據，您應該可以從數據源（比如數據庫）再次獲取到數據。您應該特別注意，您的應用應該可以容忍節點的失效。不要寫一些糟糕的查詢代碼，寄希望于 memcached來保證一切！如果您擔心節點失效會大大加重數據庫的負擔，那么您可以采取一些辦法。比如您可以增加更多的節點（來減少丟失一個節點的影 響），熱備節點（在其他節點down了的時候接管IP），等等。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached如何處理容錯的？
不處理！:) 在memcached節點失效的情況下，集群沒有必要做任何容錯處理。如果發生了節點失效，應對的措施完全取決于用戶。節點失效時，下面列出幾種方案供您選擇：

• 忽略它！ 在失效節點被恢復或替換之前，還有很多其他節點可以應對節點失效帶來的影響。

• 把失效的節點從節點列表中移除。做這個操作千萬要小心！在默認情況下（余數式哈希算法），客戶端添加或移除節點，會導致所有的緩存數據不可用！因為哈希參照的節點列表變化了，大部分key會因為哈希值的改變而被映射到（與原來）不同的節點上。

• 啟動熱備節點，接管失效節點所占用的IP。這樣可以防止哈希紊亂（hashing chaos）。

• 如果希望添加和移除節點，而不影響原先的哈希結果，可以使用一致性哈希算法（consistent hashing）。您可以百度一下一致性哈希算法。支持一致性哈希的客戶端已經很成熟，而且被廣泛使用。去嘗試一下吧！

• 兩次哈希（reshing）。當客戶端存取數據時，如果發現一個節點down了，就再做一次哈希（哈希算法與前一次不同），重新選擇另一個節點 （需要注意的時，客戶端并沒有把down的節點從節點列表中移除，下次還是有可能先哈希到它）。如果某個節點時好時壞，兩次哈希的方法就有風險了，好的節 點和壞的節點上都可能存在臟數據（stale data）。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">如何將memcached中item批量導入導出？

您不應該這樣做！Memcached是一個非阻塞的服務器。任何可能導致memcached暫停或瞬時拒絕服務的操作都應該值得深思熟慮。向 memcached中批量導入數據往往不是您真正想要的！想象看，如果緩存數據在導出導入之間發生了變化，您就需要處理臟數據了；如果緩存數據在導出導入 之間過期了，您又怎么處理這些數據呢？

因此，批量導出導入數據并不像您想象中的那么有用。不過在一個場景倒是很有用。如果您有大量的從不變化 的數據，并且希望緩存很快熱（warm）起來，批量導入緩存數據是很有幫助的。雖然這個場景并不典型，但卻經常發生，因此我們會考慮在將來實現批量導出導入的功能。

Steven Grimm，一如既往地,，在郵件列表中給出了另一個很好的例子：http://lists.danga.com/pipermail/memcached/2007-July/004802.html 。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">但是我確實需要把memcached中的item批量導出導入，怎么辦？？

好吧好吧。如果您需要批量導出導入，最可能的原因一般是重新生成緩存數據需要消耗很長的時間，或者數據庫壞了讓您飽受痛苦。

如果一個memcached節點down了讓您很痛苦，那么您還會陷入其他很多麻煩。您的系統太脆弱了。您需要做一些優化工作。比如處理"驚群"問 題（比如 memcached節點都失效了，反復的查詢讓您的數據庫不堪重負...這個問題在FAQ的其他提到過），或者優化不好的查詢。記住，Memcached 并不是您逃避優化查詢的借口。

如果您的麻煩僅僅是重新生成緩存數據需要消耗很長時間（15秒到超過5分鐘），您可以考慮重新使用數據庫。這里給出一些提示：

• 使用MogileFS（或者CouchDB等類似的軟件）在存儲item。把item計算出來并dump到磁盤上。MogileFS可以很方便地 覆寫item，并提供快速地訪問。.您甚至可以把MogileFS中的item緩存在memcached中，這樣可以加快讀取速度。 MogileFS+Memcached的組合可以加快緩存不命中時的響應速度，提高網站的可用性。
• 重新使用MySQL。MySQL的 InnoDB主鍵查詢的速度非常快。如果大部分緩存數據都可以放到VARCHAR字段中，那么主鍵查詢的性能將更好。從memcached中按key查詢 幾乎等價于MySQL的主鍵查詢：將key 哈希到64-bit的整數，然后將數據存儲到MySQL中。您可以把原始（不做哈希）的key存儲都普通的字段中，然后建立二級索引來加快查 詢...key被動地失效，批量刪除失效的key，等等。

上面的方法都可以引入memcached，在重啟memcached的時候仍然提供很好的性能。由于您不需要當心"hot"的item被 memcached LRU算法突然淘汰，用戶再也不用花幾分鐘來等待重新生成緩存數據（當緩存數據突然從內存中消失時），因此上面的方法可以全面提高性能。

關于這些方法的細節，詳見博客：http://dormando.livejournal.com/495593.html 。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached是如何做身份驗證的？
沒有身份認證機制！memcached是運行在應用下層的軟件（身份驗證應該是應用上層的職責）。memcached的客戶端和服務器端之所以是輕量級的，部分原因就是完全沒有實現身份驗證機制。這樣，memcached可以很快地創建新連接，服務器端也無需任何配置。

如果您希望限制訪問，您可以使用防火墻，或者讓memcached監聽unix domain socket。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached的多線程是什么？如何使用它們？
線 程就是定律（threads rule）！在Steven Grimm和Facebook的努力下，memcached 1.2及更高版本擁有了多線程模式。多線程模式允許memcached能夠充分利用多個CPU，并在CPU之間共享所有的緩存數據。memcached使 用一種簡單的鎖機制來保證數據更新操作的互斥。相比在同一個物理機器上運行多個memcached實例，這種方式能夠更有效地處理multi gets。

如果您的系統負載并不重，也許您不需要啟用多線程工作模式。如果您在運行一個擁有大規模硬件的、龐大的網站，您將會看到多線程的好處。

更多信息請參見：http://code.sixapart.com/svn/memcached/trunk/server/doc/threads.txt 。

簡 單地總結一下：命令解析（memcached在這里花了大部分時間）可以運行在多線程模式下。memcached內部對數據的操作是基于很多全局鎖的（因 此這部分工作不是多線程的）。未來對多線程模式的改進，將移除大量的全局鎖，提高memcached在負載極高的場景下的性能。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached能接受的key的最大長度是多少？
key 的最大長度是250個字符。需要注意的是，250是memcached服務器端內部的限制，如果您使用的客戶端支持"key的前綴"或類似特性，那么 key（前綴+原始key）的最大長度是可以超過250個字符的。我們推薦使用使用較短的key，因為可以節省內存和帶寬。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached對item的過期時間有什么限制？
過期時間最大可以達到30天。memcached把傳入的過期時間（時間段）解釋成時間點后，一旦到了這個時間點，memcached就把item置為失效狀態。這是一個簡單但obscure的機制。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached最大能存儲多大的單個item？
1MB。如果你的數據大于1MB，可以考慮在客戶端壓縮或拆分到多個key中。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">為什么單個item的大小被限制在1M byte之內？
啊...這是一個大家經常問的問題！

簡單的回答：因為內存分配器的算法就是這樣的。

詳 細的回答：Memcached的內存存儲引擎（引擎將來可插拔...）,使用slabs來管理內存。內存被分成大小不等的slabs chunks（先分成大小相等的slabs，然后每個slab被分成大小相等chunks，不同slab的chunk大小是不相等的）。chunk的大小 依次從一個最小數開始，按某個因子增長，直到達到最大的可能值。

如果最小值為400B，最大值是1MB，因子是1.20，各個slab的chunk的大小依次是：slab1 - 400B slab2 - 480B slab3 - 576B ...

slab中chunk越大，它和前面的slab之間的間隙就越大。因此，最大值越大，內存利用率越低。Memcached必須為每個slab預先分配內存，因此如果設置了較小的因子和較大的最大值，會需要更多的內存。

還有其他原因使得您不要這樣向memcached中存取很大的數據...不要嘗試把巨大的網頁放到mencached中。把這樣大的數據結構load和unpack到內存中需要花費很長的時間，從而導致您的網站性能反而不好。

如果您確實需要存儲大于1MB的數據，你可以修改slabs.c:POWER_BLOCK的值，然后重新編譯memcached；或者使用低效的malloc/free。其他的建議包括數據庫、MogileFS等。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">我可以在不同的memcached節點上使用大小不等的緩存空間嗎？這么做之后，memcached能夠更有效地使用內存嗎？
Memcache 客戶端僅根據哈希算法來決定將某個key存儲在哪個節點上，而不考慮節點的內存大小。因此，您可以在不同的節點上使用大小不等的緩存。但是一般都是這樣做 的：擁有較多內存的節點上可以運行多個memcached實例，每個實例使用的內存跟其他節點上的實例相同。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">什么是二進制協議，我該關注嗎？
關于二進制最好的信息當然是二進制協議規范：http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol 。

二進制協議嘗試為端提供一個更有效的、可靠的協議，減少客戶端/服務器端因處理協議而產生的CPU時間。
根據Facebook的測試，解析ASCII協議是memcached中消耗CPU時間最多的環節。所以，我們為什么不改進ASCII協議呢？

在這個郵件列表的thread中可以找到一些舊的信息：http://lists.danga.com/pipermail/memcached/2007-July/004636.html 。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached的內存分配器是如何工作的？為什么不適用malloc/free！？為何要使用slabs？
實 際上，這是一個編譯時選項。默認會使用內部的slab分配器。您確實確實應該使用內建的slab分配器。最早的時候，memcached只使用 malloc/free來管理內存。然而，這種方式不能與OS的內存管理以前很好地工作。反復地malloc/free造成了內存碎片，OS最終花費大量 的時間去查找連續的內存塊來滿足malloc的請求，而不是運行memcached進程。如果您不同意，當然可以使用malloc！只是不要在郵件列表中 抱怨啊:)

slab分配器就是為了解決這個問題而生的。內存被分配并劃分成chunks，一直被重復使用。因為內存被劃分成大小不等的 slabs，如果item的大小與被選擇存放它的slab不是很合適的話，就會浪費一些內存。Steven Grimm正在這方面已經做出了有效的改進。

郵件列表中有一些關于slab的改進（power of n 還是 power of 2）和權衡方案：http://lists.danga.com/pipermail/memcached/2006-May/002163.html http://lists.danga.com/pipermail/memcached/2007-March/003753.html 。

如果您想使用malloc/free，看看它們工作地怎么樣，您可以在構建過程中定義USE_SYSTEM_MALLOC。這個特性沒有經過很好的測試，所以太不可能得到開發者的支持。

更多信息：http://code.sixapart.com/svn/memcached/trunk/server/doc/memory_management.txt 。

" src="/CuteSoft_Client/CuteEditor/Images/anchor.gif">memcached是原子的嗎？
當然！好吧，讓我們來明確一下：
所有的被發送到memcached的單個命令是完全原子的。如果您針對同一份數據同時發送了一個set命令和一個get命令，它們不會影響對方。它們將被串行化、先后執行。即使在多線程模式，所有的命令都是原子的，除非程序有bug:)
命令序列不是原子的。如果您通過get命令獲取了一個item，修改了它，然后想把它set回memcached，我們不保證這個item沒有被其他進程（process，未必是操作系統中的進程）操作過。在并發的情況下，您也可能覆寫了一個被其他進程set的item。

memcached 1.2.5以及更高版本，提供了gets和cas命令，它們可以解決上面的問題。如果您使用gets命令查詢某個key的item，memcached會 給您返回該item當前值的唯一標識。如果您覆寫了這個item并想把它寫回到memcached中，您可以通過cas命令把那個唯一標識一起發送給 memcached。如果該item存放在memcached中的唯一標識與您提供的一致，您的寫操作將會成功。如果另一個進程在這期間也修改了這個 item，那么該item存放在memcached中的唯一標識將會改變，您的寫操作就會失敗。

通常，基于memcached中item的值來修改item，是一件棘手的事情。除非您很清楚自己在做什么，否則請不要做這樣的事情。

　　“無法解決  equal  to  操作的排序規則沖突。”

　　一.錯誤分析：

　　這個錯誤是因為排序規則不一致造成的，我們做個測試，比如：
create  table  #t1(
name  varchar(20)  collate  Albanian_CI_AI_WS,    
value  int)

create  table  #t2(
name  varchar(20)  collate  Chinese_PRC_CI_AI_WS,        
value  int  )

表建好后，執行連接查詢：

select  *  from  #t1  A  inner  join  #t2  B  on  A.name=B.name  

這樣，錯誤就出現了：

　　 服務器:  消息  446，級別  16，狀態  9，行  1
　　 無法解決  equal  to  操作的排序規則沖突。
　　要排除這個錯誤，最簡單方法是，表連接時指定它的排序規則，這樣錯誤就不再出現了。語句這樣寫：

select  *  
from  #t1  A  inner  join  #t2  B  
on  A.name=B.name  collate  Chinese_PRC_CI_AI_WS

　　二.排序規則簡介：

　　什么叫排序規則呢？MS是這樣描述的："在  Microsoft  SQL  Server  2000  中，字符串的物理存儲由排序規則控制。排序規則指定表示每個字符的位模式以及存儲和比較字符所使用的規則。

　　在查詢分析器內執行下面語句，可以得到SQL　SERVER支持的所有排序規則。

　　　　select  *  from  ::fn_helpcollations()  

　　排序規則名稱由兩部份構成，前半部份是指本排序規則所支持的字符集。
　　如：
　　Chinese_PRC_CS_AI_WS  
　　前半部份：指UNICODE字符集，Chinese_PRC_指針對大陸簡體字UNICODE的排序規則。
　　排序規則的后半部份即后綴  含義：  
　　_BIN  二進制排序  
　　_CI(CS)  是否區分大小寫，CI不區分，CS區分
　　_AI(AS)  是否區分重音，AI不區分，AS區分　　　
　　_KI(KS)  是否區分假名類型,KI不區分，KS區分　
       _WI(WS)  是否區分寬度  WI不區分，WS區分　

　　區分大小寫:如果想讓比較將大寫字母和小寫字母視為不等，請選擇該選項。

　　區分重音:如果想讓比較將重音和非重音字母視為不等，請選擇該選項。如果選擇該選項，比較還將重音不同的字母視為不等。

　　區分假名:如果想讓比較將片假名和平假名日語音節視為不等，請選擇該選項。

　　區分寬度:如果想讓比較將半角字符和全角字符視為不等，請選擇該選項

　　三.排序規則的應用：

　　SQL  SERVER提供了大量的WINDOWS和SQLSERVER專用的排序規則，但它的應用往往被開發人員所忽略。其實它在實踐中大有用處。

　　例1:讓表NAME列的內容按拼音排序：

create  table  #t(id  int,name  varchar(20))
insert  #t  select  1,'中'
union  all  select  2,'國'
union  all  select  3,'人'
union  all  select  4,'阿'

select  *  from  #t  order  by  name  collate  Chinese_PRC_CS_AS_KS_WS  
drop  table  #t
/*結果：
id                    name                                  
-----------  --------------------  
4                      阿
2                      國
3                      人
1                      中
*/

　　例2：讓表NAME列的內容按姓氏筆劃排序：

create  table  #t(id  int,name  varchar(20))

insert  #t  select  1,'三'
union  all  select  2,'乙'
union  all  select  3,'二'
union  all  select  4,'一'
union  all  select  5,'十'
select  *  from  #t  order  by  name  collate  Chinese_PRC_Stroke_CS_AS_KS_WS    
drop  table  #t
/*結果：
id                    name                                  
-----------  --------------------  
4                      一
2                      乙
3                      二
5                      十
1                      三
*/

　　四.在實踐中排序規則應用的擴展

　　SQL  SERVER漢字排序規則可以按拼音、筆劃等排序，那么我們如何利用這種功能來處理漢字的一些難題呢？我現在舉個例子：

　　用排序規則的特性計算漢字筆劃

　　要計算漢字筆劃，我們得先做準備工作，我們知道，WINDOWS多國漢字，UNICODE目前
收錄漢字共20902個。簡體GBK碼漢字UNICODE值從19968開始。

　　首先，我們先用SQLSERVER方法得到所有漢字，不用字典，我們簡單利用SQL語句就可以得到：

select  top  20902  code=identity(int,19968,1)  into  #t  from  syscolumns  a,syscolumns  b

再用以下語句，我們就得到所有漢字，它是按UNICODE值排序的：

　　select  code,nchar(code)  as  CNWord  from  #t  

　　然后，我們用SELECT語句，讓它按筆劃排序。

select  code,nchar(code)  as  CNWord  
from  #t  
order  by  nchar(code)  collate  Chinese_PRC_Stroke_CS_AS_KS_WS,code

結果：
code                CNWord  
-----------  ------  
19968              一
20008              丨
20022              丶
20031              丿
20032              乀
20033              乁
20057              乙
20058              乚
20059              乛
20101              亅
19969              丁
..........

　 　從上面的結果，我們可以清楚的看到，一筆的漢字，code是從19968到20101，從小到大排，但到了二筆漢字的第一個字“丁”，CODE為 19969，就不按順序而重新開始了。有了這結果，我們就可以輕松的用SQL語句得到每種筆劃漢字歸類的第一個或最后一個漢字。
下面用語句得到最后一個漢字：

create  table  #t1(id  int  identity,code  int,cnword  nvarchar(2))

insert  #t1(code,cnword)
select  code,nchar(code)  as  CNWord    from  #t  
order  by  nchar(code)  collate  Chinese_PRC_Stroke_CS_AS_KS_WS,code

select  A.cnword  
from  #t1  A  
left  join  #t1  B  on  A.id=B.id-1  and  A.code<B.code  
where  B.code  is  null
order  by  A.id

　　得到36個漢字，每個漢字都是每種筆劃數按Chinese_PRC_Stroke_CS_AS_KS_WS排序規則排序后的
最后一個漢字：

亅阝馬風龍齊龜齒鴆齔龕龂齠齦齪龍龠龎龐龑龡龢龝齹龣龥齈龞麷鸞麣龖龗齾齉龘

　　上面可以看出：“亅”是所有一筆漢字排序后的最后一個字，“阝”是所有二筆漢字排序后的最后一個字......等等。

　　但同時也發現，從第33個漢字“龗(33筆)”后面的筆劃有些亂，不正確。但沒關系，比“龗”筆劃多的只有四個漢字，我們手工加上：齾35筆，齉36筆，靐39筆，龘64筆

　　建漢字筆劃表（TAB_HZBH）：

create  table  tab_hzbh(id  int  identity,cnword  nchar(1))
--先插入前33個漢字
insert  tab_hzbh
select  top  33  A.cnword  
from  #t1  A  
left  join  #t1  B  on  A.id=B.id-1  and  A.code<B.code  
where  B.code  is  null
order  by  A.id
--再加最后四個漢字
set  identity_insert  tab_hzbh  on
go
insert  tab_hzbh(id,cnword)
　　　　　select  35,N'齾'
union  all  select  36,N'齉'
union  all  select  39,N'靐'
union  all  select  64,N'龘'
go
set  identity_insert  tab_hzbh  off
go

　　到此為止，我們可以得到結果了，比如我們想得到漢字“國”的筆劃：

declare  @a  nchar(1)
set  @a='國'
select  top  1  id  
from    tab_hzbh  
where  cnword>=@a  collate  Chinese_PRC_Stroke_CS_AS_KS_WS
order  by  id

id                    
-----------  
8
(結果：漢字“國”筆劃數為8)

　　上面所有準備過程，只是為了寫下面這個函數，這個函數撇開上面建的所有臨時表和固定表，為了通用和代碼轉移方便，把表tab_hzbh的內容寫在語句內，然后計算用戶輸入一串漢字的總筆劃：

create  function  fun_getbh(@str  nvarchar(4000))
returns  int
as
begin
declare  @word  nchar(1),@n  int
set  @n=0
while  len(@str)>0
begin
set  @word=left(@str,1)
--如果非漢字，筆劃當0計
set  @n=@n+(case  when  unicode(@word)  between  19968  and  19968+20901
then  (select  top  1  id  from  (
select  1  as  id,N'亅'  as  word  
union  all  select  2,N'阝'  
union  all  select  3,N'馬'  
union  all  select  4,N'風'  
union  all  select  5,N'龍'  
union  all  select  6,N'齊'  
union  all  select  7,N'龜'  
union  all  select  8,N'齒'  
union  all  select  9,N'鴆'  
union  all  select  10,N'齔'  
union  all  select  11,N'龕'  
union  all  select  12,N'龂'  
union  all  select  13,N'齠'  
union  all  select  14,N'齦'  
union  all  select  15,N'齪'  
union  all  select  16,N'龍'  
union  all  select  17,N'龠'  
union  all  select  18,N'龎'  
union  all  select  19,N'龐'  
union  all  select  20,N'龑'  
union  all  select  21,N'龡'  
union  all  select  22,N'龢'  
union  all  select  23,N'龝'  
union  all  select  24,N'齹'  
union  all  select  25,N'龣'  
union  all  select  26,N'龥'  
union  all  select  27,N'齈'  
union  all  select  28,N'龞'  
union  all  select  29,N'麷'  
union  all  select  30,N'鸞'  
union  all  select  31,N'麣'  
union  all  select  32,N'龖'  
union  all  select  33,N'龗'  
union  all  select  35,N'齾'  
union  all  select  36,N'齉'  
union  all  select  39,N'靐'  
union  all  select  64,N'龘'  
)  T  
where  word>=@word  collate  Chinese_PRC_Stroke_CS_AS_KS_WS
order  by  id  ASC)  else  0  end)
set  @str=right(@str,len(@str)-1)
end
return  @n
end

--函數調用實例：
select  dbo.fun_getbh('中華人民共和國'),dbo.fun_getbh('中華人民共和國')
　
　　執行結果：筆劃總數分別為39和46，簡繁體都行。

       當然，你也可以把上面“UNION　ALL”內的漢字和筆劃改存在固定表內，在漢字列建CLUSTERED  INDEX，列排序規則設定為：

　　Chinese_PRC_Stroke_CS_AS_KS_WS

　　這樣速度更快。如果你用的是BIG5碼的操作系統，你得另外生成漢字，方法一樣。但有一點要記住：這些漢字是通過SQL語句SELECT出來的，不是手工輸入的，更不是查字典得來的，因為新華字典畢竟不同于UNICODE字符集，查字典的結果會不正確。

　　
　　用排序規則的特性得到漢字拼音首字母

　　用得到筆劃總數相同的方法，我們也可以寫出求漢字拼音首字母的函數。如下：

create  function  fun_getPY(@str  nvarchar(4000))
returns  nvarchar(4000)
as
begin
declare  @word  nchar(1),@PY  nvarchar(4000)
set  @PY=''
while  len(@str)>0
begin
set  @word=left(@str,1)
--如果非漢字字符，返回原字符
set  @PY=@PY+(case  when  unicode(@word)  between  19968  and  19968+20901
then  (select  top  1  PY  from  (
select  'A'  as  PY,N'驁'  as  word
union  all  select  'B',N'簿'
union  all  select  'C',N'錯'
union  all  select  'D',N'鵽'
union  all  select  'E',N'樲'
union  all  select  'F',N'鰒'
union  all  select  'G',N'腂'
union  all  select  'H',N'夻'
union  all  select  'J',N'攈'
union  all  select  'K',N'穒'
union  all  select  'L',N'鱳'
union  all  select  'M',N'旀'
union  all  select  'N',N'桛'
union  all  select  'O',N'漚'
union  all  select  'P',N'曝'
union  all  select  'Q',N'囕'
union  all  select  'R',N'鶸'
union  all  select  'S',N'蜶'
union  all  select  'T',N'籜'
union  all  select  'W',N'鶩'
union  all  select  'X',N'鑂'
union  all  select  'Y',N'韻'
union  all  select  'Z',N'咗'
)  T  
where  word>=@word  collate  Chinese_PRC_CS_AS_KS_WS  
order  by  PY  ASC)  else  @word  end)
set  @str=right(@str,len(@str)-1)
end
return  @PY
end

--函數調用實例：
select  dbo.fun_getPY('中華人民共和國'),dbo.fun_getPY('中華人民共和國')
結果都為：ZHRMGHG

　　你若有興趣，也可用相同的方法，擴展為得到漢字全拼的函數，甚至還可以得到全拼的讀音聲調，不過全拼分類大多了。得到全拼最好是用對照表，兩萬多漢字搜索速度很快，用對照表還可以充分利用表的索引。

　　排序規則還有很多其它的巧妙用法。歡迎大家共同探討。

本文來自和你在一起的博客，原文標題為《JVM調優總結（一）-- 一些概念》。

數據類型

基本類型包括：byte, short, int, long, char, float, double, Boolean, returnAddress

引用類型包括：類類型，接口類型和數組。

堆與棧

堆和棧是程序運行的關鍵，很有必要把他們的關系說清楚。

棧是運行時的單位，而堆是存儲的單位。

棧解決程序的運行問題，即程序如何執行，或者說如何處理數據；堆解決的是數據存儲的問題，即數據怎么放、放在哪兒。

在Java中一個線程就會相應有一個線程棧與之對應，這點很容易理解，因為不同的線程執行邏輯有所不同，因此需要一個獨立的線程棧。而堆則是所有線 程共享的。棧因為是運行單位，因此里面存儲的信息都是跟當前線程（或程序）相關信息的。包括局部變量、程序運行狀態、方法返回值等等；而堆只負責存儲對象 信息。

為什么要把堆和棧區分出來呢？棧中不是也可以存儲數據嗎？

第一，從軟件設計的角度看，棧代表了處理邏輯，而堆代表了數據。這樣分開，使得處理邏輯更為清晰。分而治之的思想。這種隔離、模塊化的思想在軟件設計的方方面面都有體現。

第二，堆與棧的分離，使得堆中的內容可以被多個棧共享（也可以理解為多個線程訪問同一個對象）。這種共享的收益是很多的。一方面這種共享提供了一種有效的數據交互方式(如：共享內存)，另一方面，堆中的共享常量和緩存可以被所有棧訪問，節省了空間。

第三，棧因為運行時的需要，比如保存系統運行的上下文，需要進行地址段的劃分。由于棧只能向上增長，因此就會限制住棧存儲內容的能力。而堆不同，堆中的對象是可以根據需要動態增長的，因此棧和堆的拆分，使得動態增長成為可能，相應棧中只需記錄堆中的一個地址即可。

第四，面向對象就是堆和棧的完美結合。其實，面向對象方式的程序與以前結構化的程序在執行上沒有任何區別。但是，面向對象的引入，使得對待問題的思 考方式發生了改變，而更接近于自然方式的思考。當我們把對象拆開，你會發現，對象的屬性其實就是數據，存放在堆中；而對象的行為（方法），就是運行邏輯， 放在棧中。我們在編寫對象的時候，其實即編寫了數據結構，也編寫的處理數據的邏輯。不得不承認，面向對象的設計，確實很美。

在Java中，Main函數就是棧的起始點，也是程序的起始點。

程序要運行總是有一個起點的。同C語言一樣，java中的Main就是那個起點。無論什么java程序，找到main就找到了程序執行的入口：）

堆中存什么？棧中存什么？

堆中存的是對象。棧中存的是基本數據類型和堆中對象的引用。一個對象的大小是不可估計的，或者說是可以動態變化的，但是在棧中，一個對象只對應了一個4btye的引用（堆棧分離的好處：））。

為什么不把基本類型放堆中呢？因為其占用的空間一般是1~8個字節——需要空間比較少，而且因為是基本類型，所以不會出現動態增長的情況——長度固 定，因此棧中存儲就夠了，如果把他存在堆中是沒有什么意義的（還會浪費空間，后面說明）。可以這么說，基本類型和對象的引用都是存放在棧中，而且都是幾個 字節的一個數，因此在程序運行時，他們的處理方式是統一的。但是基本類型、對象引用和對象本身就有所區別了，因為一個是棧中的數據一個是堆中的數據。最常 見的一個問題就是，Java中參數傳遞時的問題。

Java中的參數傳遞時傳值呢？還是傳引用？

要說明這個問題，先要明確兩點：

1. 不要試圖與C進行類比，Java中沒有指針的概念

2. 程序運行永遠都是在棧中進行的，因而參數傳遞時，只存在傳遞基本類型和對象引用的問題。不會直接傳對象本身。

明確以上兩點后。Java在方法調用傳遞參數時，因為沒有指針，所以它都是進行傳值調用（這點可以參考C的傳值調用）。因此，很多書里面都說Java是進行傳值調用，這點沒有問題，而且也簡化的C中復雜性。

但是傳引用的錯覺是如何造成的呢？在運行棧中，基本類型和引用的處理是一樣的，都是傳值，所以，如果是傳引用的方法調用，也同時可以理解為“傳引用 值”的傳值調用，即引用的處理跟基本類型是完全一樣的。但是當進入被調用方法時，被傳遞的這個引用的值，被程序解釋（或者查找）到堆中的對象，這個時候才 對應到真正的對象。如果此時進行修改，修改的是引用對應的對象，而不是引用本身，即：修改的是堆中的數據。所以這個修改是可以保持的了。

對象，從某種意義上說，是由基本類型組成的。可以把一個對象看作為一棵樹，對象的屬性如果還是對象，則還是一顆樹（即非葉子節點），基本類型則為樹 的葉子節點。程序參數傳遞時，被傳遞的值本身都是不能進行修改的，但是，如果這個值是一個非葉子節點（即一個對象引用），則可以修改這個節點下面的所有內 容。

堆和棧中，棧是程序運行最根本的東西。程序運行可以沒有堆，但是不能沒有棧。而堆是為棧進行數據存儲服務，說白了堆就是一塊共享的內存。不過，正是因為堆和棧的分離的思想，才使得Java的垃圾回收成為可能。

Java中，棧的大小通過-Xss來設置，當棧中存儲數據比較多時，需要適當調大這個值，否則會出現java.lang.StackOverflowError異常。常見的出現這個異常的是無法返回的遞歸，因為此時棧中保存的信息都是方法返回的記錄點。

二 JAVA垃圾收集器

2.1 垃圾收集簡史

垃圾收集提供了內存管理的機制，使得應用程序不需要在關注內存如何釋放，內存用完后，垃圾收集會進行收集，這樣就減輕了因為人為的管理內存而造成的 錯誤，比如在C++語言里，出現內存泄露時很常見的。Java語言是目前使用最多的依賴于垃圾收集器的語言，但是垃圾收集器策略從20世紀60年代就已經 流行起來了，比如Smalltalk,Eiffel等編程語言也集成了垃圾收集器的機制。

2.2 常見的垃圾收集策略

所有的垃圾收集算法都面臨同一個問題，那就是找出應用程序不可到達的內存塊，將其釋放，這里面得不可到達主要是指應用程序已經沒有內存塊的引用了， 而在JAVA中，某個對象對應用程序是可到達的是指：這個對象被根（根主要是指類的靜態變量，或者活躍在所有線程棧的對象的引用）引用或者對象被另一個可 到達的對象引用。

2.2.1 Reference Counting(引用計數）
 
引用計數是最簡單直接的一種方式，這種方式在每一個對象中增加一個引用的計數，這個計數代表當前程序有多少個引用引用了此對象，如果此對象的引用計數變為0，那么此對象就可以作為垃圾收集器的目標對象來收集。

優點：

簡單，直接，不需要暫停整個應用

缺點：

1.需要編譯器的配合，編譯器要生成特殊的指令來進行引用計數的操作，比如每次將對象賦值給新的引用，或者者對象的引用超出了作用域等。

2.不能處理循環引用的問題

2.2.2 跟蹤收集器

跟蹤收集器首先要暫停整個應用程序，然后開始從根對象掃描整個堆，判斷掃描的對象是否有對象引用，這里面有三個問題需要搞清楚：

1．如果每次掃描整個堆，那么勢必讓GC的時間變長，從而影響了應用本身的執行。因此在JVM里面采用了分代收集，在新生代收集的時候minor gc只需要掃描新生代，而不需要掃描老生代。

2．JVM采用了分代收集以后，minor gc只掃描新生代，但是minor gc怎么判斷是否有老生代的對象引用了新生代的對象，JVM采用了卡片標記的策略，卡片標記將老生代分成了一塊一塊的，劃分以后的每一個塊就叫做一個卡 片，JVM采用卡表維護了每一個塊的狀態，當JAVA程序運行的時候，如果發現老生代對象引用或者釋放了新生代對象的引用，那么就JVM就將卡表的狀態設 置為臟狀態，這樣每次minor gc的時候就會只掃描被標記為臟狀態的卡片，而不需要掃描整個堆。具體如下圖：
3．GC在收集一個對象的時候會判斷是否有引用指向對象，在JAVA中的引用主要有四種：Strong reference,Soft reference,Weak reference,Phantom reference.

◆ Strong Reference

強引用是JAVA中默認采用的一種方式，我們平時創建的引用都屬于強引用。如果一個對象沒有強引用，那么對象就會被回收。

public void testStrongReference(){  
Object referent = new Object();  
Object strongReference = referent;  
referent = null;  
System.gc();  
assertNotNull(strongReference);  
} 

◆ Soft Reference

軟引用的對象在GC的時候不會被回收，只有當內存不夠用的時候才會真正的回收，因此軟引用適合緩存的場合，這樣使得緩存中的對象可以盡量的再內存中待長久一點。

Public void testSoftReference(){  
String  str =  "test";  
SoftReference<String> softreference = new SoftReference<String>(str);  
str=null;  
System.gc();  
assertNotNull(softreference.get());  
}  

◆ Weak reference

弱引用有利于對象更快的被回收，假如一個對象沒有強引用只有弱引用，那么在GC后，這個對象肯定會被回收。

Public void testWeakReference(){  
String  str =  "test";  
WeakReference<String> weakReference = new WeakReference<String>(str);  
str=null;  
System.gc();  
assertNull(weakReference.get());  
}  

◆ Phantom reference

2.2.2.1 Mark-Sweep Collector(標記-清除收集器）

標記清除收集器最早由Lisp的發明人于1960年提出，標記清除收集器停止所有的工作，從根掃描每個活躍的對象，然后標記掃描過的對象，標記完成以后，清除那些沒有被標記的對象。

優點：

1 解決循環引用的問題

2 不需要編譯器的配合，從而就不執行額外的指令

缺點：

1．每個活躍的對象都要進行掃描，收集暫停的時間比較長。

2.2.2.2 Copying Collector(復制收集器）復制收集器將內存分為兩塊一樣大小空間，某一個時刻，只有一個空間處于活躍的狀態，當活躍的空間滿的時候，GC就會將活 躍的對象復制到未使用的空間中去，原來不活躍的空間就變為了活躍的空間。復制收集器具體過程可以參考下圖：

優點：

1 只掃描可以到達的對象，不需要掃描所有的對象，從而減少了應用暫停的時間

缺點：

1．需要額外的空間消耗，某一個時刻，總是有一塊內存處于未使用狀態

2．復制對象需要一定的開銷

2.2.2.3 Mark-Compact Collector(標記-整理收集器）標記整理收集器汲取了標記清除和復制收集器的優點，它分兩個階段執行，在第一個階段，首先掃描所有活躍的對象，并 標記所有活躍的對象，第二個階段首先清除未標記的對象，然后將活躍的的對象復制到堆得底部。標記整理收集器的過程示意圖請參考下圖：Mark- compact策略極大的減少了內存碎片，并且不需要像Copy Collector一樣需要兩倍的空間。

JVM內存模型是Java的核心技術之一，之前51CTO曾為大家介紹過JVM分代垃圾回收策略的基礎概念，現在很多編程語言都引入了類似Java JVM的內存模型和垃圾收集器的機制，下面我們將主要針對Java中的JVM內存模型及垃圾收集的具體策略進行綜合的分析。

一 JVM內存模型

1.1 Java棧

Java棧是與每一個線程關聯的，JVM在創建每一個線程的時候，會分配一定的棧空間給線程。它主要用來存儲線程執行過程中的局部變量，方法的返回 值，以及方法調用上下文。棧空間隨著線程的終止而釋放。StackOverflowError：如果在線程執行的過程中，棧空間不夠用，那么JVM就會拋 出此異常，這種情況一般是死遞歸造成的。

1.2 堆

Java中堆是由所有的線程共享的一塊內存區域，堆用來保存各種JAVA對象，比如數組，線程對象等。

1.2.1 Generation

JVM堆一般又可以分為以下三部分：

◆ Perm

Perm代主要保存class,method,filed對象，這部門的空間一般不會溢出，除非一次性加載了很多的類，不過在涉及到熱部署的應用服 務器的時候，有時候會遇到java.lang.OutOfMemoryError : PermGen space 的錯誤，造成這個錯誤的很大原因就有可能是每次都重新部署，但是重新部署后，類的class沒有被卸載掉，這樣就造成了大量的class對象保存在了 perm中，這種情況下，一般重新啟動應用服務器可以解決問題。

◆ Tenured

Tenured區主要保存生命周期長的對象，一般是一些老的對象，當一些對象在Young復制轉移一定的次數以后，對象就會被轉移到Tenured區，一般如果系統中用了application級別的緩存，緩存中的對象往往會被轉移到這一區間。

◆ Young

Young區被劃分為三部分，Eden區和兩個大小嚴格相同的Survivor區，其中Survivor區間中，某一時刻只有其中一個是被使用的， 另外一個留做垃圾收集時復制對象用，在Young區間變滿的時候，minor GC就會將存活的對象移到空閑的Survivor區間中，根據JVM的策略，在經過幾次垃圾收集后，任然存活于Survivor的對象將被移動到 Tenured區間。

1.2.2 Sizing the Generations

JVM提供了相應的參數來對內存大小進行配置。正如上面描述，JVM中堆被分為了3個大的區間，同時JVM也提供了一些選項對Young,Tenured的大小進行控制。

◆ Total Heap

-Xms ：指定了JVM初始啟動以后初始化內存

-Xmx：指定JVM堆得最大內存，在JVM啟動以后，會分配-Xmx參數指定大小的內存給JVM，但是不一定全部使用，JVM會根據-Xms參數來調節真正用于JVM的內存

-Xmx -Xms之差就是三個Virtual空間的大小

◆ Young Generation

-XX:NewRatio=8意味著tenured 和 young的比值8：1，這樣eden+2*survivor=1/9

堆內存

-XX:SurvivorRatio=32意味著eden和一個survivor的比值是32：1，這樣一個Survivor就占Young區的1/34.

-Xmn 參數設置了年輕代的大小

◆ Perm Generation

-XX:PermSize=16M -XX:MaxPermSize=64M

Thread Stack

-XX:Xss=128K

1.3 堆棧分離的好處

呵呵，其它的先不說了，就來說說面向對象的設計吧，當然除了面向對象的設計帶來的維護性，復用性和擴展性方面的好處外，我們看看面向對象如何巧妙的 利用了堆棧分離。如果從JAVA內存模型的角度去理解面向對象的設計，我們就會發現對象它完美的表示了堆和棧，對象的數據放在堆中，而我們編寫的那些方法 一般都是運行在棧中，因此面向對象的設計是一種非常完美的設計方式，它完美的統一了數據存儲和運行。

2000年10月份出來
Servlet API 2.3中最重大的改變是增加了filters

servlet 2.4 新增功能:
2003年11月份出來
1、web.xml DTD改用了XML Schema;

Servlet 2.3之前的版本使用DTD作為部署描述文件的定義，其web.xml的格式為如下所示：

<?xml version="1.0" encoding="IS0-8859-1"?>
<!DOCTYPE web-app
PUBLIC "-//sunMicrosystems,Inc.//DTD WebApplication 2.3f//EN"
" <web-app>
.......
</web-app>

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns=" xmlns:workflow=" xmins:xsi=" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
.........
</web-app>

In practice, you only need two settings to optimize caching:

1. Don’t cache HTML
2. Cache everything else forever

“Wooah…hang on!”, we hear you say. “Cache all my scripts and images forever?“

Yes, that’s right. You don’t need anything else in between. Caching indefinitely is fine as long as you don’t allow your HTML to be cached.

“But what about if I need to issue code patches to my JavaScript? I can’t allowbrowsers to hold on to all my images either. I often need to update those as well.”

Simple – just change the URL of the item in your HTML and it will bypass the existing entry in the cache.

In practice, caching ‘forever’ typically means setting an Expires header value of Sun, 17-Jan-2038 19:14:07 GMT since that’s the maximum value supported by the 32 bit Unix time/date format. If you’re using IIS6 you’ll find that the UI won’t allow anything beyond 31-Dec-2035. The advantage of setting long expiry dates is that the content can be read from the local browser cache whenever the user revisits the web page or goes to another page that uses the same images, script or CSS files.

You’ll see long expiry dates like this if you look at a Google web page with HttpWatch. For example, here are the response headers used for the main Google logo on the home page:

If Google needs to change the logo for a special occasion like Halloween they just change the name of the file in the page’s HTML to something like halloween2007.gif.

The diagram below shows how a JavaScript file is loaded into the browser cache on the first visit to a web page:

On any subsequent visits the browser only has to fetch the page’s HTML:

The JavaScript file can be read directly from the browser cache on the user’s hard disk. This avoids a network round trip and is typically 100 to 1000 times faster than downloading the file over a broadband connection.

The key to this caching scheme is to keep tight control over your HTML as it holds the references to everything else on your web site. One way to do this is to ensure that your pages have a Cache-Control: no-cache header. This will prevent any caching of the HTML and will ensure the browser requests the page’s HTML every time.

If you do this, you can update any content on the page just by changing the URL that refers to it in the HTML. The old version will still be in the browser’s cache, but the updated version will be downloaded because of the modified URL.

For instance, if you had a file called topMenu.js and you fixed some bugs in it, you might rename the file topMenu-v2.js to force it to be downloaded:

Now this is all very well, but whenever there’s a discussion of longer expiration times, the marketing people get very twitchy and concerned that they won’t be able to re-brand a site if stylesheets and images are cached for long periods of time.

In fact, choosing an expiration time of anything other than zero or infinite is inherently uncertain. The only way to know exactly when you can release a new version to all users simultaneously is to choose a specific time of day for your cache expiry; say midnight. It’s better to set indefinite caching on all your page-linked items so that you get the maximum amount of caching, and then force updates as required.

Now, by this point, you might have the marketing types on board but you’ll be losing the developers. The developers by now are seeing all the extra work involved in changing the filenames of all their CSS, javascript and images both in their source controlled projects and in their deployment scripts.

So here’s the icing on the cake; you don’t actually need to change the filename, just the URL. A simple way to do this is to append a query string parameter onto the end of the existing URL when the resource has changed.

Here’s the previous example that updated a JavaScript file. The difference this time is that it uses a query string parameter ‘v2′ to bypass the existing cache entry:

The web server will simply ignore the query string parameter unless you have chosen to do anything with it programmatically.

There’s one final optimization you can make. The Cache-Control: no-cache response header works well for dynamic pages as it ensures that pages will always be refreshed from the server; even when pressing the Back button. However, for HTML that changes less frequently it is better to use the Last-Modified header instead. This will avoid a complete download of the page’s HTML, if it has not changed since it was last cached by the browser.

The Last-Modified header is added automatically by IIS for static HTML files and can be added programmatically in dynamic pages (e.g. ASPX and PHP). When this header is present, the browser will revalidate the local, cached copy of an HTML page in each new browser session. If the page is unchanged the web server returns a 304 Not Modified response indicating the browser can use the cached version of the page.

So to summarize:

1. Don’t cache HTML
   • Use Cache-Control: no-cache for dynamic HTML pages
   • Use the Last-Modified header with the current file time for static HTML
2. Cache everything else forever
   • For all other file types set an Expires header to the maximum future date your web server will allow
3. Modify URLs by appending a query string in your HTML to any page element you wish to ‘expire’ immediately.