Redis Cluster:Too many Cluster redirections异常

一、现象：

    我们的redis私有云，对外提供了redis-standalone, redis-sentinel, redis-cluster三种类型的redis服务。

    其中redis-cluster, 使用的版本是 Redis Cluster 3.0.2, 客户端是jedis 2.7.2。

    有人在使用时候，业务的日志中发现了一些异常（Too many Cluster redirections）。 

    
 

二、jedis源码分析：

    先从jedis源码中找到这个异常，这段异常是在JedisClusterCommand类中

Java代码  

1. if (redirections <= 0) {  
2.        throw new JedisClusterMaxRedirectionsException("Too many Cluster redirections? key=" + key);  
3. }  

    在jedis中调用redis-cluster使用的JedisCluster类，所有api的调用方式类似如下：

Java代码  

1. public String set(final String key, final String value) {  
2.      return new JedisClusterCommand(connectionHandler, maxRedirections) {  
3.          @Override  
4.          public String execute(Jedis connection) {  
5.              return connection.set(key, value);  
6.          }  
7.      }.run(key);  
8.  }  

     

    所以重点代码在JedisClusterCommand这个类里，重要代码如下：

Java代码  

1. public T run(int keyCount, String... keys) {  
2.     if (keys == null || keys.length == 0) {  
3.         throw new JedisClusterException("No way to dispatch this command to Redis Cluster.");  
4.     }  
5.     if (keys.length > 1) {  
6.         int slot = JedisClusterCRC16.getSlot(keys[0]);  
7.         for (int i = 1; i < keyCount; i++) {  
8.             int nextSlot = JedisClusterCRC16.getSlot(keys[i]);  
9.             if (slot != nextSlot) {  
10.                 throw new JedisClusterException("No way to dispatch this command to Redis Cluster "  
11.                         + "because keys have different slots.");  
12.             }  
13.         }  
14.     }  
15.   
16.     return runWithRetries(SafeEncoder.encode(keys[0]), this.redirections, false, false);  
17. }  
18.   
19. private T runWithRetries(byte[] key, int redirections, boolean tryRandomNode, boolean asking) {  
20.     if (redirections <= 0) {  
21.         JedisClusterMaxRedirectionsException exception = new JedisClusterMaxRedirectionsException(  
22.                 "Too many Cluster redirections? key=" + SafeEncoder.encode(key));  
23.         throw exception;  
24.     }  
25.   
26.     Jedis connection = null;  
27.     try {  
28.         if (asking) {  
29.             // TODO: Pipeline asking with the original command to make it  
30.             // faster....  
31.             connection = askConnection.get();  
32.             connection.asking();  
33.   
34.             // if asking success, reset asking flag  
35.             asking = false;  
36.         } else {  
37.             if (tryRandomNode) {  
38.                 connection = connectionHandler.getConnection();  
39.             } else {  
40.                 connection = connectionHandler.getConnectionFromSlot(JedisClusterCRC16.getSlot(key));  
41.             }  
42.         }  
43.   
44.         return execute(connection);  
45.     } catch (JedisConnectionException jce) {  
46.         if (tryRandomNode) {  
47.             // maybe all connection is down  
48.             throw jce;  
49.         }  
50.   
51.         // release current connection before recursion  
52.         releaseConnection(connection);  
53.         connection = null;  
54.   
55.         // retry with random connection  
56.         return runWithRetries(key, redirections - 1, true, asking);  
57.     } catch (JedisRedirectionException jre) {  
58.         // if MOVED redirection occurred,  
59.         if (jre instanceof JedisMovedDataException) {  
60.             // it rebuilds cluster's slot cache  
61.             // recommended by Redis cluster specification  
62.             this.connectionHandler.renewSlotCache(connection);  
63.         }  
64.   
65.         // release current connection before recursion or renewing  
66.         releaseConnection(connection);  
67.         connection = null;  
68.   
69.         if (jre instanceof JedisAskDataException) {  
70.             asking = true;  
71.             askConnection.set(this.connectionHandler.getConnectionFromNode(jre.getTargetNode()));  
72.         } else if (jre instanceof JedisMovedDataException) {  
73.         } else {  
74.             throw new JedisClusterException(jre);  
75.         }  
76.   
77.         return runWithRetries(key, redirections - 1, false, asking);  
78.     } finally {  
79.         releaseConnection(connection);  
80.     }  
81. }  

       

     代码解释：

     1. 所有jedis.set这样的调用，都用JedisClusterCommand包装起来（模板方法）

     2. 如果操作的是多个不同的key, 会抛出如下异常，因为redis-cluster不支持key的批量操作（可以通过其他方法解决，以后会介绍）：

Java代码  

1. throw new JedisClusterException("No way to dispatch this command to Redis Cluster because keys have different slots.");  

     3. 参数解释

Java代码  

