我們使用快取的目的主要有如下幾點：
1、減少資料庫查詢次數，降低資料庫負載。
2、縮短php執行路徑，降低web前端負載。
3、減少webserver的請求數量， 降低web前端負載。
第一項 ：比較接近底層， 主要做細粒度資料快取， 比如快取乙個資料物件， 一行記錄等。 只有當物件中的屬性或記錄中的字段值發生變化後使快取失效。 memcached很適合做這個工作。
第二項： 主要將業務邏輯複雜的區域或模組以某種靜態形式快取， 比如頁面中的某個區域，某個具體的action->render後的內容 等。 **arty 快取是個不錯的選擇，當然還有一些其他方案比如 cacalite等。
以上兩類快取策略的實現 必須有乙個統一的 cachekey 管理策略來輔助。 這樣才能達到對快取的精細化控制。
第三項：目前大型**都是用 squid來快取不長更新的頁面，或者說資料的更新對於使用者來說不是很敏感的頁面。 比如首頁、列表頁等。 後台的資料更新對於前台首頁來講晚一時半會兒無所謂。 這種地方就很適合squid ， 他是基於url的一種按時間過期的反向**快取。不誇張的說 上千萬pv的** 70%靠 squid, 30% 靠webserver。
有關於RTX本地快取的問題
最近對外發布了乙個遊戲更新包，因為是大版本，有問題在所難免。於是，很快就要打乙個緊急補丁包出去。這是之前我開發的乙個工具，只對要修改的檔案處理，高效快捷。只需更新乙個檔案，於是叫相關同事在內部rtx上發過來，接著，更新包打好測試後便對外發布。沒想到，更新包出現問題了，一些理論上沒問題的功能出現異常。...
有關於RTX本地快取的問題
最近對外發布了乙個遊戲更新包，因為是大版本，有問題在所難免。於是，很快就要打乙個緊急補丁包出去。這是之前我開發的乙個工具，只對要修改的檔案處理，高效快捷。只需更新乙個檔案，於是叫相關同事在內部rtx上發過來，接著，更新包打好測試後便對外發布。沒想到，更新包出現問題了，一些理論上沒問題的功能出現異常。...
有關頁面快取測試
以前做的乙個有關page cache方面的測試 今天提出來說說我的測試方法，希望對讀者有所幫助。問題回顧 由於 被頻繁請求的頁面為動態生成web頁，導致消耗大量系統資源，為了提高使用者對此類網頁訪問的響應時間，採用對其該部分頁面使用cache技術。對於這種型別的測試其實很簡單，只要求測試人員做到以下...