百万级消息推送 Redis 性能排查
You are here:架构&实践 -性能和可伸缩性Frank2015/02/22阅读: 503评论: 0收藏: 0
服务性能 Redis
最近查看消息推送的监控信息，日推送量到百万，但是随之而来的是 TP99 搞到 5秒，详细对日志打了埋点，监控其瓶颈，最终定位是 Redis 的性能问题。但是令人疑惑的是，对比了其他应用系统 Redis 的性能，日吞吐量亿次的 TP99 才 5~10ms，故猜测一定是应用问题导致了 Redis 的性能下降！查看了应用服务器的网络 IO，发现网络吞吐量异常的汹涌！查看了 Redis 服务器的配置参数，...最近查看消息推送的监控信息，日推送量到百万，但是随之而来的是 TP99 搞到 5秒，详细对日志打了埋点，监控其瓶颈，最终定位是 Redis 的性能问题。
但是令人疑惑的是，对比了其他应用系统 Redis 的性能，日吞吐量亿次的 TP99 才 5~10ms，故猜测一定是应用问题导致了 Redis 的性能下降！
查看了应用服务器的网络 IO，发现网络吞吐量异常的汹涌！
查看了 Redis 服务器的配置参数，发现 Redis 内存占用 7G+，Key键值对 1200万+，Reids 的使用可见一斑！但这并不能直接影响 Redis 的性能下降！
于是，我们又查看了 Redis 的 Showlog，终于发现详细，Redis 被大量的调用 SMEMBERS 命令，而每次调用几乎耗时 5s+。
SMEMBERS 命令是从一个 Set 结构获取集合，但这个集合数据量已经很大，当这个结合被频繁的调用，会极大的占用网络 IO，当网络被占满时，其余的操作也变得慢下来！
同时，查看了 Redis 的连接情况，发现连接数 1000 左右，保持的比较高，又重新查看 Redis 的配置文件！
配置文件中 timeout = 0，这表明 Redis 默认不会断开客户端的连接，这造成的问题：已经无效的连接会造成网络 IO 的浪费！
这次问题排查的反思，跟之前 502 有些相似，都是隐藏极深的问题导致的，问题不再是赤裸裸的暴露出来，而是蒙上了一层面纱！
转载请并标注:
“本文转载自 http://www.linkedkeeper.com/detail/blog.action?bid=37 (文／Frank)”