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

• 資深大佬 : rushssss

  第一缓存雪崩不是这个意思，第二你更新了代码但是 OPcache 不更新跑的不就是原来的代码了？ 那更新代码有啥意义

• 主 資深大佬 : mitu9527

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

• 資深大佬 : yc8332

  你在说什么？先把概念搞清楚再发帖吧

• 主 資深大佬 : mitu9527

  @yc8332 我去改一下

• 資深大佬 : simapple

  你是要做什么？让不同机器的 php 进程复用同一份 opcache ？

• 主 資深大佬 : mitu9527

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

• 資深大佬 : yc8332

  opcache 的缓存也是有时间的。并不是说你代码更新了马上就更新，更新也不是全部都更新，用到才会更新。。而且这个也不是什么缓存击穿、缓存雪崩。。。那个是相对应缓存系统来说的，有兴趣可以自己搜索一下

• 主 資深大佬 : mitu9527

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

• 資深大佬 : hauzi

  先把常用的 PHP 脚本预热下

• 主 資深大佬 : mitu9527

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

• 資深大佬 : yc8332

  @mitu9527 opcache 不会马上都更新，你觉得你的 php-fpm 进程一开始，服务器的处理能力会影响到你的 qps 吗？如果不会，更新代码也不会有这个问题。

• 主 資深大佬 : mitu9527

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

• 資深大佬 : coosir

  更新代码后，主动清一下 opcache

• 主 資深大佬 : mitu9527

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

• 資深大佬 : loveyu

  看了上面的。主安心摘流量，然后一点点放量吧，这样就没这些问题。

  还要，清缓存就是了，并发读文件建缓存那点压力，忽略吧

• 主 資深大佬 : mitu9527

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

  @mitu9527 真有这么大流量那就是很多个实例来支撑，那么就不应该热更。
  就像上面说的，发布的时候部分实例先摘掉下线，更新代码，预热好，再上线。逐步更新所有实例防止服务中断。

• 主 資深大佬 : mitu9527

  @coosir 明白了，谢谢！

• 資深大佬 : gantleman

  @mitu9527 缓存服务重置后，重建缓冲存是否会导致后端压力过大。通常情况下外网带宽远远小于内网带宽，内网带宽远远小于硬盘 io 。所以一般情况下不存在击穿或雪崩。有一种特殊情况，就是所有外网带宽持续集中在一点，外网带宽总和大于磁盘 io 。例如产品活动的特殊情况。然后缓存服务器故障重置，压力突然后移到 io 。进而导致拒绝服务。

  出现这种情况首先有一个必要条件，就是外网带宽大于磁盘 io 。当前服务器磁盘 io 一般速度为 500m 每秒。单台服务外网带宽约为 24m 。大概是大于 20 台主机的集群规模。那么这 20 多台服务器接到请求不做任何处理直接转发给同一台服务器。并且那台服务器缓存重置出现雪崩。

  第二服务器读写数据有 28 定律，20%为写入操作，80%为读取操作。出现雪崩也就是对于 80%的读取操作不做 CDN 加速。如果有 cdn 加速，雪崩的条件就要上升到 100 台服务器同时写入并内存重置。 也就是需要外网带宽要高达 2400m，才可能触发雪崩。这里还没考虑限流措施。

  雪崩有存在的可能，但在实际运维的条件下，要达到雪崩的条件非常苛刻。

• 資深大佬 : wangritian

  如果你真的担心大流量，优化业务逻辑为先，用好 redis，然后做负载均衡+多台部署，时间允许的话，底层代码换 swoole 协程，最后上一套 k8s 做好自动部署

• 資深大佬 : 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 以后撤下一个旧实例再以此类推