Redis三种集群方式

redis三种集群方式

主从复制

1、 什么是主从复制？

• ​ 主从复制就是存在多个服务器，一台作为主服务器（master），多台作为从服务器（slave）

  master服务器数据，会全部发送给slave服务器，上述称为主从复制

2、为什么要进行主从复制？

• 我们知道一个网站大部分的时候，服务器收到的都是请求读的操作，写的操作相对来说会少很多。如果我们用一台服务器 即支持读，又支持写，一旦出现高并发的情况，服务器很可能就凉凉。于是要进行读写分离。进行主从复制，将多台服务器作为读的服务器，一台作为写的服务器。master服务器主要负责写服务,slave服务器主要负责读服务，为保证数据的一直性，master服务器会将数据全部发给slave服务器

3、主从复制原理

和MySQL需要主从复制的原因一样，Redis虽然读取写入的速度都特别快，但是也会产生性能瓶颈，特别是在读压力上，为了分担压力，Redis支持主从复制。Redis的主从结构一主一从，一主多从或级联结构，复制类型可以根据是否是全量而分为全量同步和增量同步。
下图为级联结构：

4、全量复制

Redis全量复制一般发生在slave的初始阶段，这时slave需要将master上的数据都复制一份，具体步骤如下：

（1）、slave连接master，发送SYNC命令；

（2）、master街道SYNC命令后，执行BGSAVE命令生产RDB文件并使用缓冲区记录此后执行的所有写命令；

（3）、master的BGSAVE执行完成后，向所有的slave发送快照文件，并在发送过程中继续记录执行的写命令；

（4）、slave收到快照后，丢弃所有的旧数据，载入收到的数据；

（5）、master快照发送完成后就会开始向slave发送缓冲区的写命令；

（6）、slave完成对快照的载入，并开始接受命令请求，执行来自master缓冲区的写命令；

（7）、slave完成上面的数据初始化后就可以开始接受用户的读请求了。

5、增量复制

增量复制实际上就是在slave初始化完成后开始正常工作时master发生写操作同步到slave的过程。增量复制的过程主要是master每执行一个写命令就会向slave发送相同的写命令，slave接受并执行写命令，从而保持主从一致。

6、 测试集群

1. 复制几份配置文件 分别是redis.conf redis6380.conf redis6381.conf

2. 修改配置文件中的配置

   port，pidfile，logfile，dbfileName

3. 分别启动即可

4. 查看是否启动成功
   

5. 通过 slaveof ip port命令动态的设置为从服务器设置master （但不是永久的）
   

6. 通过 info replication 查看当前服务器主从复制信息
   
   

7. 从服务器是不能自己set key的哦，从服务器主要负责读服务
   

7、Redis主从同步的策略(全量复制和增量复制相结合)

主从同步刚连接的时候进行全量同步；全量同步结束后开始增量同步。如果有需要，slave在任何时候都可以发起全量同步，其主要策略就是无论如何首先会尝试进行增量同步，如果步成功，则会要求slave进行全量同步，之后再进行增量同步。

注意：如果多个slave同时断线需要重启的时候，因为只要slave启动，就会和master建立连接发送SYNC请求和主机全量同步，如果多个同时发送SYNC请求，可能导致master IO突增而发送宕机。

哨兵模式（有待补充和实验）

1. 为什么要用哨兵模式？

   • 当主从复制服务器群搭建好后，主服务器宕机，需要手动配置从服务器变为master服务器，而这一步需要手动，效率不高。使用哨兵模式，开启哨兵进程对主从服务器进行监控，一旦发现主服务器宕机，会进行投票选举，选举出一个新的slave服务器作为主服务器，而这一流程是自动的。

2. 哨兵的功能

   • 监控所有Redis节点（主从服务器）是否正常运行；
   • master故障后可以通过投票机制，从slave中选举出新的master，保证集群正常运行。
     在一个一主多从的集群中，可以启用多个哨兵进行监控以保证集群足够稳健，这种情况下，哨兵不仅监控主从服务，哨兵之间也会相互监控，建议哨兵至少3个并且是奇数。

