php+redis在实际项目中HTTP 500: Internal Server Error故障排除
问题描述
用户量快速增长，访问量在短时间内翻倍，由于前期容量规划做得比较好，硬件资源可以支撑，可是软件系统方面出现了大问题：
40%的请求都会返回HTTP500:InternalServerError
通过查看日志，发现错误是在PHP<->Redis的连接处理上
调试处理
第1次
刚开始时并没有找到根本原因，只能尝试各种与错误相关的办法，例如：
增加PHP连接数，并把超时时间从500ms增加到2.5s
禁止掉PHP设置中的default_socket_timeout
在主机系统中禁止掉SYNcookies
检查Redis和Webservers的文件描述符数量
增加主机系统的mbuffer
调整TCPbacklog数量
……
尝试了很多方法，但全部无效
第2次
想在预发布环境中重现这个问题，可惜，还是没成功，应为流量不够大，无法复现
第3次
会不会是代码中没有关闭Redis连接呢？
正常来讲，PHP在执行结束时会自动关闭资源连接，但老版本中会有内存泄漏的问题，保险起见，把代码都修改一遍，手动关闭连接
结果还是无效
第4次
怀疑目标：phpredis这个客户端库
做A/B测试，替换回predis这个库，部署到数据中心中20%的用户量上
得益于良好的代码结构，替换工作很快完成
可结果依旧是无效，但也有好的一面，可以证明phpredis没问题嘛
第5次
查看了一下Redis的版本，是v2.6，当时最新版本是v2.8.9
升级Redis试一下吧，升完后还是不行
没事儿，要保持乐观，这不顺便把Redis版本升为最新的了
第6次
通过查找大量文档，在官方文档中发现了一个调试好方法RedisSoftwareWatchdog，打开后执行：
$redis-cli--latency-p6380-h1.2.3.4 min:0,max:463,avg:2.03(19443samples)
查看Redis日志：
... [20398]22May09:20:55.351*10000changesin60seconds.Saving... [20398]22May09:20:55.759*Backgroundsavingstartedbypid41941 [41941]22May09:22:48.197*DBsavedondisk [20398]22May09:22:49.321*Backgroundsavingterminatedwithsuccess [20398]22May09:25:23.299*10000changesin60seconds.Saving... [20398]22May09:25:23.644*Backgroundsavingstartedbypid42027 ...
发现了问题：
每隔几分钟就向硬盘保存一次数据，fork一个后台存储进行为什么需要大概400ms（通过上面日志的第1条和第2条的时间可以看出来）
到这儿，终于找到问题的根源了，因为Redis实例中有大量的数据，导致每次持久化操作fork后台进程时非常耗时，并且在他们的业务中经常修改key，又导致了频繁触发持久化，也就经常产生对Redis的阻塞
处理办法：使用单独的slave来做持久化
这个slave不处理真实的流量请求，唯一的作用就是处理持久化，把之前Redis实例上的持久化操作转移到这个slave上
效果非常明显，问题基本解决，但有的时候还是会报错
第7次
排查可能阻塞Redis的慢查询，发现有地方使用了keys*
因为Redis中的数据越来越多，这个命令自然会产生严重阻塞
可以使用scan进行替换
第8次
经过前面的调整，问题已经解决，随后的几个月，即使流量在不断增长，也都抗住了
但他们意识到了新的问题：
现在的方式是，来一个请求就创建一个Redis连接，执行几个命令，然后再断开连接，在请求量很大时，这个方式产生了严重的性能浪费，一半以上的命令是用来处理连接操作的，这都超过了业务逻辑上的处理，也使Redis变慢
解决方法：引入proxy，他们选择了twitter的twemproxy，只需要在每个webserver上安装代理，twemproxy负责与Redis实例进行持久连接，这样就大大减少了连接方面的操作
twemproxy还有两个方便的地方：
支持memcached
可以阻止非常耗时或者危险的命令，例如keys、flushall
效果自然很完美，再也不用担心之前的连接错误
第9次
通过数据分片来继续优化：
对不同上下文的数据拆分隔离
对相同上下文的数据进行一致性哈希分片
效果：
减少了每台机器上的请求、负载
提升了缓存的可靠性，不担心节点故障
小结
原文作者写的非常好，详细的描述了他们在Redis应用上的成长历程，是很值得参考的实践经验
原文地址http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production