RedisCluster 是 Redis 的亲儿子，它是 Redis 作者自己提供的 Redis 集群化方案。
数据分区方式
哈希节点数取余
是在客户端分片。优点简单。缺点：扩容影响太大！添加节点的时候整个数据会做很多偏移。3个节点扩容添加1个节点，会发生80%的数据迁移。如果用这个中方式做数据分布，扩容的时候建议使用多倍扩容。比如3个节点，扩容的时候，再添加3个节点，这样只会发生50%的数据迁移。不建议使用这种古老的数据分布方式。
一致性hash
数据做成token环，为每一个节点分配一个token，key做了hash后会落在两个node2之间，顺时针找离它最近的节点。是在客户端分片。节点比较多的时候建议使用这种方式。节点伸缩的时候只影响临近的节点，还是要使用多倍扩容，不然会数据倾斜。
虚拟槽分区
这就是redis cluster使用的数据分布方式。预设虚拟槽：每个槽映射一个数据子集，一般比节点数大。由服务端管理节点、槽、数据的关系。由服务端管理节点、槽、数据的关系。
原生命令安装
Cluster中每个节点都知道其他节点的信息，相互间可以通信(meet)，知道每个节点负责哪些槽(slot)。16384是redis Cluster指定的槽的数量。要为每个节点指派槽，才能正常读写。redis Cluster有主从复制，每个主节点都有从节点，高可用，分片。从节点默认不支持读写，如果要对从节点做读写分离需要每个连接用readonly，自己维护从节点的资源池和故障转移。不建议在从节点做读，直接扩容操作各个主节点。
配置开启节点 4台机器
cd /app/redis/config
touch redis-cluster-6379.conf
vi redis-cluster-6379.conf
protected-mode no
port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "6379.log"
dir /app/redis/data
dbfilename "dump-6379.rdb"
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-require-full-coverage no
启动4个节点
cd /app/redis/src
./redis-server /app/redis/config/redis-cluster-6379.conf
meet
各节点之间相互meet建立通信
在node1中进行
cd /app/redis/src
./redis-cli -h node1 -p 6379 cluster meet 192.168.2.104 6379
./redis-cli -h node1 -p 6379 cluster meet 192.168.2.106 6379
./redis-cli -h node1 -p 6379 cluster meet 192.168.2.107 6379
这样其他节点会自动建立连接。
指派槽
node1和node3是master，由他们两个平分16384个槽
node1 0-8191
node2 8192-16384
node1上执行
./redis-cli -h node1 -p 6379 cluster addslots {0…8191}
node3上执行
./redis-cli -h node3 -p 6379 cluster addslots {8192…16383}
主从分配
node2 slaveof node1 ，node4 slaveof node3
集群中输入命令cluster nodes查看每个节点的ID，这个ID在分配主从的时候要用
在node2上执行 那一串很长的是node1的nodeid
./redis-cli -p 6379 cluster replicate 4be5d22323fbb080172ffdeb0885f7caacc45dbd
在node4上执行 那一串很长的是node3的nodeid
./redis-cli -p 6379 cluster replicate 6500b5a2ed52ffc05a5d81ee57ecca4282e5cf5e
配置完以后再在集群中输入cluster nodes查看节点信息
./redis-cli -p 6379 cluster nodes
集群中可以输入命令cluster info查看集群信息。
cluster slots可以看到槽的分配信息。
cluster keyslot key可以查看key属于哪个槽
官方工具安装
1.首先每台机器要准备ruby的环境。
2.安装rubygem redis
3.安装redis-trib.rb
拓扑结构
一个Redis Cluster由多个Redis节点组成。不同的节点组服务的数据无交集，每个节点对应数据sharding的一个分片。节点组内部分为主备2类，对应前面叙述的master和slave。两者数据准实时一致，通过异步化的主备复制机制保证。一个节点组有且仅有一个master，同时有0到多个slave。只有master对外提供写服务，读服务可由master/slave提供。如下所示：
上图中，key-value全集被分成了5份，5个slot（实际上Redis Cluster有 16384 [0-16383] 个slot，每个节点服务一段区间的slot，这里面仅仅举例）。A和B为master节点，对外提供写服务。分别负责1/2/3和4/5的slot。A/A1和B/B1/B2之间通过主备复制的方式同步数据。
上述的5个节点，两两通过Redis Cluster Bus交互，相互交换如下的信息：
- 数据分片（slot）和节点的对应关系；
- 集群中每个节点可用状态；
- 集群结构发生变更时，通过一定的协议对配置信息达成一致。数据分片的迁移、主备切换、单点master的发现和其发生主备关系变更等，都会导致集群结构变化。
- publish/subscribe（发布订阅）功能，在Cluster版内部实现所需要交互的信息。
Redis Cluster Bus通过单独的端口进行连接，由于Bus是节点间的内部通信机制，交互的是字节序列化信息。相对Client的字符序列化来说，效率较高。
Redis Cluster是一个去中心化的分布式实现方案，客户端和集群中任一节点连接，然后通过后面的交互流程，逐渐的得到全局的数据分片映射关系。
配置的一致性
对于去中心化的实现，集群的拓扑结构并不保存在单独的配置节点上，后者的引入同样会带来新的一致性问题。那么孤立的节点间，如何对集群的拓扑达成一致，是Redis Cluster配置机制要解决的问题。Redis Cluster通过引入2个自增的Epoch变量，来使得集群配置在各个节点间最终达成一致。
配置信息数据结构
Redis Cluster中的每个节点都保存了集群的配置信息，并且存储在clusterState中，结构如下：
上图的各个变量语义如下:
- clusterState 记录了从集群中某个节点视角，来看集群配置状态；
- currentEpoch 表示整个集群中最大的版本号，集群信息每变更一次，改版本号都会自增。
- nodes 是一个列表，包含了本节点所感知的，集群所有节点的信息（clusterNode），也包含自身的信息。
- clusterNode 记录了每个节点的信息，其中包含了节点本身的版本 Epoch；自身的信息描述：节点对应的数据分片范围（slot）、为master时的slave列表、为slave时的master等。
每个节点包含一个全局唯一的NodeId。
当集群的数据分片信息发生变更（数据在节点间迁移时），Redis Cluster 仍然保持对外服务。
当集群中某个master出现宕机时，Redis Cluster 会自动发现，并触发故障转移的操作。会将master的某个slave晋升为新的 master。
由此可见，每个节点都保存着Node视角的集群结构。它描述了数据的分片方式，节点主备关系，并通过Epoch 作为版本号实现集群结构信息的一致性，同时也控制着数据迁移和故障转移的过程。
信息交互
去中心化的架构不存在统一的配置中心。在Redis Cluster中，这个配置信息交互通过Redis Cluster Bus来完成（独立端口）。Redis Cluster Bus 上交互的信息结构如下：
clusterMsg 中的type指明了消息的类型，配置信息的一致性主要依靠PING/PONG。每个节点向其他节点频繁的周期性的发送PING/PONG消息。对于消息体中的Gossip部分，包含了sender/receiver 所感知的其他节点信息，接受者根据这些Gossip 跟新对集群的认识。
对于大规模的集群，如果每次PING/PONG 都携带着所有节点的信息，则网络开销会很大。此时Redis Cluster 在每次PING/PONG，只包含了随机的一部分节点信息。由于交互比较频繁，短时间的几次交互之后，集群的状态也会达成一致。
一致性的达成
当Cluster 结构不发生变化时，各个节点通过gossip 协议在几轮交互之后，便可以得知Cluster的结构信息，达到一致性的状态。但是当集群结构发生变化时（故障转移/分片迁移等），优先得知变更的节点通过Epoch变量，将自己的最新信息扩散到Cluster，并最终达到一致。
- clusterNode 的Epoch描述的单个节点的信息版本；
- clusterState 的currentEpoch 描述的是集群信息的版本，它可以辅助Epoch 的自增生成。因为currentEpoch 是维护在每个节点上的，在集群结构发生变更时，Cluster 在一定的时间窗口控制更新规则，来保证每个节点的currentEpoch都是最新的。
更新规则如下：
- 当某个节点率先知道了变更时，将自身的currentEpoch 自增，并使之成为集群中的最大值。再用自增后的currentEpoch 作为新的Epoch 版本；
- 当某个节点收到了比自己大的currentEpoch时，更新自己的currentEpoch；
- 当收到的Redis Cluster Bus 消息中的某个节点的Epoch > 自身的时，将更新自身的内容；
- 当Redis Cluster Bus 消息中，包含了自己没有的节点时，将其加入到自身的配置中。
上述的规则保证了信息的更新都是单向的，最终朝着Epoch更大的信息收敛。同时Epoch也随着currentEpoch的增加而增加，最终将各节点信息趋于稳定。
sharding
不同节点分组服务于相互无交集的分片（sharding），Redis Cluster 不存在单独的proxy或配置服务器，所以需要将客户端路由到目标的分片。
数据分片（slot）
Redis Cluster 将所有的数据划分为16384 [0-16383] 个分片，每个分片负责其中一部分。每一条数据（key-value）根据key值通过数据分布算法（一致性哈希）映射到16384 个slot中的一个。数据分布算法为：
slotId = crc16(key) % 16384
客户端根据slotId 决定将请求路由到哪个Redis 节点。Cluster 不支持跨节点的单命令，如：sinterstore，如果涉及的2个key对应的slot 在不同的Node，则执行失败。通常Redis的key都是带有业务意义的，如：Product:Trade:20180890310921230001、Product:Detail:20180890310921230001。当在集群中存储时，上述同一商品的交易和详情可能会存储在不同的节点上，进而对于这2个key 不能以原子的方式操作。为此，Redis引入了HashTag的概念，使得数据分布算法可以根据key 的某一部分进行计算，让相关的2 条记录落到同一个数据分片。如：
- 商品交易记录key：Product:Trade:{20180890310921230001}
- 商品详情记录key：Product:Detail:{20180890310921230001}
Redis 会根据 {} 之间的字符串作为数据分布式算法的输入。
客户端的路由
Redis Cluster的客户端相比单机Redis 需要具备路由语义的识别能力，且具备一定的路由缓存能力。当Client 访问的key 不在当前Redis 节点的slots中，Redis 会返回给Client 一个moved命令。并告知其正确的路由信息，如下所示：
当Client 接收到moved 后，再次请求新的Redis时，此时Cluster 的结构又可能发生了变化。此时有可能再次返回moved 。Client 会根据moved响应，更新其内部的路由缓存信息，以便后续的操作直接找到正确的节点，减少交互次数。
当Cluster 在数据重新分布过程中时，可以通过ask 命令控制客户端的路由，如下所示：
上图中，slot 1 需要迁移到新节点上，此时如果客户端已经完成迁移的key，节点将相应ask 告知客户端想目标节点重试。
ask命令和moved 命令的不同在于，moved 会更新Client数据路由，ask 只是重定向新节点，但是后续的相同slot 仍会路由到旧节点。
迁移的过程可能会持续一段时间，这段时间某个slot 的数据，同时可能存在于新旧 2 个节点。由于move 操作会使Client 的路由缓存变更，如果新旧节点对于迁移中的slot 所有key 都回应moved，客户端的路由缓存会频繁变更。因此引入ask 类型消息，将重定向和路由缓存分离。
分片的迁移
在一个稳定的Redis Cluster 中，每个slot 对应的节点都是确定的。在某些情况下，节点和分片需要变更：
-
新的节点作为master加入；
-
某个节点分组需要下线；
-
负载不均衡需要调整slot 分布。
此时需要进行分片的迁移，迁移的触发和过程控制由外部系统完成。Redis Cluster 只提供迁移过程中需要的原语，包含下面 2 种： -
节点迁移状态设置：迁移前标记源/目标节点。
-
key迁移的原子化命令：迁移的具体步骤。
下面的Demo会介绍slot 1 从节点A 迁移到B的过程。
- 向节点B发送状态变更命令，将B的对应slot 状态置为importing。
- 向节点A发送状态变更命令，将A对应的slot 状态置为migrating。
- 针对A上的slot 的所有key，分别向A 发送migrate 命令，告知A 将对应的key 迁移到B。
当A节点的状态置为migrating 后，表示对应的slot 正在从A迁出，为保证该slot 数据的一致性。A此时提供的写服务和通常状态下有所区别，对于某个迁移中的slot：
- 如果Client 访问的key 尚未迁出，则正常的处理该key；
- 如果key已经迁出或者key不存在，则回复Client ASK 信息让其跳转到B处理；
当节点B 状态变成importing 后，表示对应的slot 正在向B迁入。即使B 能对外提供该slot 的读写服务，但是和通常情况下有所区别：
- 当Client的访问不是从ask 跳转的，说明Client 还不知道迁移。有可能操作了尚未迁移完成的，处在A上面的key，如果这个key 在A上被修改了，则后续会产生冲突。
- 所以对于该slot 上所有非ask 跳转的操作，B不会进行操作，而是通过moved 让Client 跳转至A执行。
这样的状态控制，保证了同一个key 在迁移之前总是在源节点执行。迁移后总是在目标节点执行，从而杜绝了双写的冲突。迁移过程中，新增加的key 会在目标节点执行，源节点不会新增key。使得迁移有界限，可以在某个确定的时刻结束。
单个key 的迁移过程可以通过原子化的migrate 命令完成。对于A/B的slave 节点，是通过主备复制，从而达到增删数据。
当所有key 迁移完成后，Client 通过 cluster setslot 命令设置B的分片信息，从而包含了迁入的slot。设置过程中会让Epoch自增，并且是Cluster 中的最新值。然后通过相互感知，传播到Cluster 中的其他节点。
failover
同Sentinel 一样，Redis Cluster 也具备一套完整的故障发现、故障状态一致性保证、主备切换机制。
failover的状态变迁
- 故障发现：当某个master 宕机时，宕机时间如何被集群其他节点感知。
- 故障确认：多个节点就某个master 是否宕机如何达成一致。
- slave选举：集群确认了某个master 宕机后，如何将它的slave 升级成新的master；如果有多个slave，如何选择升级。
- 集群结构变更：成功选举成为master后，如何让整个集群知道，以更新Cluster 结构信息。
故障发现
Redis Cluster 节点间通过Redis Cluster Bus 两两周期性的PING/PONG 交互。当某个节点宕机时，其他Node 发出的PING消息没有收到响应，并且超过一定时间（NODE_TIMEOUT）未收到，则认为该节点故障，将其置为PFAIL状态（Possible Fail）。后续通过Gossip 发出的PING/PONG消息中，这个节点的PFAIL 状态会传播到集群的其他节点。
Redis Cluster 的节点两两通过TCP 保持Redis Cluster Bus连接，当对PING 无反馈时，可能是节点故障，也可能是TCP 链接断开。如果是TCP 断开导致的误报，虽然误报消息会因为其他节点的正常连接被忽略，但是也可以通过一定的方式减少误报。Redis Cluster 通过 预重试机制 排除此类误报：当 NODE_TIMEOUT/2 过去了，但是还未收到响应，则重新连接重发PING 消息，如果对端正常，则在很短的时间内就会有响应。
故障确认
对于网络分隔的情况，某个节点（B）并没有故障，但是和A 无法连接，但是和C/D 等其他节点可以正常联通。此时只会有A 将 B 标记为PFAIL 状态，其他节点认为B 正常。此时A 和C/D 等其他节点信息不一致，Redis Cluster 通过故障 确认协议 达成一致。
集群中每个节点都是Gossip的接收者，A 也会接收到来自其他节点的Gossip 消息，被告知B 是否处于PFAIL 状态。当A收到来气其他master 节点对于 B 的PFAIL 达到一定数量后，会将B的PFAIL 状态升级为 FAIL 状态。表示B 已经确认为故障态，后面会发起slave 选举流程。
A节点内部的集群信息中，对于B的状态从PFAIL 到 FAIL 的变迁，如下图所示：
slave选举
上图中，B是A的master，并且B 已经被集群公认是FAIL 状态了，那么A 发起竞选，期望成为新的master。
如果B 有多个slave （A/E/F）都认知到B 处于FAIL 状态了，A/E/F 可能会同时发起竞选。当B的slave 个数 >= 3 时，很有可能产生多轮竞选失败。为了减少冲突的出现，优先级高的slave 更有可能发起竞选，从而提升成功的可能性。这里的优先级是slave的数据最新的程度，数据越新的（最完整的）优先级越高。
slave 通过向其他master发送FAILVOER_AUTH_REQUEST 消息发起竞选，master 收到后回复FAILOVER_AUTH_ACK 消息告知是否同意。slave 发送FAILOVER_AUTH_REQUEST 前会将currentEpoch 自增，并将最新的Epoch 带入到FAILOVER_AUTH_REQUEST 消息中，如果自己未投过票，则回复同意，否则回复拒绝。
结构变更通知
当slave 收到过半的master 同意时，会替代B 成为新的master。此时会以最新的Epoch 通过PONG 消息广播自己成为master，让Cluster 的其他节点尽快的更新拓扑结构。
当B 恢复可用之后，它手续爱你仍然认为自己是master，但逐渐的通过Gossip 协议得知A 已经替代了自己，然后降级为A的slave。
扫一扫
3532
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
