OPcache 配合软链接发布的一个疑问，希望懂的人帮忙解答一下

[mitu9527]

如果一个项目开启了 OPcache，但是不启用预加载，同时该项目使用的是软链接到新目录的方式发布新版本。

因为 OPcache 使用的是文件路径来标识缓存，由于软链接到了新的目录，所以文件路径变了，那不就要重建全部的缓存，不就是缓存雪崩了么？就算开启了 OPcahce 的 file cache 好像也帮不上忙，因为 file cache 也是基于文件路径的。

问题一：是不是真的就会缓存雪崩？ 问题二：除了换成覆盖式发布，还有办法解决么？

[yc8332]

@mitu9527 说了 opcache 不是马上失效，是去检测是否失效，重建。和你自己设计缓存系统一下，你会让所有的请求都去重建一个通用的缓存吗？人家的系统是考虑的。

[mitu9527]

@gantleman 谢谢，我明白服务器崩溃并不是这么容易。我是反过来想，把 OPcache 缓存可能会造成雪崩的情况给找出来并解决，就不用担心雪崩了。OPcache 的设计是基于源文件路径来缓存源文件的字节码，如果采取覆盖式发布，发布完要重置缓存，理论上这里也会发生缓存雪崩，但是此时可以开启 OPcache 的 file cache，虽然压力还是会有，但是不至于崩溃，如果项目还可以开启预加载，压力就会更小，所以在覆盖式发布下，雪崩可以避免。但软链接式发布，新版本的代码全都在新的路径下，而就像上面说的 OPcache 的设计是基于源文件路径来缓存的，所以之前为旧版本建好的缓存全都相当于自动失效了，还占着位置，file cache 也是一样失效了，如果再不能启用预加载，我认为一定会缓存雪崩。至于缓存雪崩会不会导致服务器崩溃，那要看情况。所以我目前认为，软链接式发布，一定会缓存雪崩，这个问题还是要尽量去解决掉的，解决不掉才可以采用你们建议的各种方案进行规避，总之放在那不理会感觉不太好。

另外，你说的外网带宽、内外带宽和硬盘 io 的这种阶梯我其实也知道。如果只是读写文件，那确实几乎百分百适用，因为是对于三者来说，数据量差不多是相等的。但对于 Web 请求来说就不一定了，一个动态 http 请求返回的数据大小一般都在几 k 到小几十 k 之间，而为了生成这份请求数据，读写的 PHP 源文件很可能有小几十个，总大小加起来上百 k 也是很常见的，这时这种速度阶梯不见得可靠，还是要观察。

最后，我到目前为止，只用过 CDN 加速静态请求文件，还没加速过动态请求文件，所以这块保留不谈。

[gantleman]

@mitu9527 也许你还会找到其他的方法，这些方法都能在一定概率上保证服务器不崩溃。并且每增加一个方法都会降低崩溃的概率。也可以找到一种使崩溃大幅下降的方法。也可能会找到一种价格最便宜的方法。或者找到一个价格最便宜并且效果最好的方法。但你思考的问题已经非常的深。恐怕很少人能帮助你，需要你自己去实验代码，检索开源代码，查找论文。从模糊的知识碎片到形成问题，到找到答案，再实验，再迭代。
好像我又自言自语的说奇怪的话，简单说我知道的就这么多了。完全避免崩溃是不可能的，但应该有更好的方法还没被发现。

[mitu9527]

@yc8332 能说一下是怎么做到的么？是用了锁和队列，还是像 APCu 那样通过 slam_defense 去随机抽签？

[mitu9527]

@gantleman 我不认为你说的话奇怪哈，挺实用的，虽然不见得能百分百适用，但方向是没问题的，再次感谢。

[rushssss]

OPcache 的缓存是基于时间的，过期的才会去重载缓存，而发布代码最重要的是什么？是确定新代码上线并且保持一致性！

所以发布代码以后都会主动清除缓存以保持新代码的一致性，这里不是一个可以做性能优化的点，而是必要的操作。

另外根据经验 OPcache 带来的性能提升百分比不会超过整个系统的性能上限，除非你的系统本来就不勘重负必须要运行 warm 的代码才能正常提供服务。

最后如果实在不能接受缓存失效的代价，那就滚动更新了，一个新实例足够 warm 以后撤下一个旧实例再以此类推