Redis 应用案例 - 在问题中不断成长

本文翻译整理自 Andy Grunwald 发布的一篇文章,写的是作者所在公司使用 Redis 时遇到的问题,以及处理过程,在不断解决调整中积累了很多 Redis 的使用经验

背景

产品类型:酒店搜索

技术选型:前端 PHP + 后端 Java,都会用到 Redis

Redis 使用场景:缓存、数据持久化前的临时存储

2010年开始应用 Redis,PHP 对其操作时使用的是 Predis 这个客户端库

2013年改用了 phpredis 作为客户端库

2014年开始出现问题

问题描述

用户量快速增长,访问量在短时间内翻倍,由于前期容量规划做得比较好,硬件资源可以支撑,可是软件系统方面出现了大问题:

40% 的请求都会返回 HTTP 500: Internal Server Error

通过查看日志,发现错误是在 PHP <-> Redis 的连接处理上

调试处理

第1次

刚开始时并没有找到根本原因,只能尝试各种与错误相关的办法,例如:

  1. 增加 PHP 连接数,并把超时时间从 500ms 增加到 2.5s
  2. 禁止掉 PHP 设置中的 default_socket_timeout
  3. 在主机系统中禁止掉 SYN cookies
  4. 检查 Redis 和 Webservers 的文件描述符数量
  5. 增加主机系统的 mbuffer
  6. 调整 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还有两个方便的地方:

  1. 支持 memcached
  2. 可以阻止非常耗时或者危险的命令,例如 keys、flushall

效果自然很完美,再也不用担心之前的连接错误

第9次

通过数据分片来继续优化:

  1. 对不同上下文的数据拆分隔离
  2. 对相同上下文的数据进行一致性哈希分片

效果:

  1. 减少了每台机器上的请求、负载
  2. 提升了缓存的可靠性,不担心节点故障

小结

原文作者写的非常好,详细的描述了他们在 Redis 应用上的成长历程,是很值得参考的实践经验

原文地址

http://tech.trivago.com/2017/01/25/learn-redis-the-hard-way-in-production

原文发布于微信公众号 - 性能与架构(yogoup)

原文发表时间:2017-02-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IMWeb前端团队

关于webrtc peer to server 为什么还需要使用stun服务

本文作者:IMWeb jaychen 原文出处:IMWeb社区 未经同意,禁止转载 关于webrtc peer to server 为什么还需要使用s...

40010
来自专栏开源优测

JMeter性能测试基本过程及示例

性能测试是我们日常测试过程中,必须掌握的技能。通过进行性能测试,我们能分析服务端的整体性能、负载等,以便进一步评估我们的业务系统是否能满足当前运营生产及未来业务...

1162
来自专栏Java架构

阿里双十一秒杀系统架构设计,有哪些技术关键点?

秒杀活动只是网站营销的一个附加活动,特点是:时间短、并发访问量大,如果和网站原有应用部署在一起,必然会对现有业务造成冲击。

1963
来自专栏木子昭的博客

python脚本批量修改文件名前言1.批量添加前缀功能2.(扩展)添加移除前缀功能:

我曾以为,写脚本是很难的,直到我遇到了Python 前言 随着国内版权意识的跟进,很多影视音乐资源开始收费,而且度盘又经常随意封杀各种资源,所以,为了保护资源...

48010
来自专栏架构师之路

DNS在架构设计中的巧用

一、缘起 一个http请求从客户端到服务端,整个执行流程是怎么样的呢? ? 一个典型流程如上: (1)客户端通过域名daojia.com请求dns-serve...

3864
来自专栏领域驱动设计DDD实战进阶

领域驱动设计之聚合与聚合根实例二

3405
来自专栏木可大大

【福利】百度云2018最新限速破解软件

我想大家都曾为百度云的龟速而咬牙切齿,本期就为大家带来百度云2018最新限速破解软件。

5449
来自专栏性能与架构

使用内存数据库Redis做页面静态化

image.png 适用于被高频访问的、页面内容常需要更新的情况 例如首页,特点: 访问量很大 需要展示的内容很多,需要多次的数据库查询,数据库压力大 ...

3014
来自专栏游戏杂谈

as3中ProgressEvent的bytesTotal始终为0

遇到很奇怪的问题,as3中监听资源下载的PROGRESS事件(ProgressEvent.PROGRESS),它的bytesLoaded属性倒是正常的,但byt...

1241
来自专栏WeTest质量开放平台团队的专栏

微信支付异常性能测试

原文链接:https://wetest.qq.com/lab/view/426.html

1842

扫码关注云+社区

领取腾讯云代金券