IT序号网

redis--AOF知识解答

developer 2021年06月13日 数据库 141 0
Redis 分别提供了 RDB 和 AOF 两种持久化机制:
  • RDB 将数据库的快照( snapshot)以二进制的方式保存到磁盘中。
    • 相当于MySQL binlog 的 raw模式
  • AOF 则以协议文本的方式,将所有对数据库进行过写入的命令(及其参数)记录到 AOF
    • 相当于MySQL binlog 的 satement模式
文件,以此达到记录数据库状态的目的。
 
 
AOF命令同步

Redis 将所有对数据库进行过写入的命令(及其参数)记录到 AOF 文件,以此达到记录数据库状态的目的。
为了处理的方便,AOF 文件使用网络通讯协议的格式来保存这些命令。
 
同步命令到 AOF 文件的整个过程可以分为三个阶段:
 
  • 命令传播:
    • Redis将执行完的命令、命令的参数、命令的参数个数等信息发送到AOF程序中。
  • 缓存追加:
    • AOF程序根据接收到的命令数据,将命令转换为网络通讯协议的格式,然后将协议内容追加到服务器的AOF缓存中。
  • 文件写入和保存:
    • AOF缓存中的内容被写入到AOF文件末尾,如果设定的AOF保存条件被满足的话,
    • fsync函数或者fdatasync函数会被调用,将写入的内容真正地保存到磁盘中
 
命令传播过程
if (execRedisCommand(cmd, argv, argc) == EXEC_SUCCESS): 
     if aof_is_turn_on(): 
          # 传播命令到 AOF 程序 
          propagate_aof(cmd, argv, argc) 
  
     if replication_is_turn_on(): 
          # 传播命令到 REPLICATION 程序 
          propagate_replication(cmd, argv, argc) 
 
缓存追加
当命令被传播到 AOF 程序之后,程序会根据命令以及命令的参数,将命令从字符串对象转换回原来的协议文本。
redisServer 结构维持着 Redis 服务器的状态,
aof_buf域则保存着所有等待写入到AOF文件的协议文本:
 
缓存追加过程分为三步:
  • 接受命令、命令的参数、以及参数的个数、所使用的数据库等信息
  • 将命令还原成 Redis 网络通讯协议
  • 将协议文本追加到 aof_buf ( Redis 中 AOF 缓存)末尾
 
文件写入和保存
每当服务器常规任务函数被执行、或者事件处理器被执行时,aof.c/flushAppendOnlyFile 函数都会被调用,
这个函数执行以下两个工作:
  • WRITE:根据条件,将 aof_buf 中的缓存写入到 AOF文件
    • AOF 文件相当于MySQL redo log 缓存,然后使用一些策略,提升持久化到磁盘的效率
    • 因为AOF 是后台进程,此时AOF 文件 是后台进程的 缓存
  • SAVE:根据条件,调用 fsync 或 fdatasync 函数,将 AOF 文件保存到磁盘中。
 
AOF 保存模式

Redis 目前支持三种 AOF 保存模式,它们分别是:
AOF_FSYNC_NO :不保存。
AOF_FSYNC_EVERYSEC :每一秒钟保存一次。
AOF_FSYNC_ALWAYS :每执行一个命令保存一次
 
不保存
每次调用 flushAppendOnlyFile 函数,WRITE 都会被执行,但 SAVE会被略过
在这种模式下,SAVE 只会在以下任意一种情况中被执行:
  • Redis 被关闭
  • AOF功能被关闭
  • 系统的写缓存被刷新(可能是缓存已经被写满,或者定期保存操作被执行)
这三种情况下的 SAVE 操作都会引起 Redis 主进程阻塞。
 
每秒保存一次
 
在这种模式中,SAVE 原则上每隔一秒钟就会执行一次,
因为SAVE操作是由后台子线程调用的,所以它不会引起服务器主进程阻塞。
 
"原则上", 在实际运行中,程序在这种模式下对 fsync或 fdatasync 的调用并不是每秒一次,
它和调用flushAppendOnlyFile函数时Redis所处的状态有关。
 
每当 flushAppendOnlyFile 函数被调用时,可能会出现以下四种情况:
  • 子线程正在执行 SAVE ,并且:
    • 1. 这个 SAVE 的执行时间未超过 2 秒,那么程序直接返回,并不执行 WRITE 或新的SAVE 。
      • 在情况 1 中发生故障停机,那么用户最多损失小于 2 秒内所产生的所有数据。
    • 2. 这个 SAVE 已经执行超过 2 秒,那么程序执行 WRITE ,但不执行新的 SAVE 。
      • 注意,因为这时 WRITE 的写入必须等待子线程先完成(旧的) SAVE ,因此这里WRITE 会比平时阻塞更长时间
      • 在情况 2 中发生故障停机,那么用户损失的数据是可以超过 2 秒的。
  • 子线程没有在执行 SAVE ,并且:
    • 3. 上次成功执行 SAVE 距今不超过 1 秒,那么程序执行 WRITE ,但不执行 SAVE 。
    • 4. 上次成功执行 SAVE 距今已经超过 1 秒,那么程序执行 WRITE 和 SAVE 。
 
