Redis_集群方案：主从-哨兵-cluster

redis高可用集群方案

公司redis集群方案是怎样的？

1. 一般三主三从就很好了；一共六台机器,三主三从,保证高可用,主节点挂了,从节点可以顶上来;
2. 机器的配置32G内存+8核心CPU,但是分配给redis是10G的内存;对外总共50G内存;

redis主从复制

简介:

1. 是典型的读写分离；
2. 主节点：可读可写； 从节点：可读，数据从主节点同步过来
3. 缺点：
   • 没有保证高可用：实际上只做到了读写分离，提高了性能而已，但是万一主节点挂掉，程序将无法写入数据。
   • 无法解决主节点写的压力；

主从数据同步的核心流程:

1. slave会ping主节点master，master生成一份全量的RDB发给slave, 此时master还是会继续缓存最新的数据的,并不是停止;
2. slave接收到RDB，会将RDB保存到磁盘上去(持久化)，再基于RDB将数据加载到自己的本地内存；
3. 之后master会将新来缓存的写命令发送给slave，实现一致性；也就是全量同步以后的写操作的同步：就是只发写的命令,不是发全量RDB了；

主从复制的断点续传:

1. slave节点第一次连(或者断开很久再连)master会触发一次全量的复制; 将自己数据全部给slave(具体怎么复制就是上面的流程);
2. 如果slave断开连接后再连master，那么master只会将在上次基础上增加的数据生成RDB传过去;

无磁盘化复制:

​ 所谓无磁盘化，就是master复制数据到slave时，是直接在内存生成RDB发给slave的， 不会在自己本地磁盘存RDB；

主从架构过期key的处理:

​ slave不会处理过期key，只有等master的key过期了，那么模拟一条del发给slave进行key的删除；

哨兵集群模式

什么是哨兵：

​ 哨兵是一种特殊的模式，redis提供了哨兵的命令，哨兵是一个独立的进程，会独立运行，原理就是通过哨兵发送命令，等待redis服务器响应，从而监控运行着的多个reids实例；

优点：

1. 监控：哨兵sentinel会不断检查主服务器和从服务是否正常；
2. 提醒：某一个节点出问题，sentinel会通过API通知；
3. 故障自动转移（高可用）：当主节点不能用时，sentinel会自动开启一次自动故障转移；

缺点：

1. 还是没有解决主节点master写的压力问题；

2. 另外转移需要时间；

3. 就是对主从的增强；另外一定要先启动主从节点（保证主从复制成功），也就是要创建好一个原始的主从关系。

哨兵本身也要多实例:

1. 主从架构的致命问题就是如果master挂了，整个就不可用了。所以sentinel哨兵可以监控所有节点，如果master挂了，会自动故障转移，选举一个slave变为master；

2. 哨兵本身也是需要搭集群，至少需要三个哨兵实例来保证哨兵的高可用；

   • 为什么至少三个哨兵实例？如果两个 ,那么一台宕机，另外一个不能将slave转为master，因为没有达到majority数据;

   

异步复制导致数据丢失:

1. 就是master新存进来的数据，在还没有同步到slave的时候就挂了；那么哨兵检测到master挂了之后，会将slave转为master，此时那部分新存进来的数据是丢失的;

集群脑裂导致数据丢失:

1. 脑裂问题：就是出现了异常性的、有相同数据、相同工作的两个节点；相当于两个大脑，称为脑裂；
2. 这里的集群脑裂：就是master并没有死，只是因为为网络问题和哨兵断开了连接(客户端还是可以访问的)，那么此时哨兵认为其挂了，就将一个slave转为master；此时就出现了两个master；
3. 那么client继续向原master写数据；原master被会被转为slave、从新的master同步数据；那么client写的那部分数据就没有了，因为master变为slave，会去同步新master的数据；

如何解决同步复制和脑裂带来的数据丢失方法:

1. 配置参数:

   • min-slaves-to-write 1
   • min-slaves-max-lag 10

   第一个参数表示连接到master的最少slave数量
   第二个参数表示slave连接到master的最大延迟时间

2. 按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。

redis cluster集群模式

概述：

1. Redis Cluster是Redis的亲儿子，是Redis作者自己提供的Redis集群方案；
2. 是一种去中心化的集群模式；使用==哈希槽算法==实现数据的分布存储；redis3.0后支持，每个节点之间相连；
3. 实际上是一种局部的主从，正常情况主节点正常工作，万一主节点挂了，那么从节点升级为局部主节点，继续完成集群中的事物；如果原来的主节点恢复，那么也只能作为从节点了；
4. 就是多master+读写分离(master写slave读)+高可用(master挂掉，slave顶上来)
5. 原来的集群模式只有一个master，那么master能存多少数据,、slave就只能存多少数据；所以可以在主从基础上横向扩容,支持多个master节点;

