redis cluster

redis cluster

redis cluster特性

1. 对于每一个节点，都需要配置master，slave。当master down掉的时候，其它仍然alive的节点会promote slave节点作为master节点。关于节点的功能还有auto-discover other nodes, detect non-working nodes
2. 2.

关于configEpoch

感觉configEpoch是类似于一个版本号的东西，是关于cluster slot的一个版本号。一般来说，每一个master节点的configEpoch都是不同的（假如存在相同的configEpoch，会有冲突处理算法来保证每个节点的configEpoch不同），并且每一个节点的configEpoch不会轻易发生改变（节点改变的情况见下面）。由于configEpoch是单调递增的，因此当某一个节点的configEpoch改变之后，其它节点就会更新对该节点所声称拥有的slots的认识。

关于currentEpoch

configEpoch只是关于slots分布的一个版本号，而currentEpoch才是真正的逻辑时钟。通过gossip协议，集群中的currentEpoch总是一致的（当然，特殊情况除外，如网络分区发生等）。currentEpoch越高，代表节点的配置或者操作越新。

redis cluster中得逻辑时间

• configEpoch : configEpoch should be generate by concensus and should be unique across the cluster(configEpoch可以看做是一个逻辑时间戳)
• currentEpoch

configEpoch的变化

1. 在集群初始化的时候，通过读取配置文件nodes.conf中的configEpoch值，对每一个节点的configEpoch进行赋值
2. 集群重置(resetCluster)时，configEpoch被置为0
3. 当一个槽迁移到某一个节点之后，尤其是集群发生resharding的时候；当发生failover force时，节点的configEpoch会被置为currentEpoch + 1（原因未清楚）
4. 若两个节点的configEpoch相同，并且当前节点的nodename更大，则当前节点的configEpoch=currentEpoch+1（configEpoch发生冲突时的处理）
5. 当master发生fail的之后，slave获得大多数master的投票时，设置slave的configEpoch为failover_auth_epoch
6. cluster set-config-epoch命令强制设置configEpoch
7. 当接受到其它节点发来的gossip消息的时候，设置configEpoch为消息中得configEpoch

投票的条件

1. 发起投票的节点必须是slave节点，并且它的master节点已经down掉
2. 发起投票节点的currentEpoch不低于投票节点的currentEpoch
3. slave节点的configEpoch不低于投票节点特定slots的configEpoch（这些特定slots是指投票节点知道的down掉得master节点所拥有的slots）

注意事项

• 在retarding过程中，设计多个key的操作可能失败。
• 任意一个节点都可以接受客户端请求，但是假如请求的key不在本节点，会发送一个MOVE