背景
业务所用redis为一主五从的读写分离架构企业架构，承担了访问量高达73万的QPS，主要是热key访问量过大导致，由于还需上线新的业务，但是redis的cpu高达100%，已满负荷运行，在进行优化时，对代理开启了query_cache。反而响应延迟变高，导致性能下降
运维与使用
设置方法与参数说明
参数 | 说明 |
query_cache_enabled | 是否启用代理查询缓存功能，取值：0：不启用，默认值。1：启用。注意 由于代理节点中缓存的热点Key的查询结果在有效时间内不会更新，在启用该功能前，您需要确认业务上是否允许数据在缓存有效时间内的 最终一致性 。 |
query_cache_mode | 代理查询缓存的工作模式，取值：0：只缓存数据分片推送的热点Key的查询结果，默认值。1：缓存所有Key的查询结果并进行根据最近最少使用算法LRU（Least Recently Used）进行淘汰。注意 由于代理节点的缓存空间有限（代理节点每个线程100 MB），如果设置该参数的值为1，代理节点将按照LRU算法进行淘汰，可能降低缓存的命中率，从而引起整体性能的下降。 |
query_cache_expire | 缓存数据的有效时间，单位为毫秒，取值：100~60000，默认值为1000。如果缓存的数据在有效期内被修改，修改后的数据不会同步至缓存中，即相同的读请求会获取到缓存中的脏数据，直至缓存失效。您需要根据具体的业务场景和对脏数据的容忍度谨慎评估该参数的值，该值设置过小会降低缓存的命中率，设置过大会导致客户端在较长的时间内读取到的是脏数据。。 |
使用
查询缓存的key
querycache keys：获取代理节点中已缓存的所有热点Key
返回实例
1) 1) (integer) 0
2) "key:000000000003"
2) 1) (integer) 0
2) "key:000000000001"
3) 1) (integer) 0
2) "key:000000000002"
4) 1) (integer) 0
2) "key:000000000000"
返回示例说明
每个热点Key的信息由两行信息组成，含义如下：
数据库名。
Key名称。获取缓存情况
返回实例
1) "put_qps:4.00"
2) "get_qps:16570.00"
3) "hit_rate:99.98"
4) "memory_size:180"
5) "query_count:4"
返回示例说明
put_qps：数据节点每秒往query_cache写入的次数。
get_qps：客户端每秒从query_cache中读取的次数。
hit_rate：缓存的命中率。
memory_size：缓存数据占用的内存容量，单位为字节。
query_count：已缓存的请求的数量。获取缓存的请求命令
返回示例
1) 1) (integer) 0
2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000000\r\n"
3) (integer) 668
2) 1) (integer) 0
2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000001\r\n"
3) (integer) 668
3) 1) (integer) 0
2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000003\r\n"
3) (integer) 668
4) 1) (integer) 0
2) "*2\r\n$3\r\nGET\r\n$16\r\nkey:000000000002\r\n"
3) (integer) 667
返回示例说明
每个请求命令的信息由三行信息组成，含义如下：
数据库名。
请求命令的完整内容，格式遵照Redis协议规范。
剩余生存时间，单位为毫秒。问题排查
现象
响应时间明显变大，QPS也有所下降
排查
1、开启代理缓存后，代理的部门节点出现了cpu飙高的情况，但是QPS出现了下降，没有过于的关注耗时，查看proxy的代理请求出现了下降的趋势，以为是缓存功能正常
2、业务这边反馈他们有部分接口，出现了耗时变长，结合proxy的耗时，的确相比以前出现了耗时变高的情况，初步怀疑是proxy性能问题，并对起进行抓包，发现热key的访问都是getbit key offset命令，基本就排查出原因了，proxy缓存的是命令的值，并不是key的值，proxy的缓存每次都没有命中，反而加重了proxy的负载
总结
proxy使用注意
- proxy只是对命令值缓存，不能对key整个值进行缓存
- 对于写较为频繁，不建议使用proxy的cache
- 不要开启全量key的缓存功能，建议只是对热key进行缓存