cluster模块在搬迁场景下，可能出现slots信息不一致的情况

[takenliu]

Description

源节点“x.x.5.243”将一批slot搬迁到目标节点"x.x.3.66"。出现部份slot信息不一致的情况。
比如图中的slot:13312，在源节点“x.x.5.243”看来，它属于目标节点“x.x.3.66”。但是在目标节点“x.x.3.66”看来，它属于源节点“x.x.5.243”。这将导致这些slot的数据无法访问。

在搬迁的场景下，低概率出现。

Expected Behavior

Current Behavior

Possible Solution

Steps to Reproduce (for bugs)

Context

Your Environment

• Operating System and version:
• Machine Specifications:
• Tendis Version:
• Tendis Configuration:
• IO/Network used:
• Link to your project:

[takenliu]

【原因分析：】

源节点在搬迁完之后，就将slot改为目标节点了。

目标节点在搬迁完后，调用setSlots函数，将slot改为目标节点。但是setSlots函数内部，改slots归属，和提升configEpoch，是分别上的锁，没有在统一的一个mutex锁内部做。在这两者中间可能出现slots被改的情况。

具体出错步骤就是：
1.setSlots函数，将slots改为目标节点
2.源节点发送了ping或者pong包到目标节点（在源节点将slot改为目标节点前），此时header里面声称源节点持有这些slots。
如果刚好此时源节点的configEpoch比目标节点的configEpoch要大的话，在目标节点里面，clusterUpdateSlotsConfigWith函数就会将这些slots改为源节点持有。
3.目标节点再提升自己的configEpoch。

如果setSlots函数改为上一个mutex锁保护两个操作的话，就会步骤3先做，步骤2再进来的时候，源节点的configEpoch就会比目标节点的configEpoch要小，从而忽略这个信息。

另外，源节点在搬迁完之后，就直接将slot改为目标节点的做法是否可以？是否应该由目标节点统一改，再将信息同步给源节点？

【出现的场景：】

从分析的结果来看，只要是搬迁，都有一定的概率出现。
出现的前提有两个：
1是源节点的configEpoch比目标节点的configEpoch要大。
2是在setSlots函数中间刚好收到源节点发来的修改slots前的ping包或者pong包。

[takenliu]

【复现方法】
步骤1.在setSlots函数内部，两步之间sleep(1s)或者500ms，增加触发的概率。

步骤2.启动节点A给B搬迁一些slots，然后启动B给C搬迁一些slots。这样B和C的configEpoch会不断交替增大，这样B发送给C给节点的pong包里面，出现B的configEpoch比C的configEpoch大的概率就比较高。因为一个搬迁任务会被拆分为很多小的子任务，可能其中某些子任务就会被这样的ping包或者pong包给错改了。（这里的B节点就是出问题的源节点，C节点就是出问题的目标节点）。比如这样：

name1=`redis-cli -h $ip -p 54000 cluster nodes|grep ":54001"|awk '{print $1}'`; 
redis-cli -h 127.0.0.1 -p 54002 cluster setslot importing $name1 {7000..7099};
sleep 1;
name2=`redis-cli -h $ip -p 54000 cluster nodes|grep ":54002"|awk '{print $1}'`;
redis-cli -h 127.0.0.1 -p 54006 cluster setslot importing $name2 {13000..13099};

如果不是链式搬迁，只是单纯的B搬到C的话，第一个搬迁子任务如果没有触发这个bug的话，C就会提升自己的configEpoch了，之后的子任务结束时，收到B发来的ping和pong，出现configEpoch比C大的概率就较低了。所以链式搬迁更容易复现一些。

在上述两个步骤下，就很容易复现了。

复现的目标节点日志：

目标节点先把13004设给了自己，然后源节点发来的pong信息里面声称拥有13004节点，且confEpoch8大于自己的5，于是又将13004改成了源节点拥有。