Redis 官网上所说的,AOF 在“每一秒钟保存一次”时发生故障,只丢失 1 秒钟数据的说法,实际上并不准确。
 
流程图来说明
 
每执行一个命令保存一次
  • 每次执行完一个命令之后,WRITE 和 SAVE 都会被执行。
  • 另外,因为 SAVE 是由 Redis 主进程执行的
    • 所以在SAVE执行期间,主进程会被阻塞,不能接受命令请求
 
 
AOF 保存模式对性能和安全性的影响
对于三种 AOF 保存模式,它们对服务器主进程的阻塞情况如下:
  • 不保存( AOF_FSYNC_NO):
    • 写入和保存都由主进程执行,两个操作都会阻塞主进程。
  • 每一秒钟保存一次( AOF_FSYNC_EVERYSEC):
    • 写入操作由主进程执行,阻塞主进程。
    • 保存操作由子线程执行,不直接阻塞主进程,但保存操作完成的快慢会影响写入操作的阻塞时长。
  • 每执行一个命令保存一次( AOF_FSYNC_ALWAYS):和模式 AOF_FSYNC_NO 一样。
 
因为阻塞操作会让 Redis 主进程无法持续处理请求,所以一般说来,阻塞操作执行得越少、完成得越快,Redis 的性能就越好。
所以说Redis 还是不能保证数据完全不丢失
 
AOF 文件的读取和数据还原
AOF 文件保存了 Redis 的数据库状态,而文件里面包含的都是符合 Redis 通讯协议格式的命令文本。
这也就是说,只要根据 AOF 文件里的协议,重新执行一遍里面指示的所有命令,就可以还原Redis 的数据库状态了。
 
Redis 读取 AOF 文件并还原数据库的详细步骤如下:
  • 创建一个不带网络连接的伪客户端( fake client)。
  • 读取 AOF 所保存的文本,并根据内容还原出命令、命令的参数以及命令的个数。
  • 根据命令、命令的参数和命令的个数,使用伪客户端执行该命令。
  • 执行 2 和 3 ,直到 AOF 文件中的所有命令执行完毕。
完成第 4 步之后,AOF 文件所保存的数据库就会被完整地还原出来
 
注意,因为 Redis 的命令只能在客户端的上下文中被执行,因此创建一个伪客户端
 
读取和还原过程伪代码:
 
def READ_AND_LOAD_AOF(): 
  
     # 打开并读取 AOF 文件 
     file = open(aof_file_name) 
     while file.is_not_reach_eof(): 
  
          # 读入一条协议文本格式的 Redis 命令 
          cmd_in_text = file.read_next_command_in_protocol_format() 
  
          # 根据文本命令,查找命令函数,并创建参数和参数个数等对象 
          cmd, argv, argc = text_to_command(cmd_in_text) 
  
          # 执行命令 
          execRedisCommand(cmd, argv, argc) 
  
     # 关闭文件 
     file.close() 
 
当程序读入这个 AOF 文件时,它首先执行 SELECT 命令,确保数据还原到正确的数据库上。
 
AOF 重写

所谓的“重写”其实是一个有歧义的词语,实际上,AOF 重写并不需要对原有的 AOF 文件进行
任何写入和读取,它针对的是数据库中键的当前值。
 
例子:
SADD animal cat // {cat} 
SADD animal dog panda tiger // {cat, dog, panda, tiger} 
SREM animal cat // {dog, panda, tiger} 
SADD animal cat lion // {cat, lion, dog, panda, tiger} 
 
实际上可以用
SADD animal cat lion dog panda tiger 一条命令替代; 这比之前的四条命令调用要大大减少。
 
根据键的类型,使用适当的写入命令来重现键的当前值,这就是 AOF 重写的实现原理。
重写过程:定期获取某个键的实际值,然后写入通过命令 + 参数 + 值 写入到AOF文件中;
 
