緩存

同事發現我們對一些采集爬蟲進行限制後，給出的403拒絕狀态也會被CDN緩存起來，造成後續正常用戶訪問的時候也被拒絕，于是詳細了解了各CDN對http/https訪問報錯狀态的緩存處理。

首先是看Cloudflare，其文檔 Configuring cache TTL by status code 中有明确說明，如果在沒有設置Cache Control的情況下：

• HTTP 200, 301: 120分鐘
• HTTP 302: 20分鐘
• HTTP 404: 10分鐘
• HTT

　　我們選用Drupal的一個重要原因是其對多語言的支持，在實際使用中也發現多語言支持的一些問題，特别是對數據庫負載的影響很大，我們已經想過不少辦法了。例如：Drupal設置Memcache緩存、修改緩存翻譯詞的長度、減少翻譯相關數據表的尺寸等。

　　這兩天對一台阿裡雲RDS負載問題進行排查的時候，再次開啟Devel來查看IP Location系列典型頁面的SQL查詢語句，從幾個方面進行了優化：

• 關閉不是很必要的模塊，例如theme color, dashboard, comment等，可以減少幾次數據庫查詢次數；
<

　　百度MIP有批量提交API我們用過，看到有清除MIP緩存的API，但以前沒用過。最近我們在百度搜索資源平台發現一個奇怪的問題：流量排在最前面的全部都是www.example.com/xxx/node/13865?mip這樣的網址，在手機百度裡面各種搜索詞本來應該是到我們站不同的頁面，但卻都指向了上面這一個網址，從百度統計中看是從2019年1月5日開始的，但原因找了幾天都找不到，在www.baidu.com中搜索結果點擊到我們站都是正常的，但m.baidu.com中搜索結果點擊到我們站卻是錯誤的。

　　我們想到可能是百度自己的MIP頁面索引出了問題，給資源平台反饋中

　　MediaWiki的文件緩存(File Cache)在我們實際使用的網站中還是很重要的，可以讓訪問速度快很多，不過有些頁面要求有一定的實時性，緩存過期時間不宜過長，我們以前都是設置的統一過期時間，然後部分頁面不生成文件緩存，這些不生成文件緩存的頁面往往成為了MySQL服務器中慢查詢的來源。

　　今天先是想了一個辦法，Linux服務器上設置crontab，定時執行一個批處理文件，來删除cache目錄下的緩存文件，這樣可以實現我們需要的對不同頁面緩存不同的時間長度，但缺點是設置比較麻煩，而且執行磁盤查找、删除在數據量大的時候比較慢。

　　後來又想了

　　Drupal網站對數據庫服務器的壓力由來已久，特别是Views做成的頁面是最可能導緻負載升高的原因，無論是以前自己服務器上的MySQL還是換用阿裡雲的RDS。

　　以前也采取一些緩存的措施來降低負載，但偶爾會出現一些問題，我翻看以前的博客中記錄有《Drupal網站Views生成頁面Title改為變量的問題》、《一個Drupal網站Views消失的排查》。

　　後來Drupal 6升級Drupal 7後似乎有些變化，但我一直也沒有深究，基本上都是把Views的查詢緩存設置為6天，把顯示緩存設置為0，在系列網站的xxx.views_default.

　　前一段時間發現分省的郵政編碼系列網站首頁常常會出現一個Views做的Block為空白的情況，例如北京郵政編碼首頁的“北京地市區縣郵編”這一個Block裡面沒有内容，這樣情況以前偶爾比較罕見會發生，例如幾個月偶爾見到一次，但最近卻成了經常的事情，每次重新清理該網站緩存會恢複，但1、2天後又出問題。

　　我用阿裡雲的網站監控設置了對該站首頁每隔5分鐘讀取一次，如果發現沒有應該存在的内容就報警，連續幾天夜間準點開始報警，先以為是cron運行的結果，但時間不對，後來發現是巡檢程序讀取head和content的時候偶爾會這樣，但具體原因依然不清楚，還是清理緩存後恢複，不久又出錯。😢

　　很早前開始使用MediaWiki的時候就聽說了MemCache，但一直沒有用過，直到前幾個月下力氣做Drupal優化，才安裝嘗試了Memcache，果然是效果明顯，對數據庫的壓力下降了很多，命中率在80%左右，這樣即使安裝在單台服務器上，也會讓該服務器的負載下降不少。當時記錄了一篇博客《Drupal單服務器設置Memcache緩存》。

　　而Memcache的典型應用其實是部署在專門的緩存服務器上，我曾經看過Wikipedia的服務器拓撲圖，緩存服務器的數量還不少。我們近期在準備撤掉部分以前的獨立服務器轉用雲平台，所以在試用阿裡雲的時候留意了有專門的開放緩存服務O

　　很久前用MediaWiki的使用就聽說過Memcache來加速網站，後來用Drupal看一些優化措施中也說到Memcache，但一直沒有時間精力去嘗試。

　　前些天把PHP代碼緩存的APC模塊安裝後，看統計數據，PHP程序代碼的命中率幾乎達到100%，服務器負下降還是比較明顯的。就幹脆一鼓作氣，我和同事配合把Memcache也安裝測試。

　　APC的安裝至需要與服務器的PHP環境、模塊設置有關，與Drupal程序沒有特别的關系，但Memcache除了服務器環境安裝以外，還需要對Drupal系統加裝模塊來利用Memcache，下面就記錄一下服務器

　　前幾年一直用MediaWiki，從2006年到2010年，在2011年初改用Drupal後，以前的Wiki網站就基本上停止了更新，MediaWiki的版本也停在了1.16，後來還遇到不少網友站長咨詢這方面的事情，我也隻好告訴對方後面的版本我都不熟悉了。

　　雖然網站平台停止了更新，但運用還在繼續，除了把一些站的留言關閉外，還是有幾個曆史悠久的網站保留了用戶留言、交互的功能，依然需要解決一些遺留的小問題。近期花了一些時間來解決下面幾個問題，記錄如下：

反垃圾：

　　這兩年國外的垃圾信息沒有停，間隔着幾天發幾條、幾十條，挺讨厭的，但又沒有到必須用技

　　從用MediaWiki做網站開始，服務器負載一直就是個問題，為了解決這個問題，我們添加了各種緩存，如MediaWiki的多種緩存機制，包括File Cache，也加上了外部的Squid。後來做Drupal網站并不需要Squid，但因為服務器上已經安裝了Squid，我們也隻好把Drupal架設在Squid之後，另外Drupal也采用了内部core緩存和Boost緩存。

　　這些緩存機制可以解決不少問題，但緩存主要對數據量小、每頁訪問多的網站有明顯效果，而對于數據量很大、每頁訪問少的網站起不到明顯效果，有時甚至因為緩存文件過多起到反效果，而且緩存更新機制也有些小問題。