Redis集群的数据一致性

Redis集群的数据一致性

Redis将键空间分为了16384个slot，然后通过如下算法

HASH_SLOT = CRC16(key) mod 16384

计算出每个key所属的slot。客户端可以请求任意一个节点，每个节点中都会保存所有16384个slot对应到哪一个节点的信息。如果一个key所属的slot正好由被请求的节点提供服务，则直接处理并返回结果，否则返回MOVED重定向信息，如下：

GET key
一MOVED slot IP:PORT

由-MOVED开头，接着是该key计算出的slot，然后是该slot对应到的节点IP和Port。客户端应该处理该重定向信息，并且向拥有该key的节点发起请求。实际应用中，Redis客户端可以通过向集群请求slot和节点的映射关系并缓存，然后通过本地计算要操作的key所属的slot，查询映射关系，直接向正确的节点发起请求，这样可以获得几乎等价于单节点部署的性能。

Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。
Reds 集群（虚拟hash solt的概念）有16384个虚拟的哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽。这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。
使用哈希槽的好处就在于可以方便的添加或移除节点。
当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；
当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；
在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务

Redis 并不能保证数据的强一致性

看下图

3、Redis集群的主从架构：
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品。
例如有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少B节点所承担的哈希槽这个范围的槽而不可用.默认情况的整个集群也是不能使用的，不过我们可以改
cluster-require-full-coverage

当cluster-require-full-coverage为no时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用
4.redis集群工作原理
https://cloud.tencent.com/developer/article/1444057
https://juejin.im/post/6844903548853944328
参考
Redis 集群教程
http://www.redis.cn/topics/cluster-tutorial.html