Redis

香港十大金曲
240 阅读13分钟

redis的备份方式

RDB (redis database redis数据库快照)

触发命令

  1. SAVE
    1. 阻塞
  2. BGSAVE
    1. 另起子线程，不会阻塞
// redisServer 结构中包括属性saveParams-- 可以用来指定BGSAVE的执行时间
struct redisServer {
    //...
    struct saveParam *saveParams;
    //修改计数器
    long dirty;
    //上次执行保存的时间
    time_t lastSave;
    //...
}

struct saveParam{
    time_t seconds; //秒数
    int changes;    //修改次数
}

按照上面的结构体可以看出，我们可以根据秒数和修改次数触发BGSAVE

save 900 1  ===> 900s内数据库执行了超过1次修改，触发BGSAVE

触发条件判断

 def serverCron(){
     for(saveParam in server.saveParams){
         //距离上次保存的时间间隔
         saveInterval = now - server.lastSave;
         
         if(server.dirty > saveParam.changes && saveInterval > saveParam.seconds){
             BGSAVE(); //执行BGSAVE
         }
     }
 }

AOF (append only file)

struct redisServer{
    //...
    //AOF缓冲区
    sds aof_buf;
    //...
}

redis会在执行命令后会将写命令加入aof_buf缓冲区中

Redis 服务器进程就是一个事件循环(loop)

def eventLoop():
    while true:
        //处理文件事件，接受命令并发送命令回复
        //期间写入操作会加入到aof_buf缓存中
        processFileEvents();
        
        //处理时间时间  执行serverCoron之类的定时运行的函数
        processTimeEvents();
        
        //判断是否需要将aof_buf中的内容写入和同步到AOF文件中
        flushAppendOnlyFile;
名称 含义
写入 调用write函数，操作系统通常会将内容暂时保存在内存缓冲区中
同步 缓冲区空间满了或者时间到了或者特殊设置情况下将缓冲区中的内容写入磁盘中
  • redis AOF写入和同步的时间配置
appendfsync选项值 写入行为
always 每次执行时都会讲aof_buf缓冲区内容写入并同步到AOF文件，
1. 效率低
2. 最安全，最多丢失一个eventLoop内产生的数据
everysec 会将aof_buf内容写入AOF中，如果上次同步时间超过1S就会做AOF文件的同步
no 会将aof_buf内容写入AOF中，但是何时进行同步需要依赖操作系统
1.执行效率最高
2.如果宕机,丢失的数据会是最多的

AOF重写节约空间

AOF的意思是将写操作命令追加到AOF文件最后，难免会出现一个key反复被操作，就会出现很多冗余的命令，文件就会变得很大。
AOF重写就是按照当前数据库中的kv,重新生成一份AOF文件，那么不管中间出现过多少次的反复操作，在重写的AOF文件中，只会存在一条。做到节约空间

def aof_rewrite(new_aof_file_name):
    // 创建新的AOF文件
    f = createFile(new_aof_file_name);
    for db in redisServer.db:
        // 忽略空的db
        f.write_command("SELECT" + db.id)
        
        //遍历db中的键
        for key in db:
            //忽略过期的键
            if(key.is_expried):continue;
            
            //按照不同类型生成命令，写入新的文件中
            //......
            
            //如果key有有效期，重写过期命令
            if(key.have_expire_time()):
                rewrite_exire_time(key)
    
    // 关闭文件
    f.close()

AOF后台重写

AOF重写涉及到大量的写入操作，所以需要单独启动子进程进行操作

  1. 子进程进行AOF重写的时候，父进程还可以继续处理命令请求

问题：在子进程进行AOF重写的时候，父进程还在处理命令，那么AOF重写完成之后，还是会出现数据不一致

redis的处理方式是，定义一个AOF重写缓冲区，
在子进程进行AOF重写的时候，执行的写命令会被加入到这个AOF重写的缓冲区，在子进程完成AOF重写通知父进程后，父进程会将AOF重写缓冲区内容加入到新出现的这个AOF文件中

RDB和AOF比较

  1. RDB同步只能间隔着操作，AOF可以做到实时
  2. RDB文件会相对比较小，AOF如果没有重写会相对比较大
  3. 启动时如果AOF持久化功能是开启的，会优先载入AOF文件

redis的主从复制

  1. 成为从服务器的命令: SLAVEOF

复制功能分为 同步 + 命令传播

同步：将从服务器的状态更新到主服务器的状态(只在建立连接的时候) 命令传播:同步完成之后，主服务器接收到命令，导致的主从双方不一致的情况，通过命令的传播来维持主从的一致性

