問題背景

通過啟用Opcache的緩存優化,將PHP代碼預編譯為Opcode緩存到共享內存中供進程反復調用,從而減少了重復從磁盤解析PHP代碼的時間消耗,顯著的提高了PHP性能,提升了業務性能的調用,但是也引發了一些問題,就是我們每次更新了相應的PHP代碼后,web server 無法即時加載到更新后的代碼。

解決方案

(一)、設置Opcache腳本驗證時間

可以通過更改 Opcache 以下兩個配置選項來調整代碼重載時間

opcache.revalidate_freq=0 檢查腳本時間戳是否有更新的周期，以秒為單位。（如果設置為 0 會導致針對每個請求， OPcache 都會檢查腳本更新）

opcache.validate_timestamps=0 如果啟用，那么 OPcache 會每隔 opcache.revalidate_freq 設定的秒數 檢查腳本是否更新。

PS:在實際生產環境中,為了盡可能達到最優性能,盡量不開啟文件更新驗證,因為每次驗證都會重新預編譯PHP代碼到共享內存中。

(二)、重啟 | 重載 php-fpm 進程

每次重啟或重啟 php-fpm 進程便會重新解析PHP腳本文件,但是重啟 fpm 進程可能會導致請求中斷,從而導致寫入臟數據 或者 造成事務回滾等一系列異常。

重載相對于重啟則平順很多,不會導致用戶請求直接中斷,相對來說風險低很多,但是php-fpm 收到reload信號，便會向所有子進程發送SIGGUIT信號，同時注冊一個定時器，在規定的時間之內子進程沒有退出，接著在發送SIGTERM信號，結束子進程。如果在一秒之內子進程還是沒結束 直接發送SIGKILL 強制殺死。

重啟php-fpm

service php-fpm restart

重載php-fpm

services php-fpm reload

或 kill -USR2 `cat /usr/local/php/var/run/php-fpm.pid`

(三)、手動清理緩存

除了上面的兩種方式,還有更為穩妥一點的緩存清理,我們可以通過opcache_reset()和opcache_invalidate() 函數來刷新Opcache緩存。

opcache_reset() - 重置整個Opcode緩存,所有的PHP腳本將會被重新解析再預編譯為Opcode。

opcache_invalidate() - 清除指定腳本緩存,可以傳遞兩個參數,一個是刷新文件路徑,一個是force字段, 如果 force 沒有設置或者傳入的是 FALSE，那么只有當腳本的修改時間 比對應Opcode的時間更新時，腳本的緩存才會失效。

需要注意的是，當PHP以PHP-FPM的方式運行的時候，opcache的緩存是無法通過php命令進行清除的，只能通過http或cgi到php-fpm進程的方式來清除緩存,我們可以編寫一個對外接口,來達到清理緩存的目的。

相關實現如下(框架:laravel):

Route::any('cache-reset', function () {
  //重置整個Opcode緩存
  dd(opcache_reset());
});

Route::any('cache-update', function () {
  //清除掉最近一次更新文件的緩存
  exec('git diff --name-only HEAD~ HEAD', $output);
  foreach ($output as $file) {
    $path = base_path($file);
    opcache_invalidate($path, true);
  }
  dd('刷新完成');
});

總結

通過上面的三種策略,可以實現 Opcache 緩存更新的目的,但是在流量高峰期或者大流量的服務端,每次更新緩存都是一件非常損耗資源的事情,Opcache在重建緩存時,也不會禁止其他進程讀取,因此就會造成反復新建緩存,因此想要達到最佳的性能調配:

• 最好不要在高峰期清理緩存
• 高峰期不要頻繁的更新代碼,清理緩存,會造成重復新建緩存
• 如果需要更新,可以嘗試削弱服務端權重,實現逐個更新的目的。
• 如果需要強制更新,盡量選擇手動清除緩存的方式,來重建Opcache緩存,使代價最小化。

以上就是解決PHP Opcache 緩存刷新、代碼重載出現無法更新代碼的問題的詳細內容，更多關于PHP Opcache 緩存刷新、代碼重載的資料請關注腳本之家其它相關文章！