1. private T runWithRetries(byte[] key, int redirections, boolean tryRandomNode, boolean asking) {  

   (1) key: 不多说了

   (2) redirections: 节点调转次数（实际可以看做是重试次数）

   (3) tryRandomNode: 是否从redis cluster随机选一个节点进行操作

   (4) asking: 是否发生了asking问题

    4. 逻辑说明：

    正常逻辑：

    (1) asking = true: 获取asking对应的jedis, 然后用这个jedis操作。

    (2) tryRandomNode= true： 从jedis连接池随机获取一个可用的jedis, 然后用这个jedis操作。

    (3) 都不是：直接用key->slot->jedis，直接找到key对应的jedis, 然后用这个jedis操作。

    异常逻辑：

    (1) JedisConnectionException： 连接出了问题，连接断了、超时等等，tryRandomNode= true，递归调用本函数

    (2) JedisRedirectionException分两种：

         ---JedisMovedDataException： 节点迁移了，重新renew本地slot对redis节点的对应Map

         ---JedisAskDataException： 数据迁移，发生asking问题, 获取asking的Jedis

   此过程最多循环redirections次。

   异常含义：试了redirections次（上述），仍然没有完成redis操作。

三、原因猜测：

     1. 超时比较多，默认超时时间是2秒。

       (1). 网络原因：比如是否存在跨机房、网络割接等等。

       (2). 慢查询，因为redis是单线程，如果有慢查询的话，会阻塞住之后的操作。 

       (3). value值过大？

       (4). aof 重写/rdb fork发生？

    2. 节点之间关系发生变化，会发生JedisMovedDataException

    3. 数据在节点之间迁移，会发生JedisAskDataException

 

 四、定位方法：

 看了一下redis的日志第三节中的2,3并未发生，应该是超时的情况。

 异常发生在2015-10-19 04:34:30左右，给出如下异常key值

Java代码  

1. key=v11Pay|huid|wlunm99_561555097  
2. key=play_anchorroom_info_529460  
3. key=v11Pay|huid|qq-qhncnxujax  
4. key=play_anchor_info_qq-luzvfcftnf  
5. key=play_anchor_info_qq-luzvfcftnf  
6. key=play_anchorroom_info_550649  
7.  key=play_anchor_info_qq-cfrkukhdsd  
8. key=play_anchor_info_qq-rbufgcqbvk      

 经过查询，这些key都同时定位在一个redis实例上，于是看了一下这个redis实例的日志（与异常时间点对应），发现如下：AOF fsync发生了异常，以经验看是本地IO使用较大造成的。

Java代码  

1. 17932:M 19 Oct 04:35:30.010 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.  
2. 17932:M 19 Oct 04:35:41.087 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.  
3. 17932:M 19 Oct 04:35:47.044 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.  
4. 17932:M 19 Oct 10:15:51.463 * Starting automatic rewriting of AOF on 1795% growth  

看了一下tsar的历史记录：tsar --io -n 2 | head -200

Java代码  

1. Time            rrqms   wrqms      rs      ws   rsecs   wsecs  rqsize  qusize   await   svctm    util  
2. 19/10/15-04:00   0.00  164.08    0.01   34.52    0.04  745.15   21.58    0.00   25.30    4.13   14.26  
3. 19/10/15-04:05  40.38    1.1K  218.49   78.39   13.9K    4.9K   64.55    7.00   24.63    2.80   83.19  
4. 19/10/15-04:10  37.15    1.0K  360.58   71.91   13.4K    4.3K   42.04    6.00   14.67    1.70   73.34  
5. 19/10/15-04:15   1.99    1.5K   21.98  115.38  588.69    6.6K   53.12    5.00   39.86    1.98   27.14  
6. 19/10/15-04:20  40.17    1.0K  278.00   76.79   10.4K    4.2K   42.32    4.00   11.48    1.60   56.85  
7. 19/10/15-04:25  78.28  861.13  381.34   62.33   14.3K    3.6K   41.40    4.00    9.85    1.51   66.78  
8. 19/10/15-04:30  81.64  913.85  402.37   55.35   15.1K    3.8K   42.18    4.00    9.47    1.41   64.71  
9. 19/10/15-04:35  21.92  888.72  145.97   58.00   16.2K    3.7K   99.71    4.00   20.57    3.63   74.04  
10. 19/10/15-04:40  39.72  474.01  169.01   48.26   14.3K    2.0K   77.09    3.00   17.83    4.14   89.89  
11. 19/10/15-04:45  47.02  537.60  149.41   41.50   16.7K    2.3K  101.55    3.00   18.27    4.21   80.35  

于是发现从4点开始IO开销一直增大，以经验看应该是有定时任务（都是托管的机器，上面还有别人的应用），于是发现了如下，是一个nginx合并的脚本，本地IO开销较大。

Java代码  

1. 00 04 * * * sh /opt/script/logcron.sh  
2. 00 04 * * * sh /opt/script/logremove.sh  

五、解决方法：

(1) 和使用方沟通一下，他们完全把redis当做memcache用，也就是允许断电后数据丢失，重新从数据源获取数据写到缓存，因此关闭了aof配置（此方法不治本）

(2) 定时脚本下线或者优化。（最终采用此方法）