同步功能的实现

  1. SYNC命令(旧版本的复制功能)=完整的重同步
  2. PSYNC命令(新版本的复制功能)=完整重同步+部分重同步
旧版的SYNC操作
  1. 从服务器发送SYNC命令
  2. 主服务器收到SYNC命令后，执行BGSAVE命令，生成RDB文件(这个RDB文件仅记录到执行BGSAVE命令时的数据库状态)，并且创建一个缓存区将从现在开始的写命令写进来
  3. 从服务器加载RDB文件，恢复到主服务器开始BGSAVE时的状态
  4. 主服务器将缓冲区的命令发送给从服务器，保证生成RDB文件时的写命令也能被完整执行

旧版SYNC的缺点:只有单纯的完整重同步导致断开连接后重连上来的从服务器也必须要让主服务器重新生成RDB文件。
1.生成RDB文件影响性能
2. 传输RDB文件增加网络负担

所以在新版本的PSYNC命令中增加了部分重同步的操作

新版的PSYNC

从服务器断开连接后重新连接的主服务器如果还是原来的那台，并且中间两者相差的命令查的不多，可以仅对中间相差的命令做部分的重同步

  1. 主从服务器各自维护一个偏移量offset
  2. 主服务器每次向从服务器复制N个字节的数据时，就将自己的offset增加N
  3. 从服务器接收到N个字节的数据时，就将自己的offset增加N
  4. 通过这两个offset就可以知道主从服务器之间相差的偏差了

PSYNC的复制积压缓存区：主服务器维护一个先进先出(FIFO)的固定长度的队列(默认1MB),主服务器在复制给从服务器的时候，也会往这个队列里面存放数据。其中每一个字节都有对应的偏移量offset(和主从服务器维护的offset一个概念) 5. 当PSYNC命令时，发现主从服务器有偏差，并且从服务器当前的offset还在这个复制积压缓存区的话，就可以使用部分重同步了

PSYNC命令 PYSNC
runid:本从服务器上次同步的主服务id,用来比较是不是断开前连接的是本主服务器，如果不是，直接完整重同步
offset:从服务器当前的offset,用来判断是否使用部分重同步

复制的实现步骤

  1. 设置需要同步的主服务器
    SLAVEOF ip port
  2. 建立socket
  3. 发送PING命令确认连接是否正常
  4. 身份验证
  5. 发送端口命令 --告诉主服务器自己的监听端口（不知道啥作用）
  6. 同步 PSYNC
  7. 命令传播
  8. 心跳检测
    1. 检查网络连接状态
    2. 检测命令丢失（传递offset）
    3. 辅助实现 min-slaves (还不知道怎么实现)

redis的高可用架构

哨兵模式

哨兵模式是redis高可用的实现方式之一 使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控，在主节点出现故障的情况下，能将从节点中的一个升级为主节点，进行故障转义，保证系统的可用性。

redis哨兵模式.png

哨兵们是怎么感知整个系统中的所有节点(主节点/从节点/哨兵节点)的

  1. 首先主节点的信息是配置在哨兵(Sentinel)的配置文件中
  2. 哨兵节点会和配置的主节点建立起两条连接命令连接和订阅连接
  3. 哨兵会通过命令连接每10s发送一次INFO命令，通过INFO命令，主节点会返回自己的run_id和自己的从节点信息
  4. 哨兵会对这些从节点也建立两条连接命令连接和订阅连接
  5. 哨兵通过命令连接向从节点发送INFO命令，获取到他的一些信息 a. run_id b. role c. 从服务器的复制偏移量 offset d. 等
  6. 因为哨兵对与集群中的其他节点(主从节点)当前都有两条连接，命令连接和订阅连接 a. 通过命令连接向服务器的_sentinel:hello频道发送一条消息，内容包括自己的ip端口、run_id、配置纪元(后续投票的时候会用到)等 b. 通过订阅连接对服务器的_sentinel:hello频道做了监听，所以所有的向该频道发送的哨兵的消息都能被接受到 c. 解析监听到的消息，进行分析提取，就可以知道还有那些别的哨兵服务节点也在监听这些主从节点了，更新结构体将这些哨兵节点记录下来 d. 向观察到的其他的哨兵节点建立命令连接----没有订阅连接

哨兵模式下的故障迁移

主观下线

哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/LOADING/MASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI_S_DOWN主观下线

客观下线

当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRI_O_DOWN客观下线 询问命令SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>