伪代码:
def AOF_REWRITE(tmp_tile_name): 
  
     f = create(tmp_tile_name) 
  
     # 遍历所有数据库 
     for db in redisServer.db: 
  
     # 如果数据库为空,那么跳过这个数据库 
     if db.is_empty(): continue 
  
     # 写入 SELECT 命令,用于切换数据库 
     f.write_command("SELECT " + db.number) 
  
     # 遍历所有键 
     for key in db: 
          # 如果键带有过期时间,并且已经过期,那么跳过这个键 
          if key.have_expire_time() and key.is_expired(): continue 
          
          if key.type == String: 
  
               # 用 SET key value 命令来保存字符串键 
               value = get_value_from_string(key) 
  
               f.write_command("SET " + key + value) 
          
          elif key.type == List: 
  
               # 用 RPUSH key item1 item2 ... itemN 命令来保存列表键 
               item1, item2, ..., itemN = get_item_from_list(key) 
  
               f.write_command("RPUSH " + key + item1 + item2 + ... + itemN) 
          
          elif key.type == Set: 
  
               # 用 SADD key member1 member2 ... memberN 命令来保存集合键 
               member1, member2, ..., memberN = get_member_from_set(key) 
  
               f.write_command("SADD " + key + member1 + member2 + ... + memberN) 
  
          elif key.type == Hash: 
               
               # 用 HMSET key field1 value1 field2 value2 ... fieldN valueN 命令来保存哈希键 
               field1, value1, field2, value2, ..., fieldN, valueN =get_field_and_value_from_hash(key) 
               
               f.write_command("HMSET " + key + field1 + value1 + field2 + value2 + fieldN + valueN) 
          elif key.type == SortedSet: 
  
               # 用 ZADD key score1 member1 score2 member2 ... scoreN memberN 
               
               # 命令来保存有序集键 
               score1, member1, score2, member2, ..., scoreN, memberN = get_score_and_member_from_sorted_set(key) 
  
               f.write_command("ZADD " + key + score1 + member1 + score2 + member + scoreN + memberN) 
          
          else: 
               raise_type_error() 
  
          # 如果键带有过期时间,那么用 EXPIREAT key time 命令来保存键的过期时间 
  
          if key.have_expire_time(): 
               f.write_command("EXPIREAT " + key + key.expire_time_in_unix_timestamp()) 
     # 关闭文件 
     f.close() 
 
AOF 后台重写
 
上面AOF重写程序,是在主程序被调用的,会阻塞服务器请求处理,
这是不希望看到的,于是将AOF重写放到(后台)子程序执行是必要的
好处是:
  • 子进程进行 AOF 重写期间,主进程可以继续处理命令请求
  • 子进程带有主进程的数据副本,使用子进程而不是线程,可以在避免锁的情况下,保证数据的安全性。
 
问题
  • 数据不一致性
    • 因为子进程在进行AOF重写期间,主进程还需要处理命令
    • 这就可能造成数据库当前数据和重写后的AOF文件数据不一致
 
解决
  • Redis增加了一个AOF重写缓存,这个缓存在fork出子进程之后开始启用。
  • Redis主进程在接到新的写命令之后,处理会将这个命令的协议内容追加AOF重写缓存
    • 追加到现有AOF文件,就是遵循原本逻辑 命令传递->追加缓存->文件保存和写入
  • 还会追加到这个缓存中:
 
图解
 
 
这样一来
  • 现有的AOF功能会继续执行
  • 所有对数据库进行修改的命令都会被记录到AOF重写缓存中。
 
当子进程完成AOF重写之后并生成新的AOF文件,它会向父进程发送一个完成信号,
父进程会调用一个函数:
  • 将AOF重写缓存中的内容全部写入到新AOF文件中
    • 完成之后,现有AOF文件,新AOF文件和数据库三者的状态完全一致
  • 对新的AOF文件进行改名,覆盖原有的AOF文件。
    • 程序完成新旧两个AOF文件交替
 
整个AOF后台重写过程中,只有最后的写入缓存和改名操作会造成主进程阻塞
(和pt-online-schema-change 相似)
 
上面就是AOF后台重写,也是BGREWRITEAOF命令的工作原理。
 
AOF后台重写的意义,就在与除去了很多中间操作,在数据库恢复的时候,效率会很高。
 
AOF 后台重写的触发条件
 
AOF重写可以由用户通过调用BGREWRITEAOF 手动触发
 
另外,服务器在 AOF 功能开启的情况下,会维持以下三个变量:
  • 记录当前 AOF 文件大小的变量 aof_current_size
  • 记录最后一次 AOF 重写之后,AOF 文件大小的变量 aof_rewirte_base_size
  • 增长百分比变量 aof_rewirte_perc
 
每次当 serverCron 函数执行时,检查是否全部满足以下条件
  • 没有 BGSAVE 命令在进行。
  • 没有 BGREWRITEAOF 在进行
  • 当前 AOF 文件大小大于 server.aof_rewrite_min_size (默认值为 1 MB)
  • 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。
 
默认情况下,增长百分比为 100% ,也即是说,如果前面三个条件都已经满足,并且当前 AOF
文件大小比最后一次 AOF 重写时的大小要大一倍的话,那么触发自动 AOF 重写
 
小结
  • AOF 文件通过保存所有修改数据库的命令来记录数据库的状态。
  • AOF 文件中的所有命令都以 Redis 通讯协议的格式保存。
  • 不同的 AOF 保存模式对数据的安全性、以及 Redis 的性能有很大的影响。
  • AOF 重写的目的是用更小的体积来保存数据库状态,整个重写过程基本上不影响 Redis主进程处理命令请求。
  • AOF 重写是一个有歧义的名字,实际的重写工作是针对数据库的当前值来进行的,程序既不读写、也不使用原有的 AOF 文件。
  • AOF 可以由用户手动触发,也可以由服务器自动触发。
 

发布评论
IT序号网

微信公众号号:IT虾米 (左侧二维码扫一扫)欢迎添加!

redis -- RDB知识解答
你是第一个吃螃蟹的人
发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。