问题描述
用户量快速增长，访问量在短时间内翻倍，由于前期容量规划做得比较好，硬件资源可以支撑，可是软件系统方面出现了大问题： 40% 的请求都会返回 HTTP 500: Internal Server Error 通过查看日志，发现错误是在 PHP <-> Redis 的连接处理上调试处理
第1次
刚开始时并没有找到根本原因，只能尝试各种与错误相关的办法，例如： 增加 PHP 连接数，并把超时时间从 500ms 增加到 2.5s 禁止掉 PHP 设置中的 default_socket_timeout 在主机系统中禁止掉 SYN cookies 检查 Redis 和 Webservers 的文件描述符数量 增加主机系统的 mbuffer 调整 TCP backlog 数量 ……尝试了很多方法，但全部无效
第2次
想在预发布环境中重现这个问题，可惜，还是没成功，应为流量不够大，无法复现第3次
会不会是代码中没有关闭 Redis 连接呢？ 正常来讲，PHP在执行结束时会自动关闭资源连接，但老版本中会有内存泄漏的问题，保险起见，把代码都修改一遍，手动关闭连接 结果还是无效第4次
怀疑目标：PHPredis 这个客户端库 做 A/B 测试，替换回 predis 这个库，部署到数据中心中 20% 的用户量上 得益于良好的代码结构，替换工作很快完成 可结果依旧是无效，但也有好的一面，可以证明 PHPredis 没问题嘛第5次
查看了一下 Redis 的版本，是 v2.6，当时最新版本是 v2.8.9 升级 Redis 试一下吧，升完后还是不行 没事儿，要保持乐观，这不顺便把 Redis 版本升为最新的了第6次
通过查找大量文档，在官方文档中发现了一个调试好方法 Redis Software Watchdog，打开后执行：查看 Redis 日志：
发现了问题： 每隔几分钟就向硬盘保存一次数据，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版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