参数 意义
ip/port 当前认为下线的主节点的ip和端口
current_epoch 配置纪元
run_id *标识仅用于询问是否下线
有值标识该哨兵节点希望对方将自己设置为leader
询问时用*，选举时用run_id
leader选举

在认为主节点客观下线的情况下,哨兵节点节点间会发起一次选举，命令还是上面的命令SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>,只是run_id这次会将自己的run_id带进去，希望接受者将自己设置为主节点。如果超过半数以上的节点返回将该节点标记为leader的情况下，会有该leader对故障进行迁移

故障迁移
  1. 在从节点中挑选出新的主节点 a. 通讯正常 b. 优先级排序 c. 优先级相同是选择offset最大的
  2. 将该节点设置成新的主节点 SLAVEOF no one,并确保在后续的INGO命令时，该节点返回状态为master
  3. 将其他的从节点设置成从新的主节点复制, SLAVEOF命令
  4. 将旧的主节点变成新的主节点的从节点

优缺点

  • 优点 高可用，在主节点故障时能实现故障的转移
  • 缺点：好像没办法做到水平拓展，如果内容很大的情况下

集群模式

官方提供的分布式方案(槽指派/重新分片/故障转移) 集群内的节点，都会有个数据结构存储整个集群内的节点信息

//整体
struct clusterState{
  clusterNode *mySelf;
  ....
  dict *nodes;  //集群内的所有节点
}

// 单个节点
struct clusterNode {
  char name[];
  char ip[];
  int port;
  clusterLink *link;  //保存节点间，连接的信息
  int flags;    //状态标记
}

//节点间连接的信息
struct clusterLink{
  mstime_t ctime;  //创建时间
  int fd; //tcp套接字描述符
  sds sndbuf;  // 输出缓存区
  sds rcvbuf;  //输入缓存区
  struct clusterNode *node;
}

redis集群结构体.jpg

槽指派

redis集群可以被分为16384个槽，只有这些槽全被指派了处理的节点的情况下，集群的状态才能是上线状态(ok) 操作redis集群的时候，将key作为参数，就可以计算出对应的处理槽上，所以存储等操作都应该在该槽对应的节点上。通过这种方式，可以完美的实现集群存储的水平拓展。

def slot_number(key):
  return CRC16(key) & 16383
//得到的结果就是槽的序号

槽指派的信息是怎么存储的

struct clusterState{
  clusterNode *slots[16384]
 }

struct clusterNode{
  unsigned char slots[16384/8]
}

通过上面两个结构体中的定义可以看出，槽指派的信息是分了两种方式，保存在结构体里面。

方式一.png
方式二.png

分两种存储的好处
1. 如果需要判断某一个节点负责的槽，只需要获取方式二中的数组做判断就可以
2.如果找某个槽是哪个节点负责，只需要获取方式一的列表，一查就知道

重新分片

将已经指派给节点的槽，重新执行新的节点。

redis重新分片过程中可能遇到的问题.jpg

故障转移

发现故障节点
  1. 集群内的节点会向其他节点发送PING命令，检查是否在线
  2. 如果未能在规定时间内做出PONG响应，则会把对应的节点标记为疑似下线
  3. 集群中一半以上负责处理槽的主节点都将主节点X标记为疑似下线的话，那么这个主节点X就会被认为是已下线
  4. 向集群广播主节点X已下线,大家收到消息后都会把自己维护的结构体里的主节点X标记为已下线
从节点选举
  1. 当从节点发现自己复制的主节点已下线了，会向集群里面广播一条消息，要求所有有投票权的节点给自己投票(所有负责处理槽的主节点都有投票权)
  2. 主节点会向第一个给他发选举消息的从节点回复支持
  3. 当支持数量超过N/2+1的情况下，该从节点当选新的主节点
故障的迁移
  1. 新当选的从节点执行 SLAVEOF no one,修改成主节点
  2. 新的主节点会撤销所有已下线的老的主节点的槽指派，指派给自己
  3. 新的主节点向集群发送命令，通知其他节点自己已经变成主节点了，负责哪些槽指派
  4. 新的主节点开始处理自己负责的槽的命令

集群模式和哨兵模式的区别

  1. 哨兵模式监控权交给了哨兵系统，集群模式中是工作节点自己做监控
  2. 哨兵模式发起选举是选举一个leader哨兵节点来处理故障转移，集群模式是在从节点中选举一个新的主节点，来处理故障的转移
avatar
文章
阅读
粉丝