带你简单了解Redis三种模式----深入了解集群！！

一，Cluster集群

官方文档！！！集群

Cluster模式介绍:一般用的最多，包含了三种模式！！！

Cluster模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。

cluster集群特点：

• 多个redis节点网络互联，数据共享

• 所有的节点都是一主一从（也可以是一主多从），其中从不提供服务，仅作为备用

• 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，
  并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为

• 支持在线增加、删除节点

• 客户端可以连接任何一个主节点进行读写

搭建环境

准备当作主的节点	准备当作从的
20.0.0.21	20.0.0. 26
20.0.0.22	20.0.0.27
20.0.0.23	20.0.0.28

步骤一：所有节点安装redis并搭建完成！

另一篇博客，redis搭建–超链接

• 注意：如果您正在使用Redis 5或更高版本，这很容易完成，因为我们得到了嵌入到redis-cli，它可以用于创建新的集群、检查或重新配置现有集群，等等。

• 对于Redis版本3或4，有一个名为redis-trib.rb非常相似。你可以在srcRedis源代码发行版的目录。你需要安装redis创业板能够运行redis-trib.

步骤二：修改配置

• 配置文件更改（所有节点）:

vi /etc/redis/6379.conf

 70 bind 20.0.0.21            //本地ip地址
 89   protected-mode no       //关闭防护模式
 833  cluster-enabled yes     //开启集群功能
 841  cluster-config-file nodes-6379.conf      //当前节点存储配置文件
 847  cluster-node-timeout 15000               //群集node超时时间
 700  appendonly yes                           //开启AOF持久化功能

步骤三：创建集群

仅在一台创建就行！！

[root@localhost opt]# redis-cli  --cluster create 20.0.0.21:6379 \
20.0.0.22:6379 \
20.0.0.23:6379 \
20.0.0.26:6379 \
20.0.0.27:6379 \
20.0.0.28:6379 \
--cluster-replicas 1


--replicas 1 表示主从复制比例为 1:1，即一个主节点对应一个从节点

安装过程。。。。。。。

>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 20.0.0.27:6379 to 20.0.0.21:6379
Adding replica 20.0.0.28:6379 to 20.0.0.22:6379
Adding replica 20.0.0.26:6379 to 20.0.0.23:6379
M: 763aaaf4e902353da98e8479f58e3dafeec95b30 20.0.0.21:6379
   slots:[0-5460] (5461 slots) master
M: f0299fef35041d6fe8388b003b56ad26ebd8ce9f 20.0.0.22:6379
   slots:[5461-10922] (5462 slots) master
M: 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7 20.0.0.23:6379
   slots:[10923-16383] (5461 slots) master
S: c99da048b0ad841105e98765745dec931df7ee7c 20.0.0.26:6379
   replicates 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7
S: 97ee6a7e3411761ab54e48289c433cbe7cf57439 20.0.0.27:6379
   replicates 763aaaf4e902353da98e8479f58e3dafeec95b30
S: 936f0a409d90b654124ceb02e91b34d72edd822e 20.0.0.28:6379
   replicates f0299fef35041d6fe8388b003b56ad26ebd8ce9f 
Can I set the above configuration? (type 'yes' to accept): yes      //确定配置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 20.0.0.21:6379)
M: 763aaaf4e902353da98e8479f58e3dafeec95b30 20.0.0.21:6379
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
M: 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7 20.0.0.23:6379
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
S: 97ee6a7e3411761ab54e48289c433cbe7cf57439 20.0.0.27:6379
   slots: (0 slots) slave
   replicates 763aaaf4e902353da98e8479f58e3dafeec95b30
S: c99da048b0ad841105e98765745dec931df7ee7c 20.0.0.26:6379
   slots: (0 slots) slave
   replicates 794fbb0a856ee612ed5eabdfde3ea10d0cd96de7
S: 936f0a409d90b654124ceb02e91b34d72edd822e 20.0.0.28:6379
   slots: (0 slots) slave
   replicates f0299fef35041d6fe8388b003b56ad26ebd8ce9f
M: f0299fef35041d6fe8388b003b56ad26ebd8ce9f 20.0.0.22:6379
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.

可以看到配置：
20.0.0.21是master  哈希槽值范围是:slots:[0-5460]
20.0.0.22是master  哈希槽值范围是:slots:[5461-10922]
20.0.0.23是master  哈希槽值范围是:slots:[10923-16383]

20.0.0.26是salve   对应的主节点是23
20.0.0.27是salve   对应的主节点是21
20.0.0.28是salve   对应的主节点是22

步骤四：验证集群

