一次缓存事故排查

周天安排做支付，使用支付宝接口对接，阅读了pdf和demo，自我感觉可以了，在本地上写好相关代码，传到服务器上，整备调试，问题就接着出来了。

一般调试，我喜欢打印语句看看，逻辑是否照着我的思路走，以便知道错误代码在哪。可在服务器打印时，却一直显示上一次的调试结果。如，一开始我输出111，接着，我改为输出222，刷新网页，尼玛，还是111，过了将近1分多钟，才变为222。习惯的，我认为应该是使用的框架开启了缓存，于是我开始看服务器上的缓存配置文件，shit，相应的状态都是关着的，我又去了缓存目录看了下，没发现有文件生成，这见了鬼呢。于是我把断掉调试的范围提升了，直接放在框架入口处，还是一样的，那么说明，压根就没有进入到框架中去，也就不是框架缓存配置的问题，于是我怀疑是web服务器缓存的缘故，过去打开看，我勒个去，还是没有发现相关的配置。

到了山穷水尽的地步了，等等，既然没有发现缓存文件，那么肯定是缓存在内存里了。为了验证这个想法，我做了个测试。在根目录我新建了两个文件，一个静态文件，一个动态php文件。首先在静态文件输出，打开页面，接着改信息，刷新，立马有变化，接着以同样的方法测试动态php文件，又出现了一开始的问题，有缓存。恩，应该是缓存在内存里了，为了验证我的想法，我在php文件里输出phpinfo语句，看了看配置信息，我发现了什么，Zend OPcache，好家伙，原来服务器上了配置了这个。

大伙应该都知道，php是动态语言，每次运行时，都会重新编译，这会很耗性能的。而Zend OPcache 则是通过 opcode 缓存和优化提供更快的 PHP 执行过程。它将预编译的脚本文件存储在共享内存中供以后使用，从而避免了从磁盘读取代码并进行编译的时间消耗。同时，它还应用了一些代码优化模式，使得代码执行更快。简单的了解了Zend OPcache作用后，那么就去php配置文件看看了，果真，在配置文件的最下方返现这么写配置信息

[opcache]zend_extension = /usr/local/php/lib/php/extensions/no-debug-non-zts-20121212/opcache.so;OPcache 的共享内存大小，以兆字节为单位。opcache.memory_consumption=64;用来存储临时字符串的内存大小，以兆字节为单位。;PHP 5.3.0 之前的版本会忽略此配置指令。opcache.interned_strings_buffer=8;OPcache 哈希表中可存储的脚本文件数量上限。;真实的取值是在质数集合 ;{ 223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987 };中找到的第一个比设置值大的质数。 设置值的取值范围是 200 到 100000 之间。opcache.max_accelerated_files=4000;如果缓存处于非激活状态，等待多少秒之后计划重启。;如果超出了设定时间，则 OPcache 模块将杀除持有缓存锁的进程， 并进行重启。;如果选项 opcache.log_verbosity_level 设置为 3 或者 3 以上的数值，;当发生重启时将在日志中记录一条错误信息。opcache.force_restart_timeout=180;检查脚本时间戳是否有更新的周期，以秒为单位。;设置为 0 会导致针对每个请求， OPcache 都会检查脚本更新。;如果 opcache.validate_timestamps 配置指令设置为禁用，那么此设置项将会被忽略。opcache.revalidate_freq=60;如果启用，则会使用快速停止续发事件。;所谓快速停止续发事件是指依赖 Zend 引擎的内存管理模块;一次释放全部请求变量的内存，而不是依次释放每一个已分配的内存块。opcache.fast_shutdown=1;仅针对 CLI 版本的 PHP 启用操作码缓存。 通常被用来测试和调试。opcache.enable_cli=1

配置文件里的“opcache.revalidate_freq=60”是说明，会每隔一分钟检测一次脚本文件是否更新，那么就找到问题的根本了，改为0，也就是每次运行时都去检测一下，重新启动php，搞定。