首頁  >  文章  >  後端開發  >  正確發布PHP程式碼的實例分享

正確發布PHP程式碼的實例分享

小云云
小云云原創
2018-03-12 14:44:402820瀏覽


幾乎每一個PHP 程式設計師都發布過程式碼,可能是透過 FTP 或 rsync 同步的,也可能是透過svngit 更新的。一個活躍的專案可能每天都要發布若干次程式碼,但是現實卻是很少有人注意其中的細節,實際上這裡面有好多坑,很可能你就在坑中卻渾然不知。

一個正確實現的發布系統至少應該支援原子發布。如果說每一個版本都表示一個獨立的狀態的話,那麼在發布期間,任何一次請求只能在單一狀態下執行。如此稱之為支持原子發布;反之如果在發布期間,一次請求跨越不同的狀態,那麼就不能稱之為原子發布。我們不妨舉個例子來說明一下:假設一次請求需要include 兩個PHP 文件,分別是a.phpb.php,當include a.php 完成後,發布程式碼,接著include b.php,如果處理不當的話,那麼就可能會導致舊版本的a. php 和新版的b.php 同時存在於同一個請求之中,換句話說就是沒有實作原子發布。

開源世界裡有很多不錯的發布程式碼工具,例如 ruby 社群的capistrano,其流程大致就是發佈程式碼到一個全新的目錄,然後再軟連結到真正的發布目錄。

├── current -> releases/v1
└── releases
    ├── v1
    │   ├── foo.php
    │   └── bar.php
    └── v2
        ├── foo.php
        └── bar.php

不過鑑於 PHP 本身的特殊性,如果只是簡單地套用上面的流程,那麼將很難實現真正的原子發布。要理清個中緣由,還需要了解PHP 中的兩個Cache 的概念:

  • ##opcode cache

  • 正確發布PHP程式碼的實例分享 cache

#先聊聊

opcode cache,基本上就是apczend opcode,關於它的作用,大家都已經很熟悉,不必多言,需要注意的是apc 的bug 很多,比如開啟了apc. enable_cli 配置後就會有很多靈異問題,所以說opcode cache 還是盡可能使用zend opcache 吧,如果需要快取數據,可以用apcu。此外apczend opcode 對快取鍵的選擇有所差異:apc 選擇的是檔案的inodezend opcode 選擇的是檔案的path

再聊聊

正確發布PHP程式碼的實例分享 cache,它的作用是緩衝獲取文件資訊的IO 操作,大多數時候它對我們而言是透明的,以至於很多人都不知道它的存在,需要注意的是正確發布PHP程式碼的實例分享 cache 是進程層級的,也就是說,每一個php-fpm 進程都有自己獨立的 正確發布PHP程式碼的實例分享 cache

假設在發布程式碼期間,

opcode cache正確發布PHP程式碼的實例分享 cache 裡的資料出現過期,那麼就會出現一部分快取是舊文件,一部分快取是新文件的非原子發布的情況,為了避免這種情況,我們應該保證緩存過期時間足夠長,最好是除非我們手動刷新,否則永遠不過期,對應到配置上就是:關閉apc.stat、opcache.validate_timestamps配置,設定足夠大的正確發布PHP程式碼的實例分享_cache_size、正確發布PHP程式碼的實例分享_cache_ttl 配置,必要的監控總是有好處的。

相關的技術細節特別瑣碎,建議大家仔細閱讀如下資料:

    正確發布PHP程式碼的實例分享_cache
    PHP’s OPCache extension review
    Atomic 正確發布PHP程式碼的實例分享s at Etsy
    Cache invalidation for scripts in symlinked folders
在採用軟連結發布程式碼的時候,通常遇到的第一個問題多半是新程式碼不生效!即使呼叫了 apc_clear_cache 或 opcache_reset 方法也無效,重啟

php-fpm 自然是能夠解決問題,不過對腳本語言來說重啟太重了!難道除了重啟就沒有別的辦法了?

事實上之所以會出現這樣的問題,主要是因為

opcode cache 是透過正確發布PHP程式碼的實例分享 cache 獲取文件信息,即便軟連結已經指向了新位置,但如果正確發布PHP程式碼的實例分享 cache 裡還保存著舊資料的話,opcode cache 依然無法知道新程式碼的存在,預設情況下,正確發布PHP程式碼的實例分享_cache_ttl 快取有效期是兩分鐘,這表示發布代碼後,可能要兩分鐘才能生效。為了讓發布盡快生效,需要以進程為單位清除正確發布PHP程式碼的實例分享 cache

<?php

    $key = &#39;php.pid_&#39; . getmypid();    if (($rev = apc_fetch($key)) != DEPLOY_VERSION) {        if($rev < DEPLOY_VERSION) {
            apc_store($key, DEPLOY_VERSION);
        }

        clearstatcache(true);
    }

如此在

