上篇文章枚举了诸多互联网公司分享的应用redis cluster中遇到的问题，本文罗列所在公司上线后出现的一些问题，也包括一些小的困惑。
问题1：出现auto failover
现象：监控redis半个多月的时候，偶然发现其中1台master自动触发failover。
原因：
1.1 查看出现的时间点的日志：
Node 912a1efa1f4085b4b7333706e546f64d16580761 reported node 3892d1dfa68d9976ce44b19e532d9c0e80a0357d as not reachable.
从日志看到node not reachable，首先想到2个因素：
（1）redis是单进程和单线程，所以有任何一个耗时操作都会导致阻塞时间过长，最终导致failover.
（2）网络因素；
首先排除了可能原因(1)，因为从系统应用分析，并无任何特殊操作。都是最普通的操作且请求量很小，可能原因(2)不能排除。
1.2 查看出现问题时间点的系统资源应用情况：
查看了所有的常见指标，除了最近1分钟的load异常外，均正常，锁定原因为：系统load过高，达到7，导致系统僵死。其他节点认为这个节点挂了。
解决：考虑到所有其他指标：cpu/memory/disk等都正常，以及其他2台master一直也正常，业务量非常小，这种情况偶发，所以归结问题原因是这台虚拟机有问题，所以反馈问题并迁移虚拟机，迁移后system load一直平稳无问题。也没有出现failover.
困惑2：slave的ops远小于master的ops
现象：已知所有操作都是删除操作，并无查询操作。所以很好奇，为什么master和slave的ops差别这么大：前3台为master，达到100ops,相反slave不到10.
解惑：CRUD中，不见得只要是CUD就肯定会“传播”命令到slave，还有一个条件是必须“库”发生了改变。例如当前的业务中，处于测试阶段，所有主流操作都是删除操作，而且这些删除操作都是删除一个没有key的操作。所以并没有发生改变（即下文中dirty为0）。
计算dirty值：
/* Call the command. */
c->flags &= ~(REDIS_FORCE_AOF|REDIS_FORCE_REPL);
// 保留旧 dirty 计数器值
dirty = server.dirty;
// 计算命令开始执行的时间
start = ustime();
// 执行实现函数
c->cmd->proc(c);
// 计算命令执行耗费的时间
duration = ustime()-start;
// 计算命令执行之后的 dirty 值
dirty = server.dirty-dirty;
只有dirty值发生改变：
// 如果数据库有被修改,即判断dirty，那么启用 REPL 和 AOF 传播
if (dirty)
flags |= (REDIS_PROPAGATE_REPL | REDIS_PROPAGATE_AOF);
if (flags != REDIS_PROPAGATE_NONE)
propagate(c->cmd,c->db->id,c->argv,c->argc,flags);
所有的操作，不见得都会改变dirty值：
void delCommand(redisClient *c) {
int deleted = 0, j;
for (j = 1; j < c->argc; j++) {
// 尝试删除键
if (dbDelete(c->db,c->argv[j])) {
//改变server.dirty
server.dirty++;
}
}
}
问题3：socket timeout
现象：查看最近1周数据访问量，有4个socket timeout错误：
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out at redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202) at redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40) at redis.clients.jedis.Protocol.process(Protocol.java:151) at redis.clients.jedis.Protocol.read(Protocol.java:215) at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340) at redis.clients.jedis.Connection.getIntegerReply(Connection.java:265) at redis.clients.jedis.Jedis.del(Jedis.java:197) at redis.clients.jedis.JedisCluster$110.execute(JedisCluster.java:1205) at redis.clients.jedis.JedisCluster$110.execute(JedisCluster.java:1202) at redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:120) at redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:31) at redis.clients.jedis.JedisCluster.del(JedisCluster.java:1207) at com.webex.dsagent.client.redis.RedisClientImpl.deleteSelectedTelephonyPoolsInfo(RedisClientImpl.java:77) at sun.reflect.GeneratedMethodAccessor75.invoke(Unknown Source)
配置： connectionTimeout=800 soTimeout=1000 BTW: 确实消耗了>1000ms componentType":"Redis","totalDurationInMS":1163
原因： 查看4个错误发生的时间，都发生在某天的一个时间点，且用key计算分段，也处于同一个机器上，所以归结到网络原因或虚拟机问题，无法重现。