redis cluster
redis cluster特性
- 对于每一个节点,都需要配置master,slave。当master down掉的时候,其它仍然alive的节点会promote slave节点作为master节点。关于节点的功能还有
auto-discover other nodes, detect non-working nodes
- 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的变化
- 在集群初始化的时候,通过读取配置文件nodes.conf中的configEpoch值,对每一个节点的configEpoch进行赋值
- 集群重置(resetCluster)时,configEpoch被置为0
- 当一个槽迁移到某一个节点之后,尤其是集群发生resharding的时候;当发生failover force时,节点的configEpoch会被置为currentEpoch + 1(原因未清楚)
- 若两个节点的configEpoch相同,并且当前节点的nodename更大,则当前节点的configEpoch=currentEpoch+1(configEpoch发生冲突时的处理)
- 当master发生fail的之后,slave获得大多数master的投票时,设置slave的configEpoch为failover_auth_epoch
- cluster set-config-epoch命令强制设置configEpoch
- 当接受到其它节点发来的gossip消息的时候,设置configEpoch为消息中得configEpoch
投票的条件
- 发起投票的节点必须是slave节点,并且它的master节点已经down掉
- 发起投票节点的currentEpoch不低于投票节点的currentEpoch
- slave节点的configEpoch不低于投票节点特定slots的configEpoch(这些特定slots是指投票节点知道的down掉得master节点所拥有的slots)
注意事项
- 在retarding过程中,设计多个key的操作可能失败。
- 任意一个节点都可以接受客户端请求,但是假如请求的key不在本节点,会发送一个MOVE