Redis集群解决方案


redis集群解决方案

  1. 主从复制
  2. 哨兵机制
  3. redis cluster

这三种都可以解决集群问题。区别不在于能否解决集群问题,而在于集群的问题解决的好不好,是否方便。

三种集群的特点

  • 主从复制

工作机制

  1. slave启动后,向master发送SYNC命令,master接收到SYNC命令后通过bgsave保存快照(即RDB持久化),并使用缓冲区记录保存快照这段时间内执行的写命令
  2. master将保存的快照文件发送给slave,并继续记录执行的写命令
  3. slave接收到快照文件后,加载快照文件,载入数据
  4. master快照发送完成后开始向slave发送缓冲区的写命令,slave接收命令并执行,完成复制初始化
  5. 此后master每执行一个写命令都会同步发送给slave,保持master与slave之间的数据一致性

优点:数据备份,读写分离,负载均衡
缺点:不能自动故障恢复

  • 哨兵机制

    Sentinel 基于主从复制模式,会监控多个服务器,当 master 不可用时,会将一个 salve 升级为 master, 并将其他 salve 的主服务器更新为最新的 master。

工作机制:
在配置文件中通过sentinel monitor <master-name> <ip> <redis-port> <quorum>来定位master的IP、端口,一个哨兵可以监控多个master数据库,只需要提供多个该配置项即可。哨兵启动后,会与要监控的master建立两条连接:

  1. 一条连接订阅master的_sentinel_:hello频道与获取其他监控该master的哨兵节点信息;
  2. 另一条连接定期向master发送INFO命令获取master本身的信息
    与master建立连接后,哨兵会执行三个操作:
  3. 定期(一般10s一次,当master被标记为主观下线时,改为1s一次)向master和slave发送INFO命令
  4. 定期向master和slave的_sentinel_:hello频道发送自己的信息
  5. 定期(1s一次)向master、slave和其他哨兵发送PING命令

发送INFO命令可以获取当前数据库的相关信息从而实现新节点的自动发现。所以哨兵只需要配置master数据库信息就可以自动发现其slave信息。获取到slave信息后,哨兵也会与slave建立两条连接执行监控。通过INFO命令,哨兵可以获取主从数据库的最新信息,并进行相应的操作。

接下来哨兵向主从数据库的_sentinel_:hello频道发送信息与同样监控这些数据库的哨兵共享自己的信息,发送内容为哨兵的ip端口、运行id、配置版本、master名字、master的ip端口还有master的配置版本。这些信息有以下用处:

  1. 其他哨兵可以通过该信息判断发送者是否是新发现的哨兵,如果是的话会创建一个到该哨兵的连接用于发送PING命令。
  2. 其他哨兵通过该信息可以判断master的版本,如果该版本高于直接记录的版本,将会更新
  3. 当实现了自动发现slave和其他哨兵节点后,哨兵就可以通过定期发送PING命令定时监控这些数据库和节点有没有停止服务。

如果被PING的数据库或者节点超时(通过sentinel down-after-milliseconds master-name milliseconds 配置)没有回复,哨兵会认为其主观下线(sdown,s为Subjectibely)。如果下线的是master,哨兵会向其他哨兵发送命令询问他们是否也认为该master主观下线,如果达到一定数目(即配置文件中的quorum)投票,哨兵会认为该master已经客观下限(odown,o即Objectively),并选举领头的哨兵节点对主从系统发起故障恢复。若没有足够的sentinel进程同意master下线,master的客观下线状态会被移除,若master重新向sentinel进程发送的PING命令返回有效回复,master的主观下线就被移除。

总结:如果master节点超时,哨兵会认为该master主观下线,会向其他哨兵发送命令询问是否同意该master下线,如果达到一定数目投票,则认为该master客观下线,并选举新的领头哨兵进行故障恢复。

哨兵认为master客观下线后,故障恢复的操作需要由选举的领头哨兵执行,选举采用Raft算法

  1. 发现master下线的哨兵节点(A)向每个哨兵发送命令,要求对方选自己为领头哨兵
  2. 如果目标哨兵节点没有选过其他人,则会同意选择A为领头哨兵
  3. 如果有超一般的哨兵同意选择A为领头,则A当选
  4. 如果有多个哨兵同时参选领头,此时有可能存在一轮投票没有哨兵胜出,此时每个参选的节点等待一个随机时间后再次发起参选请求,进行下一轮投票竞选,直至选出领头哨兵

选出领头哨兵后,领头者开始对系统进行故障恢复,从出现故障的master的slave节点中挑选一个当选新的master,规则如下:

  1. 所有在线的slave中选择优先级最高的,优先级可以通过slave-priority配置;
  2. 如果有多个最高优先级的slave,则选取复制偏移量最大(即复制最完整)当选;
  3. 如果以上条件都一样,选取id最小的slave

挑选出要继任的slave后,领头哨兵向该数据库发送命令使其升级为master,然后再向其他slave发送命令接受新的master,最后更新数据。将停止的旧的master更新为新的master的slave,恢复服务后继续以slave身份继续运行。

优点:解决自动故障恢复的问题
缺点:不能解决负载均衡的问题

  • redis cluster

    cluster实现了redis的分布式存储,即每台节点存储不同的内容,来解决在线扩容的问题

cluster采用无中心结构,特点如下:

  1. 所有redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和宽带
  2. 节点的fail是通过集群中超过半数的节点检测失效时才生效
  3. 客户端与redis节点直连,不需要中间代理层,客户端不需要连接集群所有节点,连接及群众任意一个可用节点即可

cluster模式的工作机制

  1. 在redis每个节点上,都有一个插槽(slot),取值范围为0~16383
  2. 当我们存取key的时候,redis会根据CRC16算法得出一个结果,然后把结果对16383求余数,这样每个key都会对应一个编号在0~16383之间的哈希槽,通过这个值,去找对应的插槽所对应的节点,然后直接自动跳转到这个对于节点上进行存取操作;
  3. 为了保证高可用,cluster模式也引入了主从复制模式,一个主节点对应一个从节点,主节点宕机,就会启用从节点;
  4. 其他主节点ping一个主节点A时,如果半数以上的主节点与A通信超时,那么认为主节点A宕机了。如果主节点A和它的从节点都宕机,则该集群无法再提供服务了。

优点:解决负载均衡问题,在线扩容。具体解决方案是分片/虚拟槽slot

redis三种集群有什么区别?分别有什么特点?适用于什么场景?实际工作如何选择?

主从模式:备份数据、负载均衡,一个master可以有多个slaves;
哨兵模式:发现master挂了之后,就会从slave中重新选择一个master;
cluster:为了解决单机redis容量有限的问题,将数据按一定的规则分配到多台机器
哨兵着重高可用,cluster提高并发量




Enjoy Reading This Article?

Here are some more articles you might like to read next:

  • 2379. Minimum Recolors to Get K Consecutive Black Blocks
  • 2471. Minimum Number of Operations to Sort a Binary Tree by Level
  • 1387. Sort Integers by The Power Value
  • 2090. K Radius Subarray Averages
  • 2545. Sort the Students by Their Kth Score