一、几个疑问?
1.为什么要有客户端上报?
Redis的开发和运维人员,可以通过查看Redis的慢查询了解一些超时的情况,但是我们知道这个慢查询是指命令真正的执行时间,而客户端的调用的数据应该更为重要,其中包含对于客户端的耗时、value大小、异常。运维人员可能不完全清楚,这样对于发现Redis自身问题以及和应用方“撕”(定位问题)很不方便,所以客户端的一些数据无论对于开发人员还是运维人员都是非常有价值的。
2.客户端上报会对客户端性能有消耗?
据统计会有万分之二、三的损耗:一万次调用,会有2~3次比不加统计上报调用时多消耗1~2毫秒,如果不是特别较真,几乎可以忽略不计。
3.是否存在内存泄露?
因为需要在客户端保存一些数据,是否存在内存泄露呢?这个客户端已经在搜狐视频的很多项目中使用接近一年,未发现有问题,而且之前我们也对客户端的数据进行了一些监控,未发现有内存泄露的问题,可以放心使用。
4.客户端上报是否需要使用搜狐提供的jedis?
不需要,可以使用自己的jedis进行测试(jedis 2.7.2以后已测,其他不保证可用)。
5.客户端上报只支持java语言?
是的!由于目前只对java的Redis客户端(jedis)比较熟悉,所以只在java的客户端提供了上报功能,其他语言可以参考下面的总体流程自行实现,有关上报的格式(cachecloud服务端可以解析的格式),如果有需要再提供。
二、总体流程说明(如果想直接使用,可以跳过此步骤):
如上图所示,完成客户端上报需要如下四步:
- 在jedis上做一些”手脚”,对jedis的每个命令产生的耗时、返回value的大小、是否产生异常进行拦截和统计。
- 管理上述数据。(定期清理,维护数据)
- 将指定数据每分钟上报给cachecloud服务端。(使用http的形式)
- cachecloud服务端接收上报数据,保存在mysql中,并绘制成图表。
三、总体效果
1.功能入口
应用方使用了新版客户端(带统计上报功能),点击自己的应用,点击客户端统计按钮就可以查看相应的客户端数据报表。
2.耗时统计:
(1) 应用和客户端的全局耗时统计。
(2) 所有客户端和redis实例对应关系,以及耗时统计。
(3) 耗时统计包含了:平均值、中位值、90%最大值、99%最大值、最大值五个维度。
(4) 命令按照调用量倒排序。
3.值分布统计
按照value的区间,统计了redis过程中io输入流中字符数组的大小作为value的值,帮助用户分析value值是否合理(是否存在大value(如1000k以上))。
4.异常统计
查询客户端和redis实例的异常、客户端上报过程中的异常、redis-cluster存在的异常(由于jedis中对于redis-cluster调用做了特殊处理,所以单独统计。)
四、 使用方法
1. jedis的改造(2.7.2+版本可用,其他未试过)
- jedis统计版本,可以详见:https://github.com/sohutv/jedis-2.8.0-stat,
- 具体修改细节,可以参考https://github.com/sohutv/jedis-2.8.0-stat/commit/0d82201172df25f769ced2786c88a5b928060c13
修改文件入下:
在jedis添加新的pom依赖:cachecloud-open-jedis-stat包含了一些统计的基础类
12345<dependency><groupId>com.sohu.tv</groupId><artifactId>cachecloud-open-jedis-stat</artifactId><version>1.0</version></dependency>Connection.java
Connection是Jedis调用命令的基础类,所以在这里做了一些相应的拦截JedisClusterCommand.java
统计了一下JedisClusterMaxRedirectionsException异常
2. 开启统计功能
细心的朋友应该已经发现,在之前发布的客户端代码中,有一行是注释掉的,那个就是客户端统计的开关,如果想使用在如下类去掉注释即可。
具体类:RedisClusterBuilder、RedisSentinelBuilder、RedisStandaloneBuilder
|
|
修改cachecloud-open-client-redis包中的pom.xml中的jedis版本为你的私有版本
3. 上报
在第2步开启后,会自动上报。
4. 报表
在第2步开启后,会自动出现,详见第二章具体功能
5.添加新的表
以cachecloud源码中的表为准.
|
|
五、 视频
如果对java不太了解,或者配置不太成功,请等待视频教程。
尚未录制
|
|