shuxiaohua的博客

618大促前，运维对系统做巡检时发现redis cpu利用率白天基本保持在72%左右，夜里也在60%以上。担心618流量比平时大，导致redis超负荷，因此找开发进行优化，降低redis的负载。

通过执行monitor命令，可将客户机更改为监视器，实时打印出 Redis 服务器接收到的命令。可以通过这个命令去捕获意料之外的命令是从哪里发过来的。格式:sec.usec [db_id 客户端ip:端口] 命令及参数。如果想导出到文件中进行分析，可以使用。

项目组准备将自建的redis切到公司云平台的redis服务；自建的redis用的是哨兵模式，而云平台的提供的redis服务用的是集群模式。切换前先分析redis用到了那些功能，redis集群模式下是否兼容。分析代码时发现，用到了RedisMessageListenerContainer，该类用于监听redis发出的消息(redis的发布订阅功能)。我们使用到了redis键过期通知的特性，来实现超时处理异步任务的。

空间通知对每个影响redis数据的操作会发送2个不同的事件。例如，针对database 0 中名为 mykey 的键的 DEL 操作将触发两条消息的传递，完全等同于以下两个 PUBLISH 命令。第一种在通道中带有 keyspace 前缀的事件称为 Key-space 通知，而第二种带有 keyevent 前缀的事件称为 Key-event 通知。第一个通道监听所有针对键 mykey 的事件，另一个通道仅监听键 mykey 上的 del 操作事件。可以只启用一种通知，以便只传递我们感兴趣的事件子集。

项目组最近准备将Redis由哨兵模式组网切换到集群组网，切换后应用访问redis时报错，“Pipeline is currently not supported for JedisClusterConnection.”。初步定为Jedis在集群模式下不支持pipeline。org.springframework.data.redis.connection.jedis.JedisClusterConnection#openPipelinepipeline解析pipeline并不是redis的设计，只要

背景接手了一个系统，该使用了HAProxy + Sentinel +redis方案，该方案在redis发生主从切换后，因为应用层启用了连接池，老连接连的仍然是redis的“老主节点”。当应用层获取到这些老连接进行写操作的时候，会抛出异常。org.springframework.data.redis.RedisSystemException: Error in execution; nested exception is io.lettuce.core.RedisCommandExecutionExcep