我的程序员修炼日记

Redis架构知识梳理

2019-10-22  本文已影响0人  一岁一枯荣啊

Redis架构知识梳理

作者写的很好，自己懒得写。按照作者的思路梳理了一遍

引用原文入口：https://zhuanlan.zhihu.com/p/60632927

引用原文入口：https://www.cnblogs.com/51life/p/10233340.html

redis save和bgsave区别

Redis持久化使用的是RDB快照模式，Redis在一定的时间间隔会进行生成RDB文件持久化数据，手动进行持久化的话可以使用save或者bgsave

Save:该命令将在 redis 安装目录中创建dump.rdb文件。这个命令会调用 rdbSave函数 ，函数执行期间会阻塞 Redis 主进程，阻塞期间，服务器不处理客户端的请求。谨慎使用

bgsave:客户端可以通过 LASTSAVE 命令查看相关信息，判断 BGSAVE 命令是否执行成功。

bgsave 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

BGSAVE方式比较适合线上的维护操作。

1.主从复制

优点：

缺点：

2.哨兵模式

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

（1）监控主服务器和从服务器是否正常运行。 （2）主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式：

哨兵模式的优缺点

优点：

缺点：

Redis Sentinel 哨兵-选举领头Sentinel和故障转移

选举领头Sentinel

当一个Master服务器客观下线后，监控这个Master服务器的所有Sentinel将会选举出一个领头Sentinel。并由领头Sentinel对客观下线的Master进行故障转移。

选举领头Sentinel的规则和方法

  1. 所有监控客观下线Master的Sentinel都有可能成为领头Sentinel。
  1. 每次进行领头Sentinel选举之后，不论是否选举成功，所有Sentinel的配置纪元（configuration epoch）的值都会自动增加一次。
  1. 在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头Sentinel一旦设置，在这个配置纪元里面将不能再更改。
  1. 监视Master客观下线的所有在线Sentinel都有要求其它Sentinel将自己设置为局部领头Sentinel的机会。
  1. 当一个Sentinel（源Sentinel）向另一个Sentinel（目标Sentinel）发送SENTINEL is-master-down-by-addr命令，并且命令中的runid参数不是“.”符号而是当前Sentinel的运行ID时，这表示当前Sentinel要求目标Sentinel将自己设置为领头Sentinel。
  1. Sentinel设置局部领头Sentinel的规则是先到先得。即最先向目标Sentinel发送设置要求的Sentinel将会成为局部领头Sentinel，之后接受到的请求都会被拒绝。
  1. 目标Sentinel接收到SENTINEL is-master-down-by-addr命令后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元。
  1. 源Sentinel在接收到目标Sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么源Sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID一直，那么表示目标Sentinel将源Sentinel设置成了局部领头Sentinel。
  1. 如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel，那么这个Sentinel称为领头Sentinel。
  1. 领头Sentinel的产生需要半数以上的Sentinel支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部Sentinel，所以在一个配置纪元里面，只会出现一个领头Sentinel。
  1. 如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，知道选出领头Sentinel为止。
## 故障转移



故障转移包括以下三步：


1.  在已下线的Master主机下面挑选一个Slave将其转换为主服务器。
    
    
2.  让其余所有Slave服务器复制新的Master服务器。
    
    
3.  让已下线的Master服务器变成新的Master服务器的Slave。当已下线的服务器在此上线后将复新的Master的数据。
    
    

### 选举新的主服务器



领头Sentinel会在所有Slave中选出新的Master，发送SLAVEOF no one命令，将这个服务器确定为主服务器。



领头Sentinel会将已下线Master的所有从服务器报错在一个列表中，按照规则进行挑选。


1.  删除列表中所有处于下线或者短线状态的Slave。
    
    
2.  删除列表中所有最近5s内没有回复过领头Sentinel的INFO命令的Slave。
    
    
3.  删除所有与下线Master连接断开超过down-after-milliseconds * 10毫秒的Slave。
    
    
4.  领头Sentinel将根据Slave优先级，对列表中剩余的Slave进行排序，并选出其中优先级最高的Slave。如果有多个具有相同优先级的Slave，那么领头Sentinel将按照Slave复制偏移量，选出其中偏移量最大的Slave。如果有多个优先级最高，偏移量最大的Slave，那么根据运行ID最小原则选出新的Master。
    
    

确定新的Master之后，领头Sentinel会以每秒一次的频率向新的Master发送SLAVEOF no one命令，当得到确切的回复role由slave变为master之后，当前服务器顺利升级为Master服务器。



### 修改从服务器的复制目标



当选出新的Master服务器后，领头Sentinel会让之前下线Master的Slave发送SLAVEOF命令，让它们复制新的Master。



### 将旧的Master变成Slave



当已下线的Master重新上线后，领头Sentinel会向此服务器发送SLAVEOF命令，将当前服务器变成新的Master的Slave。

3.Redis-Cluster集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

Redis-Cluster采用无中心结构,它的特点如下：

工作方式：

在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

业界缓存设计问题

上一篇下一篇

猜你喜欢

热点阅读