3. 哨兵的任务

   • 监控：哨兵会不断的检测master和slave之间是否运行正常；
   • 提醒：当监控的某个Redis出现问题，哨兵可以通过API向管理员或其他应用程序发送通知；
   • 故障迁移：当一个master不能正常工作时，哨兵会开始一次自动故障迁移操作，它会将失效master的其中一个slave提升为master，并让失效master和其他slave该为复制新的master，当客户端试图连接失效的master时，集群也会向客户端返回新的master地址，使得集群可以使用新的master代替失效的master。

4. 工作原理

   哨兵是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议来接收关于Master是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
   每个哨兵会向其它哨兵、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂。若“哨兵群”中的多数sentinel都报告某一master没响应,系统才认为该master"彻底死亡"，通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。
   虽然哨兵释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵。

5. 缺点

   • 当主服务器宕机后，从服务器切换的那个时间，服务不可以用

使用方式

1、调整结构，6379带着6380、6381

2、新建sentinel.conf文件，名字绝不能错

3、配置哨兵,填写内容

• sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379
• 上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机（PS. 跟官网的描述有出入，下面有官方文档说明

4、启动哨兵

• redis-sentinel /sentinel.conf（上述目录依照各自的实际情况配置，可能目录不同）

5、正常主从演示

6、原有的master挂了

7、投票新选

8、重新主从继续开工，info replication查查看

主从复制+哨兵模式的缺点

复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

集群（有待实验）

Redis在3.0版本开始正式引用集群特性，Redis集群是一个分布式，高容错的内存K/V系统，集群可以使用的功能是普通单机Redis所使用的功能的一个子集，比如，Redis集群并不支持处理多个keys的命令，因为这需要在不同节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会出现无法预估的错误。

1. Redis集群的特征

Redis集群有以下几个重要的特征：
（1）、Redis集群的分片特征在于将空间拆分为16384个槽位，某一个节点负责其中一些槽位；
（2）、Redis集群提供一定程度的可用性，可以在某个节点宕机或者不可达的情况继续处理命令；
（3）、Redis集群不存在中心节点或代理节点，集群的其中一个最重要的设计目标是达到线性可扩展性；
其架构如下：

其中每一个圆代表一个节点，任何两个节点是互通的，可以归纳以下几点：

• 所有的节点相互连接；
• 集群消息通信通过集群总线通信，，集群总线端口大小为客户端服务端口+10000，这个10000是固定值；
• 节点与节点之间通过二进制协议进行通信；
• 客户端和集群节点之间通信和通常一样，通过文本协议进行；
• 集群节点不会代理查询；

2. Redis集群的原理

Redis Cluster中有一个16384长度的槽的概念，他们的编号为0、1、2、3……16382、16383。这个槽是一个虚拟的槽，并不是真正存在的。正常工作的时候，Redis Cluster中的每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，这是可以由用户指定的，也可以在初始化的时候自动生成（redis-trib.rb脚本）。这里值得一提的是，在Redis Cluster中，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权。

那么Redis集群是怎么存储的呢？
首先，在redis的每一个节点上，都有这么两个东西，一个是插槽（slot）可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是：0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
还有就是因为如果集群的话，是有好多个redis一起工作的，那么，就需要这个集群不是那么容易挂掉，所以，理论上就应该给集群中的每个节点至少一个备用的redis服务，这个备用的redis称为从节点（slave）。然后，每一个节点都存有这个集群所有主节点以及从节点的信息，它们之间通过互相的ping-pong判断是否节点可以连接上。
如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。如果某个节点和所有从节点全部挂掉，我们集群就进入faill状态。还有就是如果有一半以上的主节点宕机，那么我们集群同样进入发力了状态。这就是我们的redis的投票机制。

(1)、投票过程是集群中所有master参与,如果半数以上master节点与master节点通信超时(cluster-node-timeout)认为当前master节点挂掉.
(2)、什么时候整个集群不可用(cluster_state:fail)
a、如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败。
b、如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态。