Redis架构模式

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

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

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

主从模式：

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

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

Sentinel 哨兵模式：

在主从模式的基础上加上哨兵服务，它是一个单独的服务，具体配置在sentinel.conf里，配置完直接启动即可
哨兵会监控向主节点和从节点的服务
如果发现主节点宕机了 哨兵会选举一个从节点作为新的主节点，实现故障转移
宕掉的主节点恢复后成为新的从节点
发现任意一台节点出现问题  Sentinel 可以通过 API 向管理员或者其他应用程序发送通知；
哨兵的设置最好设置成单数，因为他的选举机制是少数服从多数，如果是双数会有选举两个从节点而导致脑裂的可能。
项目连接的是哨兵服务。

优点：
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哨兵节点来处理故障转移，集群模式是在从节点中选举一个新的主节点，来处理故障的转移

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