几乎每一个 php 程序员都发布过代码，可能是通过 ftp 或者 rsync 同步的，也可能是通过 svn 或者 git 更新的。一个活跃的项目可能每天都要发布若干次代码，但是现实却是很少有人注意其中的细节，实际上这里面有好多坑，很可能你就在坑中却浑然不知。
一个正确实现的发布系统至少应该支持原子发布。如果说每一个版本都表示一个独立的状态的话，那么在发布期间，任何一次请求只能在单一状态下被执行。如此称之为支持原子发布；反之如果在发布期间，一次请求跨越不同的状态，那么就不能称之为原子发布。我们不妨举个例子来说明一下：假设一次请求需要 include 两个 php 文件，分别是 a.php 和 b.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 realpath cache 先聊聊 opcode cache，早先大家一直用 apc，现在多半选择 zend opcode，关于它的作用，大家都已经很熟悉，不必多言，唯一需要注意的是 apc 和 zend opcode 对缓存键的选择有所差异：apc 选择的是文件的 inode，zend opcode 选择的是文件的 path。
再聊聊 realpath cache，它的作用是缓冲获取文件信息的 io 操作，大多数时候它对我们而言是透明的，以至于很多人都不知道它的存在，需要注意的是 realpath cache 是进程级别的，也就是说，每一个 php-fpm 进程都有自己独立的 realpath cache。
相关的技术细节特别琐碎，建议大家仔细阅读如下资料：
realpath_cache php’s opcache extension review atomic deploys at etsy cache invalidation for scripts in symlinked folders 在采用软链接发布代码的时候，通常遇到的第一个问题多半是新代码不生效！不管是开启了 apc.stat 或者 opcache.validate_timestamps 配置，还是调用了 apc_clear_cache 或者 opcache_reset 方法，均无效，重启 php-fpm 自然是能够解决问题，不过对脚本语言来说重启太重了！难道除了重启就没有别的办法了么？
事实上之所以会出现这样的问题，主要是因为 opcode cache 是通过 realpath cache 获取文件信息，即便软链接已经指向了新位置，但是如果 realpath cache 里还保存着旧数据的话，opcode cache 依然无法知道新代码的存在，缺省情况下， realpath_cache_ttl 缓存有效期是两分钟，这意味着发布代码后，可能要两分钟才能生效。为了让发布尽快生效，需要以进程为单位清除 realpath cache：
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 操作，所以是原子的。