Redis基础--架构模式

单机模式、主从模式、哨兵模式、集群模式

单机模式

就是安装一个redis，启动起来，业务调用即可；单机模式选择需要根据自己的业务场景去选择，在一个并非必须保证高可用的情况下，可以使用该模式。

优点:

部署简单，成本低；
高性能，不需要数据同步。

缺点：

可靠性低，宕机影响大；
单机高性能受限于CPU的处理能力，Redis单线程。

主从模式

主从复制，是将一台Redis服务器的数据，复制到其他的Redis服务器。

前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。

Redis主从模式.png

redis多机器部署时，这些机器节点会被分成两类，一类是主节点（master节点），一类是从节点（slave节点）。一般主节点可以进行读、写操作，而从节点只能进行读操作。同时由于主节点可以写，数据会发生变化，当主节点的数据发生变化时，会将变化的数据同步给从节点，这样从节点的数据就可以和主节点的数据保持一致了。一个主节点可以有多个从节点，但是一个从节点会只会有一个主节点，也就是所谓的一主多从结构。

主从复制机制

Redis主从复制过程.png

Slave连接Master，发送SYNC命令;
Master接收到SYNC命令后，可以执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
Master使用BGSAVE完后，向所有Slave发送快照文件，并在发送期间继续记录被执行的写命令;
Slave收到快照文件后丢弃所有旧数据，载入收到的快照;
Master快照发送完毕后开始向Slave发送缓冲区中的写命令;
Slave完成对快照的载入，开始接受命令请求，并执行来自Master缓冲区的写命令;(Slave初始化完成)
Master每执行一个写命令就会向Slave发送相同的写命令，Slave接收并执行收到的写命令(Slave初始化完成后的操作)
出现断开重连后，2.8之后的版本会将断线期间的命令传给从数据库，增量复制。

主从刚刚连接的时候，进行全量同步;全同步结束后，进行增量同步。当然，如果有需要，slave在任何时候都可以发起全量同步。Redis的策略是，无论如何，首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

优点：

一旦主节点宕机，从节点 作为主节点的备份可以随时顶上来；
支持主从复制，主机会自动将数据同步到从机，可以进行读写分离，减轻主节点压力；
高可用基石：除了上述作用以外，主从复制还是哨兵模式和集群模式能够实施的基础，因此说主从复制是Redis高可用的基石。

缺点：

不具备自动容错和恢复功能，宕机主备切换需要人工干预；
若主节点突然宕机，存在数据可能不一致的风险；
节点的读写能力都受单机的限制。

哨兵模式

为了解决Redis的主从复制的不支持高可用性能，Redis实现了Sentinel哨兵机制解决方案。由一个或多个Sentinel去监听任意多个主服务以及主服务器下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线的主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已经下线的从服务器，并且Sentinel可以互相监视。

一般为了便于决策选举，使用奇数个哨兵。哨兵可以和Redis机器部署在一起，也可以部署在其他的机器上。多个哨兵构成一个哨兵集群，哨兵直接也会相互通信，检查哨兵是否正常运行，同时发现master宕机哨兵之间会进行决策选举新的master。

Redis哨兵模式.png

哨兵作用

通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器;
当哨兵监测到master宕机，会自动将slave切换到master，然后通过发布订阅模式通过其他的从服务器，修改配置文件，让它们切换主机;
然而一个哨兵进程对Redis服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

哨兵模式的工作

每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令；
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）；
如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态；
当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN），则Master主服务器会被标记为客观下线（ODOWN）；
在一般情况下，每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令；
当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次；
若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

优点：

哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有；
主从可以自动切换，系统更健壮，可用性更高。

缺点：

具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低；
Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

集群模式（Cluster、官方）

从Redis 3.0之后版本支持Redis-Cluster集群，Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。集群是Redis提供的分布式数据库方案，集群通过分片来进行数据共享，并提供复制和故障转移功能。一个Redis集群通常由多个节点组成；最初，每个节点都是独立的，需要将独立的节点连接起来才能形成可工作的集群。

Redis集群模式.png

集群模式的节点Redis 服务分别启动成功之后，这时虽然配置了集群开启，但是这Node节点还是独立的。使用集群管理命令将这些机器添加到一个集群中。

为什么是16384个槽

如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大；
Redis的集群主节点数量基本不可能超过1000个；
槽位越小，节点少的情况下，压缩率高。

运行机制

在 Redis 的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383，可以从上面redis-trib.rb执行的结果看到这16383个slot在三个master上的分布。还有一个就是cluster，可以理解为是一个集群管理的插件，类似的哨兵;
当存取的 Key到达的时候，Redis 会根据 crc16的算法对计算后得出一个结果，然后把结果和16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作;
当数据写入到对应的master节点后，这个数据会同步给这个master对应的所有slave节点;
为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点。当其它主节点ping主节点master 1时，如果半数以上的主节点与master 1通信超时，那么认为master 1宕机了，就会启用master 1的从节点slave 1，将slave 1变成主节点继续提供服务;
如果master 1和它的从节点slave 1都宕机了，整个集群就会进入fail状态，因为集群的slot映射不完整。如果集群超过半数以上的master挂掉，无论是否有slave，集群都会进入fail状态;
redis-cluster采用去中心化的思想，没有中心节点的说法，客户端与Redis节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

优点：

无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层；
数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布；
可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除；
高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本；
实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。

缺点：

资源隔离性较差，容易出现相互影响的情况；
数据通过异步复制，不保证数据的强一致性。