Redis集群与扩展知识点分析

44次阅读

没有评论

共计 3790 个字符，预计需要花费 10 分钟才能阅读完成。

这篇文章主要讲解了“Redis 集群与扩展知识点分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“Redis 集群与扩展知识点分析”吧！

Redis 的高可用 1. 为什么要高可用

防止单点故障，造成整个集群不可用

实现高可用通常的做法是将数据库复制多个副本以部署在不同的服务器上，其中一台挂了也可以继续提供服务

Redis 实现高可用有三种部署模式：主从模式，哨兵模式，集群模式

2. 主从模式

主节点负责读写操作

从节点只负责读操作

从节点的数据来自主节点，实现原理就是主从复制机制

主从复制包括全量复制，增量复制两种

当 slave 第一次启动连接 master，或者认为是第一次连接就采用全量复制

slave 与 master 全量同步之后，master 上的数据如果再次发生更新，就会触发增量复制

3. 哨兵模式

主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址, 显然多数业务场景都不能接受这种故障处理方式,Redis 从 2.8 开始正式提供了 Redis Sentinel(哨兵)架构来解决这个问题

哨兵模式是由一个或多个 Sentinel 实例组成的 Sentinel 系统，可以监视所有的 Redis 主节点和从节点，并在被监视的主节点进入下线状态时自动将下线主服务器属下的某个从节点升级为新的主节点

但是一个哨兵进程对 Redis 节点进行监控，就可能会出现问题(单点)，因此可以使用多个哨兵来进行监控 Redis 节点，并且各个哨兵之间还会进行监控

简单来说，哨兵模式就三个作用

1. 发送命令，等待 Redis 服务器 (包括主服务器和从服务器) 返回监控其运行状态
2. 哨兵监测到主节点宕机会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点修改配置文件，让它们切换主机
3. 哨兵之间还会相互监控，从而达到高可用

故障切换过程如下

假设主服务器宕机，哨兵 1 先检测到这个结果，系统并不会马上进行  failover  过程，仅仅是哨兵 1 主观的认为主服务器不可用，这个现象称为主观下线
当后面的哨兵也检测到主服务器不可用并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行 failover 操作
切换成功后通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线
这样对于客户端而言，一切都是透明的

哨兵的工作模式

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

4.Cluster 集群模式

哨兵模式基于主从模式，实现读写分离，还可以自动切换，系统可用性更高，但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容，因此 Cluster 集群应运而生，它在 Redis3.0 加入的

Cluster 集群实现 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容，来解决在线扩容的问题，并且它也提供复制和故障转移的功能

Redis Cluster 集群通过 Gossip 协议进行通信，节点之间不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot 信息等等，常用的 Gossip 消息分别是 ping、pong、meet、fail

ping 消息：集群内交换最频繁的消息，集群内每个节点每秒向多个其他节点发送 ping 消息，用于检测节点是否在线和交换彼此状态信息
meet 消息：通知新节点加入，消息发送者通知接收者加入到当前集群，meet 消息通信正常完成后，接收节点会加入到集群中并进行周期性的 ping、pong 消息交换
pong 消息：当接收到 ping、meet 消息时，作为响应消息回复给发送方确认消息正常通信；pong 消息内部封装了自身状态数据，节点也可以向集群内广播自身的 pong 消息来通知整个集群对自身状态进行更新
fail 消息：当节点判定集群内另一个节点下线时，会向集群内广播一个 fail 消息，其他节点接收到 fail 消息之后把对应节点更新为下线状态

Hash Slot 插槽算法

既然是分布式存储，Cluster 集群使用的分布式算法是一致性 Hash 嘛？并不是，而是 Hash Slot 插槽算法
插槽算法把整个数据库被分为 16384 个 slot(槽)，每个进入 Redis 的键值对根据 key 进行散列，分配到这 16384 插槽中的一个
使用的哈希映射也比较简单，用 CRC16 算法计算出一个 16 位的值，再对 16384 取模，数据库中的每个键都属于这 16384 个槽的其中一个，集群中的每个节点都可以处理这 16384 个槽
集群中的每个节点负责一部分的 hash 槽，比如当前集群有 A、B、C 个节点，每个节点上的哈希槽数  =16384/3，那么就有：节点 A 负责 0~5460 号哈希槽
 节点 B 负责 5461~10922 号哈希槽
 节点 C 负责 10923~16383 号哈希槽 Redis Cluster 集群中，需要确保 16384 个槽对应的 node 都正常工作，如果某个 node 出现故障，它负责的 slot 也会失效，整个集群将不能工作
为了保证高可用，Cluster 集群引入了主从复制，一个主节点对应一个或者多个从节点，当其它主节点 ping 一个主节点 A 时，如果半数以上的主节点与  A 通信超时，那么认为主节点 A 宕机，如果主节点宕机时，就会启用从节点 Redis 的每一个节点上都有两个玩意，一个是插槽 slot(0~16383)，另外一个是 cluster，可以理解为一个集群管理的插件，当我们存取的 key 到达时，Redis 会根据 Hash Slot 插槽算法取到编号在 0~16383 之间的哈希槽，通过这个值去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

5. 实现高可用后的故障转移问题

主观下线：某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况

客观下线：标记一个节点真正的下线，集群内多个节点都认为该节点不可用，从而达成共识的结果，如果是持有槽的主节点故障，需要为该节点进行故障转移

故障恢复：故障发现后，如果下线节点的是主节点，则需要在它的从节点中选一个替换它，以保证集群的高可用

Redis 分布式锁带来的系列问题及解决 1.Redisson

分布式锁可能存在锁过期释放，业务没执行完的问题

能不能将锁的过期时间设置得长点来解决此问题呢？显然是不太好的，业务的执行时间是不确定的

Redisson 解决该问题，给获得锁得线程开启定时守护线程，每隔一段时间检查锁是否存在，存在则延长锁的过期时间，防止锁过期提前释放

2.Redlock 算法

线程一在 Redis 的 master 节点上拿到了锁，但是加锁的 key 还没同步到 slave 节点，恰好这时 master 节点发生故障，一个 slave 节点就会升级为 master 节点，线程二就可以获取同个 key 的锁啦，但线程一也已经拿到锁了，锁的安全性就没了

Redlock 解决这个问题，即部署多个 Redis master 以保证它们不会同时宕掉，并且这些 master 节点是完全相互独立的，相互之间不存在数据同步，实现步骤如下

MySQL 与 Redis 如何保证双写一致性 1. 延时双删