apc 環境下基本上就能工作了,但是在 zend opcode 環境下還可能有問題。因為在預設情況下opcache.revalidate_path 是關閉的,此時會快取未解析的符號連結的值,這會導致即便軟連結指向修改了,也無法生效,所以在使用zend opcode的時候,如果使用了軟鏈接,視情況可能需要把opcache.revalidate_path 啟動。

详细介绍参考:PHP’s OPCache extension review。

BTW:如果需要手动重置 opcode cache,需要注意的是因为它是基于 SAPI 的概念,所以不能直接在命令行下调用 apc_clear_cache 或者 opcache_reset 方法来重置缓存,当然办法总是有的,那就是使用 CacheTool 在命令行下模拟 fastcgi 请求。

分析到这里,我们不妨反思一下:在 PHP 中原子发布之所以是一个棘手的问题,归根结底是因为软链接和缓存之间的的矛盾。不管是 opcode cache 还是 正確發布PHP程式碼的實例分享 cache,都是 PHP 固有的缓存特性,基于客观需要无法绕开,如此说来是否有办法绕开软链接,使其成为马奇诺防线呢?答案是 NGINX 的 $正確發布PHP程式碼的實例分享_root:

    fastcgi_param SCRIPT_FILENAME $正確發布PHP程式碼的實例分享_root$fastcgi_script_name;    fastcgi_param DOCUMENT_ROOT $正確發布PHP程式碼的實例分享_root;

有了 $正確發布PHP程式碼的實例分享_root,即便  DOCUMENT_ROOT 目录中含有软链接,NGINX 也会把软链接指向的真正的路径发给 PHP,也就是说,对 PHP 而言,软链接已经不存在了!不过作为代价,每一次请求,NGINX 都要通过相对昂贵的 IO 操作获取 $正確發布PHP程式碼的實例分享_root 的值,通过 strace 命令我们能监控这一过程,下图从 currentfoo 的过程:

正確發布PHP程式碼的實例分享

在本例中,压测发现使用 $正確發布PHP程式碼的實例分享_root 后,性能下降了大约 5% 左右,不过明眼人一下就能发现,虽然  $正確發布PHP程式碼的實例分享_root  导致了 lstat  和 readlink 操作,但是 lstat 操作的次数是和目录深度成正比的,也就是说目录越深,执行的 lstat 次数越多,性能下降也就越大。如果能够降低发布目录的深度,那么可以预计还能降低一些性能损耗。

结尾介绍一下 Deployer,它是 PHP 中做得比较好的工具,有很多特色,比如支持并行发布,具体演示如下图,左边是串行,右边是并行,使用「vvv」能得到更详细信息:

正確發布PHP程式碼的實例分享

不过 Deployer 在原子发布上有一点瑕疵,具体见 release/symlink 代码:

<?php// 正確發布PHP程式碼的實例分享:releaserun("cd {{正確發布PHP程式碼的實例分享_path}} && if [ -h release ]; then rm release; fi");
run("ln -s $releasePath {{正確發布PHP程式碼的實例分享_path}}/release");// 正確發布PHP程式碼的實例分享:symlinkrun("cd {{正確發布PHP程式碼的實例分享_path}} && ln -sfn {{release_path}} current");
run("cd {{正確發布PHP程式碼的實例分享_path}} && rm release");?>

release 的时候,它是先删除再创建,是一个两步的非原子操作,在 symlink 的时候,看上去「ln -sfn」是单步原子操作,实际上也是错误的:

shell> strace ln -sfn releases/foo currentsymlink("releases/foo", "current")      = -1 EEXIST (File exists)unlink("current")                       = 0symlink("releases/foo", "current")      = 0

通过 strace 我们能清晰的看到,虽然表面上使用「ln -sfn」是一步操作,但是内部依然是按照先删除再创建的逻辑执行的,实际上这里应该搭配使用「ln & mv」

shell> ln -sfn releases/foo current.tmpshell> mv -fT current.tmp current

先通过 ln 创建一个临时的软链接,再通过 mv 实现原子操作,此时如果使用 strace 监控,会发现 mv「T」 选项实际上仅仅执行了一个 rename 操作,所以是原子的。

BTW:在使用「ln -sfn」前后,如果使用 stat 查看新旧文件的 inode 的话,可能会发现它们拥有一样的 inode 值,看上去和我们的结论相悖,其实不然,实际上只是复用删除值而已(如果想验证,注意 Linux 会复用,Mac 不会复用)。

据说一千个人的心中就有一千个哈姆雷特,不过我希望所有的 PHP 程序员在发布 PHP 代码的时候都能采用一种方法,那就是本文介绍的方法,正确的方法。

相关推荐:

php代码标志基础讲解

提高PHP代码质量的方法

JS和PHP代码实现用户输入数字后显示最大的值

以上是正確發布PHP程式碼的實例分享的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn