redis cluster

redis cluster特性

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

关于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不在本节点，会发送一个MOVED相应。并且，应该客户端来缓存key->node的对应关系。

写数据丢失的可能行

1. master接受写请求后，在没有将新数据同步到slave之前，master down掉，这部分数据丢失。（这跟单机的情况一样）
2. master由于网络分区而被slave failover，slave成为了master，然后网络分区消失，原来的master又重新与集群连接上了（这是原来的master的configuration仍然是master）。假如client将写请求发送给这个master，写请求会被接受，但是会丢失。原因在于很快，现在的master会将原来的master降级为slave。
3. 另外，假如网络分区发生后，并且很长一段时间没有恢复，那么在NODE_TIMEOUT时间内发送给minority分区中得master的写也会丢失。因为在分区发生后的NODE_TIMEOUT时间内fail detection不会检查出有节点unreachable，写请求仍可接受。在NODE_TIMEOUT时间后，fail detection检查到有节点unreachable，就不接受写请求了。

redis cluster specification上的话

Very high performance and scalability while preserving weak but reasonable forms of data safety and availability is the main goal of Redis Cluster.

如何避免gossip消息成指数级增长

注：这里的指数增长主要是指节点数跟gossip消息数的关系。

1. 每10个clusterCron（约1s）可能会随机挑选一个节点发送ping
2. 在接收到节点的pong消息(node_timeout / 2)s后回给该节点发送一个ping消息
3. 每接受到一个ping消息，回复一个pong消息。

因此，正常情况下一个node_timeout时间内，一个节点可以跟另外的节点交换至少4个包（大家互相ping一次，互相pong一次）。那么集群中总共发送的数据包是$$\dfrac{(N + 1) * N * 4}{2} = (N + 1) * N * 2$$增长率是$$2 * (2 * N + 1) = 4 * N + 2$$

从数字上来看，这gossip包得数量还是很惊人的；指数的gossip是多少？

根据实际测试，使用create-cluster脚本创建的集群，大概每10每个节点会发送100个包（默认的node_timeout是15s）。在数量级上跟上述列出的公式是一致的。个人觉得redis cluster在gossip协议上还是有优化的空间的，怎么样在保证及时性和准确性的情况下减少gossip协议的消息数量