用脑思考,用心琢磨,用行动证实 [登录·注册]

吕滔博客

首页 开发 运维 工具 摄影

php+redis在实际项目中HTTP 500: Internal Server Error故障排除

运维,工具 memory 发布于February 5, 2017 标签: PHP, Redis

问题描述
用户量快速增长,访问量在短时间内翻倍,由于前期容量规划做得比较好,硬件资源可以支撑,可是软件系统方面出现了大问题:
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-cli --latency -p 6380 -h 1.2.3.4
min: 0, max: 463, avg: 2.03 (19443 samples)

查看 Redis 日志:

...
[20398] 22 May 09:20:55.351 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:20:55.759 * Background saving started by pid 41941
[41941] 22 May 09:22:48.197 * DB saved on disk
[20398] 22 May 09:22:49.321 * Background saving terminated with success
[20398] 22 May 09:25:23.299 * 10000 changes in 60 seconds. Saving...
[20398] 22 May 09:25:23.644 * Background saving started by pid 42027
...

发现了问题:
每隔几分钟就向硬盘保存一次数据,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

相关推荐

添加新评论

网站状态

  • 栏目分类:49个
  • 发布文章:1534篇
  • 用户评论:751条
  • 开博至今:4127天

正则速查

[abc] 匹配中括号中的单个字符,如a或b或c
[^abc] 匹配除了a、b、c等字符的其他单个字符
[a-z] 匹配一个字符范围,如a到z
[a-zA-Z] 匹配一个字符范围,如a-z 或 A-Z
^ 匹配行的开始
$ 匹配行的结束
\A 匹配一个字符串的开始
\z 匹配一个字符串的结束
. 匹配任意单个字符
\s 匹配空白字符,如空格,TAB
\S 匹配非空白字符
\d 匹配一个数字
\D 匹配非数字
\w 匹配一个字母
\W 匹配非字母
\b 匹配字符边界
(...) 引用所有括号中的内容
(a|b) a或者b
a? 零个或1个a
a* 零个或多个a
a+ 1个或多个a
a{3} 3次重复的a
a{3,} 3次或3次以上重复的a
a{3,6} 3到6次重复的a

修正符

/g 查找所有可能的匹配
/i 不区分大小写
/m 多行匹配
/s 单行匹配
/x 忽略空白模式
/e 可执行模式,PHP专有
/A 强制从目标字符串开头匹配
/D 使用$限制结尾字符,则不允许结尾有换行
/U 只匹配最近的一个字符串;不重复匹配

最新回复

  • hyvm.net: 好文章,点赞
  • 新闻头条: 文章不错非常喜欢
  • 志志: 折腾了半天 感谢大神
  • Smithk464: Hey very nice blog!! Man .. Exce...
  • memory: 我已投奔phpstrom.哈哈
  • 逆风飘扬: 原来是这样!!!!!!!用惯了VS的来用zend studio没...
  • NS: 请问我这么写之后抛出了一个 javax.crypto.BadPa...
  • memory: 有内部使用的,开源的过段时间放个出来。
  • 小小: 博主 ,可有写好的
  • 111: 我看不懂唉,好多内容
  • memory: 咧,难道我手误了,回头看下官方文档去...
  • 阿东: 进入镜像的 后面 /bin/bash 是错的 你应该用的是/b...
  • memory: 帝国的安全性来说,比phpcms和dede要好的多啦.
  • 西点师培训班: 现在帝国用的少了,开源的不太会改,老被黑
  • yiyiyizoe: 谢谢~
  • memory: 不好意思呀,这个也是13年的时候,安装过淘宝的这个开源系统,做的...
  • yiyiyizoe: 实在抱歉,如果可以回答的话,只需要看这个问题:ldb支持批量导入...