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

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

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

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

@coosir 明白了，谢谢！

@loveyu 高并发下重建缓存那个瞬间，压力比不开启 OPcache 直接去读 PHP 源文件还要大，直接不管了么？我觉得这个点可能是 PHP 压力的最高点，最有可能撑不住的就是这个点，所以才想问。

@coosir opcache 被重置后，不也是相当于任何缓存都没有了，效果不也和缓存雪崩一样了么？瞬间压力就上来了。

@yc8332 请求一个新文件，不会去更新？高并发场景下，多人同时去读取这个文件，然后尝试去把这个文件的字节码写到 OPcache 中，那个瞬间，CPU 压力不就爆了？

@hauzi 我明白预加载可能解决这个问题，但是不是所有项目都能预加载，而且预加载是把缓存放在工作进程上，也不是所有内容都适合预加载，所以我才问不启用预加载的情况下，有没有办法解决这个问题。

@yc8332 OPcache 也算是缓存，怎么不能用这些词啊，有人规定这些词只能用在 redis 和 memcache 上？再者，你确定你理解我在问什么了么？我看不是我讲的不够清楚，是你没理解。

@simapple 就是想问一下，使用软链接到新目录的方式发布新版本，旧的 OPcache 缓存就全部失效，就相当于从头建缓存，在高流量的服务器上压力不就瞬间上来了？想问一下有没有什么办法解决。

@yc8332 我去改一下

@rushssss 这个不是缓存雪崩么，那是啥？第二点，代码发布到新目录下，所有文件的路径全部变了，OPcache 中现有的缓存全都是以前的路径的，也用不到了，相当于自动作废了，不是么？然后这时候去访问新版本，不就相当于从头开始建缓存么？

就是数据结构书籍（比如大话数据结构）中介绍的那些结构（栈，队列，树，图等等）和算法（查找、和排序）。

既然你不提钱的话，那就苹果吧。

没有哪种更正确，有好几种舍入模式，具体用哪种模式还是取决于需求。

@hahaandyou001 嗯，听说了。

没有广告的手机都很贵，苹果、三星皆是如此，因为你买的时候已经直接付费去广告了，说到底不过是选价格还是选质量，这就因人而异了。

网上搜了一下，可能是 mysql 的一个 bug ；可以考虑升级一下 mysql 版本，也可以考虑优化一下 SQL 语句，避开这个问题，上面的语句应该可以减少一层甚至两层子查询，说不定就避开了。

这是题外话：如 2 楼所说，你把错误日志最重要的信息给漏掉了，这么提问久了，你身边的人可能会觉得你在故意耍他，虽然你可能是无意的。

这个问题别人不好重现，找找 mysql 的日志，看看有没有有用的提示，贴出来，好让大家帮你看看是咋回事。

扣掉输出和返回，一共 5 行代码都不到，有这么“无解”么，单步调试一下，眼睛瞪大点。自己解决后把帖子给沉了吧。