cluster原理：

1. redis并不是传统的每个redis进行数据的同步，而是将16000个插槽分配到每一个redis，也就是每个节点负责一部分hash槽；

2. 所以说并不是数据一致，而是算法一致，每个请求过来都可以通过key找到他的value在哪个节点上(直接所有的ip配置好,redisTemplate直接取就能够计算你要取的key在哪)；

3. 所以说原理就是通过哈希槽算法将数据分布到不同的节点：CRC16（key)/16384 = 应该存的位置；

4. 节点里面存槽，槽里面存数据；槽的数量是固定的；

优缺点：

1. 去中心化，不存在因为某一个节点成为性能瓶颈；

2. 高扩展性：

   • 这是redis cluster最具有特点的；
   • 当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；
   • 当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了。

3. 高可用：部分节点宕机，整个集群仍然可用；还可用通过增加slave做数据备份；

4. 故障自动转移：某个局部主节点挂点，其从节点会自动转为主节点；恢复后只能充当从节点；

5. 可扩-展性：但是不建议线性扩展为1000个节点；

6. ps：提高用户体验，为运维提供宝贵的故障修复时间。

7. 缺点：

   • 资源隔离相对较差，容易出现相互影响；

   • 数据是通过异步复制，不能保证数据的强一致性；

cluster的使用场景:

1. 如果只是简单的需要几个G的内存来做一下缓存,直接用哨兵就完全可以了;
2. cluster主要用于海量数据,，高并发场景;

cluster的数据分布的算法(hash slot):

​ 这部分见下小结：数据分布算法

cluster集群什么情况下会失效？

1. 是否可以由failover机制决定；因为集群能不能用就看插槽数能不能满足；
2. 超过一半以上master宕机；
3. 如果是三台主的话，宕机一主一从也不可用；也就是只要有主从全部宕机，就不可用；

cluster节点间怎么通信的:

1. gossip协议:

   gossip协议包括多种消息,包括ping,pong,meet,fail等

   • meet: 某个节点发meet给新加入的节点,然后新节点就会开始与其他节点相互通信;
   • ping: 每个节点都会频繁去给其他节点发ping, 其中包括自己的状态和自己维护的集群元数据,相互通过ping交换数据;
   • pong: 返回ping和meet, 包括自己的状态信息,用户信息的广播和更新;
   • fail: 某个节点判断一个节点fail后,就会发生fail给其他节点,说这个节点宕机了;

2. 各个主节点之间进行元数据的交换，和状态信息的交换：

   • 如果发现ping一定时间没有回复，就会认为宕机；
   • 就会fail通知其他节点这个节点可能宕机了(主观认为)；
   • 如果其他master都认为宕机了(客观认为)； 就认为此节点宕机；从他的slave中选一个成为master；

jedis操作cluster的流程:

1. 基于重定向的客户端:
   • 总流程:
     • 客户端会任意挑选一个节点去发送命令,每个rdis实例,接收到命令,会计算key对应的hash slot;如果在本地就返回value,如果不在,因为数据一直在交换,所以返回key所在的节点给客户端,让他重定向;
   • 具体的slot计算: 根据key计算CRC16的值,再对16284进行取模,拿到对应的hash槽是哪个;
   • 具体的hash slot查找: 节点间是通过gossip协议进行数据的交换,所以就知道每个hash slot在哪个节点上;
2. smart Jedis:
   • 因为进行重定向有io操作,那么smart jedis维护了一个映射表,先找映射表,如果没有走重定向,并更新映射表;

hash slot迁移和ask重定向:

1. 随着节点数据的增加和减少,那么整个hash槽是需要进行再次分配的;所以涉及到数据的迁移;
2. 如果发现正在迁移,那么会返回ask重定向给jedis;
   s:
   • 因为进行重定向有io操作,那么smart jedis维护了一个映射表,先找映射表,如果没有走重定向,并更新映射表;

hash slot迁移和ask重定向:

1. 随着节点数据的增加和减少,那么整个hash槽是需要进行再次分配的;所以涉及到数据的迁移;
2. 如果发现正在迁移,那么会返回ask重定向给jedis;
3. jedis接收到重定向后,会定位到目标的节点去执行,但是因为ask是发生在迁移过程中,是不会更新到hashslot本地缓存的;