[root@localhost ~]# redis-cli -c -h 20.0.0.21           //-C 是集群模式，登录集群；
20.0.0.21:6379> set name lisi
-> Redirected to slot [5798] located at 20.0.0.22:6379  //此时数据，被分配到哈希槽[5798]，是在22的主节点上
OK
20.0.0.22:6379> set name1 zhangshan
-> Redirected to slot [12933] located at 20.0.0.23:6379  //此时数据，被分配到哈希槽[12933]，是在23的主节点上
OK
20.0.0.23:6379> set name2 wangwu
-> Redirected to slot [742] located at 20.0.0.21:6379    //此时数据，被分配到哈希槽[742]，是在21的主节点上
OK
20.0.0.21:6379>                 
[root@localhost ~]# redis-cli -c -h 20.0.0.27           //登录从节点服务器
20.0.0.27:6379> set age1  18
-> Redirected to slot [9008] located at 20.0.0.22:6379   //主从模式作用，写入键值，会随机自动分配到主的节点上，写的操作之会写入到主节点
OK
20.0.0.22:6379> 
[root@localhost ~]# redis-cli -c -h 20.0.0.22          //登录22主节点，应该会显示刚才写入的键值！！
20.0.0.22:6379> keys *
1) "age1"
2) "name"
20.0.0.22:6379> get age1
"18"
20.0.0.22:6379> 
[root@localhost ~]# redis-cli -c -h 20.0.0.28          //对应的从节点查看键值，因为会同步数据，所以可以看到所有key值
20.0.0.28:6379> keys *
1) "age1"
2) "name"
20.0.0.28:6379> get name
-> Redirected to slot [5798] located at 20.0.0.22:6379    //查看键值还是从主节点读！
"lisi"
20.0.0.22:6379> 
[root@localhost ~]# redis-cli -c -h 20.0.0.28
20.0.0.28:6379> set age2  19
-> Redirected to slot [4947] located at 20.0.0.21:6379   //写入键值，会随机自动分配到主的节点上，写的操作之会写入到主节点
OK
20.0.0.21:6379> 
[root@localhost ~]# redis-cli -c -h 20.0.0.26
20.0.0.26:6379> set age3  20
-> Redirected to slot [882] located at 20.0.0.21:6379     //写入键值，会随机自动分配到主的节点上，写的操作之会写入到主节点
OK
20.0.0.21:6379> get name                                   //提取键值会从对应的主节点，提取键值
-> Redirected to slot [5798] located at 20.0.0.22:6379       
"lisi"
20.0.0.22:6379> get name1
-> Redirected to slot [12933] located at 20.0.0.23:6379
"zhangshan"
20.0.0.23:6379> get name2
-> Redirected to slot [742] located at 20.0.0.21:6379
"wangwu"

• 官方文档：解释如果主节点宕机

Redis机群主从模型
为了在主节点子集失败或无法与大多数节点通信时保持可用，Redis群集使用主从模型，其中每个散列槽从1(主节点本身)到N个副本(N-1附加从节点)。
在我们的示例集群中，节点A、B、C，如果节点B失败，集群将无法继续，因为我们不再有办法在5501-11000范围内为哈希槽提供服务。
然而，当集群被创建(或在稍后的时间)时，我们向每个主节点添加一个从节点，这样最后的集群由A、B、C组成，它们是主节点，A1、B1、C1是从节点。这样，如果节点B失败，系统就能够继续运行。
节点B1复制B，B失败，集群将促进节点B1作为新的主节点，并将继续正确运行。
但是，请注意，如果节点B和B1同时失败，Redis群集将无法继续运行。

• 简单说一下原理

redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。

每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。

Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。

redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。
我们在测试的时候看到set 和 get 的时候，直接跳转到了创建键值的主节点上。

Redis 集群会把数据存在一个 master 节点，然后在这个 master 和其对应的salve 之间进行数据同步。

当读取数据时，也根据一致性哈希算法到对应的 master 节点获取数据。

需要注意的是：必须要3个或以上的主节点，否则在创建集群时会失败，并且当存活的主节点数小于总节点数的一半时，整个集群就无法提供服务了。

新增节点和更改节点身份

集群中增加节点：

20.0.0.23:6379> cluster meet 20.0.0.29 6379
OK

//新增的节点都会是master身份！！！！

更换节点身份：

redis-cli -c -h 192.168.30.130  cluster replicate e51ab166bc0f33026887bcf8eba0dff3d5b0bf14

//后面跟node_id，更改对应节点身份。


也可以进入到redis，修改

20.0.0.23:6379>CLUSTER REPLICATE e51ab166bc0f33026887bcf8eba0dff3d5b0bf14
OK

master宕机参考文档

• 参考链接！！！！！！！
• 哨兵模式起了作用

二，主从模式

主从模式介绍

主从模式是三种模式中最简单的，在主从复制中，数据库分为两类：主数据库(master)和从数据库(slave)。

其中主从复制有如下特点：

• 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库

• 从数据库一般都是只读的，并且接收主数据库同步过来的数据

• 一个master可以拥有多个slave，但是一个slave只能对应一个master

• slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来

• master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务

• master挂了以后，不会在slave节点中重新选一个master

三，哨兵模式

哨兵模式介绍

sentinel模式是建立在主从模式的基础上

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任务：

• 监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
• 提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个从服务器作为新的主服务器。

虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 –sentinel 选项来启动 Redis Sentinel 。