各種系統開發中都會大量的使用緩存，用於提高程序執行速度，避免過於頻繁的查詢或者是過於複雜的查詢的性能消耗。例如網站名稱這樣的設置項,每個頁 面都會調用到,這屬於頻繁查詢。另外一種比如是一個連接了3,4個表的sql查詢，每次查詢都會造成很大的數據庫消耗，這屬於複雜查詢。
supesite中的緩存類型
supesite中有2種緩存，一種是文件緩存，一種是數據庫緩存。
文件緩存的做法就是執行一次查詢，然後將返回的結果生成一個.php的緩存文件,可以直接在程序中include進來，所有需要的地方都是直接include，這樣就減少了數據庫的查詢。（當然，這裏眼尖的同學會說這個增加了磁盤IO，等會下說個權衡問題）
數據庫緩存的做法是將查詢結果，再序列化成字符串，保存到數據庫，碰到相同條件的查詢語句時候，直接將查詢結果又從數據庫中讀取出來。這裏有些同學 不理解，既然是減少數據庫查詢的負擔，爲什麼又把結果保存到數據庫再讀出來？ 這是我們剛剛提到的複雜查詢的緩存。我們將複雜的，性能消耗很高的查詢結果保存到數據庫，下次碰到一樣的查詢語句的時候，直接取出來，消耗僅僅是一個最簡 單的select語句而已，可以完全避免複雜sql的性能消耗。
以上是2種緩存文件實現提高性能的方式。具體緩存機制如何實現呢？
緩存機制的實現
無論文件緩存還是數據庫緩存，實現都包括3個方面：
生成，更新，調用。
文件緩存的生成
文件緩存較爲簡單。生成文件緩存，只要將數據庫結果整理成字符串，然後應用php自帶的fwrite()函數將字符串寫入文件即可。當然也要注意生成的文件語法要正確，纔可以保證include的時候不會出錯。
supesite中生成緩存的代碼：
其中$tarr是結果集數據組,指定文件名,生成文件就行.arrayeval是supesite中轉換數據爲緩存內容的函數,具體如下:
writefile是supesite封裝的一個寫文件的函數。主要是保證生成的php文件不會存在語法出錯的狀況，並且增加一定的可讀性。
文件緩存的更新
文件緩存的更新，就涉及到了整個業務機制了。有兩種更新需求，一種是即時更新，就是一旦結果集發生變化，緩存文件也要更新，適應於對實時性要求比較 高的配置項。另一種是定時更新，每隔一段時間就檢查是否到了更新的時間點，到了時間點之後，無論結果是否有變化，都執行更新。不過兩種方式沒有絕對的性能 優劣。假設結果集更新非常頻繁，那麼顯然定時更新的方式性能較優，但是如果結果集很久才變化一次，那麼即時更新的方式更划算。
即時更新的實現難度不大，只要在更新結果集的時候同時更新緩存即可。比如系統修改了設置項，那麼在執行完數據庫修改語句後，再加上緩存文件的更新代碼即可。
定時更新則會稍微有一點點麻煩，你需要一個配置項來記住當前文件更新的時間間隔（例如1小時），然後每次觸發執行的時候，都判斷下當前時間與文件時間的差異是否達到了更新的間隔。
文件緩存的調用
文件緩存的調用非常簡單，php中只要include指定的文件就可以了。當然，要稍微注意下include，require，include_once，require_once的差異。一般可使用include_once。
數據庫緩存的實現
數據庫緩存的整體實現機制相比文件緩存來說複雜得多，需要一整套完整的從生成更新到調用的機制。
supesite中採用的機制叫block，中文應該叫簇。這是一個相當好的設計，它極大的簡化了數據調用的方式，並且與數據庫緩存機制緊密結合，目前這種機制在各種開源CMS中都很流行。
首先來看看整套緩存表的設計，整個建表語句如下：
show create table supe_cache;
cachekey緩存主鍵，用於識別緩存，uid基本是無用，可以忽略。cachename是supesite中區分緩存的內容的類型的，例如分類 調用緩存，新聞調用緩存，評論調用緩存等，通過cachename字段，可以允許後臺單獨對某些分類的緩存進行更新。value則是整個調用結果集，它是 php中的結果數組的序列化字符串。updatetime記錄的是下次緩存要更新的時間。
通過這個設計，可以得出整個數據庫緩存的實現思路：生成緩存的時候，生成一個唯一的cachekey作爲主鍵，將結果集序列化爲數組保存在數據庫 中，並記錄下次更新的時間。調用緩存的時候憑藉cachekey主鍵獲取，並判斷updatetime時間是否已經到達更新的時間點，如果需要更新，則更 新緩存表。否則直接讀取緩存的結果集。
這裏面圍繞着一個核心的技術問題：
如何將sql調用跟唯一的cachekey對應起來？也就是說我執行一條sql語句來查詢數據，這個查詢怎麼生成一個唯一的cachekey，然後我下次再次執行同樣的sql就可以跟通過cachekey找到緩存結果？
這裏就是supesite的核心函數block的功勞了。
FROM:http://www.fangyuqiang.com/archives/1025