@Mithril 服务端会话有很多种成熟的方案了，小型、中型和大型架构都有，这个觉得不是问题。

@KuroNekoFan 但是我感觉 JWT 的缺点也挺多的，觉得至少在会话这块用起来不合适。

小米 9，就是电池不耐用，重度估计要一天两充，甚至三充。

恭喜楼主不用再掉自己的头发、花自己的时间去解决那些本该是微软要去解决的问题。

同 5 楼，Python 在 web 没有未来

@alexkkaa 你看看你的回复，涵盖了多少种争论了，你是有多关注这些争论的话题啊？你好好争，我不拦你。

整天搞语言之争、性能之争，你们累不累？是有多自卑，还是虚荣心这么强？

也难怪国外程序员嘲笑国内程序员菜，总想站在巨人的肩膀上，然后天天换肩膀，不菜就怪了。

13 年到 18 年国内互联网行业大跃进，浮夸之风盛行，各种对比（语言、性能等等）和名头（大数据、高并发、架构师等等）就都来了。19 年开始经济形势下滑了，而且未来几年也大概率继续下滑，你们还没冷静下来么？

风口过了，留下了一群惊慌失措的人在争吵。

代码“整洁”不等于代码“少”，代码要整洁到什么程度也不是一成不变的，要视情况决定。

建议大家去读读《程序员修炼之道》，相信会有一些不一样的收获。

等长大了，估计已经没人用了。

平时认真练即可，重点是考试时的心态，科二考试有好几个地方可以停下来思考一下，要好好利用，祝你下次考过。

去年年底考科二的时候，可能是分到了考场最烂的车，教练目送了我好几次，那表情、那眼神至今难忘啊，然后没啥问题考过了。

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

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