Redis架构模式

Redis架构模式

前言
reids在工作中经常会被用到，它的存储效率要明显高于关系数据库（因为它的数据是存储在内存中的），除此之外还可以用来验证一些操作，分布式锁等。
那么有没有想过有一天所在的redis突然崩溃了，那该怎么办呢？

当然首先我们要尽量避免这种情况，但是什么事情都有万一 万一发生呢？
如果是只有一台redis服务器，那就等死 或者跑路吧，

如果不想这样的结果，就告知你的老板多备用几台服务器，否则会有这样的风险。
忽悠到几台服务器后，（口误，是拥有后），我们怎么来用多台redis服务器来解决这种问题呢。
好了闲话不多说直接上正题，只讲步骤具体配置文件就不发出来了。
有需要的点赞关注收藏联系作者。

主从模式：

两台以上的redis 服务器，一台为主节点master 另外几台台为从节点slave，
项目连接上主节点，当主节点有数据更新时，更新完成的同时主节点会向从节点发送一条命令，从节点的数据就会更新
从节点默认是只读的，当主节点master宕机后，从节点不能连接项目用来更新存储数据。

优点：
1，配置简单
2， 解决了数据的冗余备份，是哨兵模式的基础
缺点：
不能解决高可用的问题

Sentinel 哨兵模式：

在主从模式的基础上加上多个哨兵服务，每个哨兵都是一个单独的服务，具体配置在sentinel.conf里，配置完直接启动即可
每个哨兵都会监控主节点master和从节点slave的服务
当一个哨兵认为master宕机了，此时mater状态为主观下线，
当到一定数量的（这个是通过参数quorum配置的）哨兵认为master宕机了，此时master状态为客观下线
当master状态为客观下线时 Sentinel哨兵 内部会进行选举leader，每个哨兵都会进行投票，当获得一半以上的投票的哨兵会成为哨兵leader
哨兵leader进行slave选举，选择新的从节点为主节点
宕掉的主节点恢复后成为新的从节点
发现任意一台节点出现问题  Sentinel 可以通过 API 向管理员或者其他应用程序发送通知；
哨兵服务最好配置大于等于3个 并且建议单数
项目连接的是哨兵服务。

slave选举：

首先排除不在线响应慢的slave
选择优先级高的salve
优先级一样的选择复制数据比较多的salve
复制数据一样的选择run id小的（每个run id都不一样）

哨兵模式脑裂问题：
当master与所有哨兵、slave发生通信中断，但是实际上master是存活的，且哨兵与slave是正常连接的，哨兵就会选举出一个新的master，这时候就会有两个master，发生脑裂
解决：

修改 redis 配置 redis.conf，检查 master 节点与其它副本的联系。
当 master 与其它副本在一定时间内失去联系，那么禁止 master 进行写数据

优点：
1，可以实现故障转移，高可用
2，哨兵Sentinel 会实时监控所有的主从节点，通过API 向管理员或者其他应用程序发送通知。
缺点：
1，主从切换时间会丢失数据
2，单master主节点性能压力问题

分片集群模式：

多个master主节点，每个主节点拥有自己的从节点slave
创建集群时每个master主节点通过平均分配获取哈希槽范围，
哈希槽范围为0-16383，例如如果有三个 则范围大致为(1-5000,5000-10000,10000-16383) 注意是 大致平均分配
因为哈希槽范围 0-16383 所以redis集群中master最大节点数不能超过16384
项目可以连接任意一个主master节点
 client客户端通过CRC16算法算出要连接的主节点。
CRC16算法算出的节点永远小于16383
对同一个key CRC16算法多次运算算出的结果一致
 对不同的一个key CRC16算法结果可能一致。

划重点
从节点选举步骤：
当从节点发现自己复制的主节点已下线了，会向集群里面广播一条消息，要求所有有投票权的节点给自己投票(所有负责处理槽的主节点都有投票权)
主节点会向第一个给他发选举消息的从节点回复支持
当支持数量超过N/2+1的情况下，该从节点当选新的主节点

集群模式和哨兵模式的区别：
哨兵模式监控权交给了哨兵系统，集群模式中是工作节点自己做监控
哨兵模式发起选举是选举一个leader哨兵节点来处理故障转移，集群模式是由其他的master主节点投票来来处理故障转移

欢迎大家一起讨论，一起进步，我在这里风里雨里等你