Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。
Redis 集群不支持那些需要同时处理多个键的 Redis 命令，比如：mget， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低 Redis 集群的性能， 并导致不可预测的行为。
Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
Redis 集群提供了以下两个好处：
将数据自动切分（split）到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。
每个Redis集群中的节点都需要打开两个TCP连接。一个连接用于正常的给Client提供服务，比如6379，还有一个额外的端口（通过在这个端口号上加10000）作为数据端口，比如16379。第二个端口（本例中就是16379）用于集群总线，这是一个用二进制协议的点对点通信信道。这个集群总线（Cluster bus）用于节点的失败侦测、配置更新、故障转移授权，等等。客户端从来都不应该尝试和这些集群总线端口通信，它们只应该和正常的Redis命令端口进行通信。注意，确保在你的防火墙中开放着两个端口，否则，Redis集群节点之间将无法通信。
命令端口和集群总线端口的偏移量总是10000。
Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。
集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中：
这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。 比如说：
如果用户将新节点 D 添加到集群中， 那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。
与此类似， 如果用户要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。
因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞， 所以无论是添加新节点还是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会造成集群下线。
为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下， 仍然可以正常运作， Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有 1 个至 N 个副本（replica）， 其中一个副本为主节点（master）， 而其余的 N-1 个副本为从节点（slave）。
在之前列举的节点 A 、B 、C 的例子中， 如果节点 B 下线了， 那么集群将无法正常运行， 因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。
另一方面， 假如在创建集群的时候（或者至少在节点 B 下线之前）， 我们为主节点 B 添加了从节点 B1 ， 那么当主节点 B 下线的时候， 集群就会将 B1 设置为新的主节点， 并让它代替下线的主节点 B ， 继续处理 5501 号至 11000 号的哈希槽， 这样集群就不会因为主节点 B 的下线而无法正常运作了。
不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作
Redis 集群不保证数据的强一致性（strong consistency）： 在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。
使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。 考虑以下这个写命令的例子：
主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。
Redis 集群另外一种可能会丢失命令的情况是， 集群出现网络分裂（network partition）， 并且一个客户端与至少包括一个主节点在内的少数（minority）实例被孤立。
举个例子， 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节点， 而 A1 、B1 、C1 分别为三个主节点的从节点， 另外还有一个客户端 Z1 。
假设集群中发生网络分裂， 那么集群可能会分裂为两方， 大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ， 而少数（minority）的一方则包含节点 B 和客户端 Z1 。
在网络分裂期间， 主节点 B 仍然会接受 Z1 发送的写命令：
注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选项：
| 主机名 | ip地 |
| redis01 | 10.0.0.10 |
| redis02 | 10.0.0.60 |
| redis03 | 10.0.0.61 |
| redis04 | 10.0.0.70 |
| redis05 | 10.0.0.71 |
| redis06 | 10.0.0.72 |
# vim /etc/security/limits.conf * soft noproc 10240 * hard noproc 10240 * soft nofile 65535 * hard nofile 65535
# yum install -y sshpass
# ssh-keygen -t rsa -f /root/.ssh/id_rsa -P ""
# for i in redis0{1..6};do sshpass -p123456 ssh-copy-id -i /root/.ssh/id_rsa.pub "-o StrictHostKeyChecking=no" $i;done
redis单机搭建 https://www.cnblogs.com/zh-dream/p/12094075.html
将单机redis搭建 的配置文件分发到各个节点： # for i in 10.0.0.{61,60,70,71,72};do scp -r /data/module/* $i:/data/module/ ;done
# sed -ri "s/^bind 10.*/bind `hostname -I`/" /data/module/redis-5.0.0/etc/redis.conf
# echo "export PATH=$PATH:/data/module/redis-5.0.0/bin" >> /etc/profile
# . /etc/profile
# for i in redis0{2..6};do ssh $i "mkdir /data/module/redis-5.0.0/data" ;done # for i in redis0{2..6};do ssh $i "mkdir /data/module/redis-5.0.0/logs" ;done
创建集群
[root@redis01 etc]# redis-cli --cluster create 10.0.0.10:6379 10.0.0.60:6379 10.0.0.61:6379 10.0.0.70:6379 10.0.0.71:6379 10.0.0.72:6379 --cluster-replicas 1 -a 123456 Warning: Using a password with ‘-a‘ or ‘-u‘ option on the command line interface may not be safe. >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 10.0.0.70:6379 to 10.0.0.10:6379 Adding replica 10.0.0.71:6379 to 10.0.0.60:6379 Adding replica 10.0.0.72:6379 to 10.0.0.61:6379 M: bb273c158818c55f8f3ad0d0b2d971157fd56c90 10.0.0.10:6379 slots:[0-5460] (5461 slots) master M: 5a6291fd3fb00119ae4828f5b86554fe4f35a1a7 10.0.0.60:6379 slots:[5461-10922] (5462 slots) master M: fc80f137ccb33e09fe33f2e3364de00bbbc4e888 10.0.0.61:6379 slots:[10923-16383] (5461 slots) master S: 312b3228330eff446e5c9c159182bcdcd61353c6 10.0.0.70:6379 replicates bb273c158818c55f8f3ad0d0b2d971157fd56c90 S: 97c7b9789303a8f1eb8f8516ab0d598c304635b8 10.0.0.71:6379 replicates 5a6291fd3fb00119ae4828f5b86554fe4f35a1a7 S: ad58497a499e41df39d2f597e64beb046c5dc756 10.0.0.72:6379 replicates fc80f137ccb33e09fe33f2e3364de00bbbc4e888 Can I set the above configuration? (type ‘yes‘ to accept): yes >>> Nodes configuration updated >>> Assign a different config epoch to each node >>> Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join ... >>> Performing Cluster Check (using node 10.0.0.10:6379) M: bb273c158818c55f8f3ad0d0b2d971157fd56c90 10.0.0.10:6379 slots:[0-5460] (5461 slots) master 1 additional replica(s) S: 97c7b9789303a8f1eb8f8516ab0d598c304635b8 10.0.0.71:6379 slots: (0 slots) slave replicates 5a6291fd3fb00119ae4828f5b86554fe4f35a1a7 S: 312b3228330eff446e5c9c159182bcdcd61353c6 10.0.0.70:6379 slots: (0 slots) slave replicates bb273c158818c55f8f3ad0d0b2d971157fd56c90 M: 5a6291fd3fb00119ae4828f5b86554fe4f35a1a7 10.0.0.60:6379 slots:[5461-10922] (5462 slots) master 1 additional replica(s) M: fc80f137ccb33e09fe33f2e3364de00bbbc4e888 10.0.0.61:6379 slots:[10923-16383] (5461 slots) master 1 additional replica(s) S: ad58497a499e41df39d2f597e64beb046c5dc756 10.0.0.72:6379 slots: (0 slots) slave replicates fc80f137ccb33e09fe33f2e3364de00bbbc4e888 [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.
原文：https://www.cnblogs.com/zh-dream/p/12249767.html