Redis总结

前言

Redis也用了好久,一直没有详细的做一个整理,也没有看看文档,基本就是拿来就用,在之前的文章中,也谈到过Redis对性能的影响,也用过Redis做缓存相关的设计来提升系统性能。这两天休息,就来整理一下

我看到官方文档上的资料挺全的,我就不去看那些二手知识了,直接看文档,整理一下。

开始

是什么?

Redis是一个开源的非关系型的key-value数据库,支持丰富的数据类型,List,Set,ZSet,Hash,String。平常可以用来做数据缓存,消息队列,分布式锁等场景。

文档

跟着文档的节奏来整理一下知识点

Redis持久化

Redis提供了不同级别的持久化方式:

RDB:在指定的时间间隔对数据进行快照存储

AOF:记录每次对服务器的写操作,当服务器重启时,重新执行这些命令来恢复数据,AOF命令以redis协议追加保存到文件末尾,redis还能对AOF文件进行重写,比如+1操作,加十次,合并为一条+10,以此来减少文件体积

如果只想保证数据在运行的时候存在,也可不指定持久化方式

通常做法是开启两个持久化方式,如果机器在断点之后,使用RDB来恢复大部分数据,然后在使用AOF来恢复最后剩下的未备份的数据,这样就能保证数据的完整性

RDB

优点

RDB是一个紧凑的单一文件,方便保存,方便传送到远端数据中心来防止数据丢失。RDB在保存RDB文件时,父进程唯一需要做的就是fork一个子进程,然后父进程就不需要做其他I/O操作,全部由子进程来完成备份工作,所以RDB的持久化方式可以最大化redis的性能

缺点

就是上文说的,可能备份之后,下次备份之前,机器断电,中间的数据就丢失了。

RDB需要经常fork子进程来保存数据到磁盘上,当数据比较大的时候,fork的过程非常耗时,可能会导致redis在一些毫秒级内不能响应客户端的请求,如果数据集特别大,CPU性能不是很好的时候,这种情况会持续1s。

快照

Redis将数据库快照保存在名字为dump.rdb的二进制文件中,可以对redis进行设置,让他在N秒内数据集至少有M个改动这一个条件满足时,自动保存一次数据,也可以通过SAVE或者BGSAVE手动让redis进行数据集保存操作

60秒内至少有1000个改动 就会自动保存一次数据集

1
save 60 1000
工作方式

当redis需要保存dump.rdb文件时,服务器执行以下操作

1、redis调用forks,同时拥有父进程和子进程。

2、子进程将数据集写入到一个临时的RDB文件中。

3、当子进程完成对新RDB文件的写入,redis用新的RDB文件替换原来的RDB文件,并删除旧的RDB文件

这种工作方式使redis可以写时复制(copy-on-write)机制中获益

AOF

优点

使用AOF会让redis更加耐久,可以使用不同的同步fsync策略:无fsync,每秒fsync,每次写入的时候fsync。使用默认的每秒fsync,redis的性能依然很好(fsync是由后台线程进行处理,主线程会尽力处理客户端的请求),一旦出现故障,最多丢失一秒的请求。

redis可以在AOF文件体积过大的时候,自动在后台对AOF重写合并,重写操作是绝对安全的,因为redis在创建新的AOF文件时,会继续将命令追加到现有的AOF文件中,即时重写时发生停机,现有的AOF文件也不会丢失,而新AOF文件创建完之后,redis就会从就的AOF文件切换到新的AOF文件,并开始对新的AOF文件做追加操作

缺点

对于相同数据集来说,AOF文件的体积通常大于RDB文件的体积

根据所有的fsync策略,AOF的速度可能比RDB慢

工作方式

只追加操作的文件(Append-only file,AOF)

1
appendonly yes

AOF和RDB都运用了写时复制机制

1、redis执行fork(),现在同时拥有父进程和子进程

2、子进程开始将新的AOF文件的内容写入到临时文件。

3、对于新执行的写入命令,父进程一边将他们累计到内存缓存中,一边将这些改动追加到AOF文件的末尾,这样,即时在重写中途发生停机,现有的AOF文件也是安全

4、当子进程完成工作,会给父进程发一个信号,父进程接收到信号之后,将内存缓存中的所有数据追加到新的AOF文件末尾

5、redis原子地用新文件替换就文件,之后所有的命令都会追加到新文件的末尾

日志重写

上文提到过日志重写,即合并指令。可以在不打断服务客户端的情况下,对AOF文件重建(rebuild)。执行bgrewriteaof,redis将生成一个新的AOF文件,这个文件保存了重建当前数据集的最少命令,redis2.2需要手动执行,redis2.4可以自动触发AOF重写

使用redis-check-aof对原来的AOF文件修复

备份

可以将RDB文件上传到数据中心之外的远程服务器上,比如S3

Redis的Sentinel(哨兵)

Redis的Sentinel用来管理多个Redis的服务器,系统执行三个任务

1、监控(Montioring):不断检查服务器和从服务器是否正常

2、提醒(Notification):当某个Redis服务器出问题,可以通过API向管理员或其他应用程序发送通知

3、自动故障迁移(Automatic failover):当主服务器不能正常工作,Sentinel会开始自动故障迁移,将失效的主服务器的其中一台从服务器升级为新的主服务器,让失效的主服务器的从服务器改为复制新的主服务器,当客户端试图连接失效服务器时,集群也会向客户端返回新的主服务器地址

主观下线和客观下线

Redis中的Sentinel关于下线(down)有两个概念

主观下线(SDOWN)指单个Sentinel实例对服务器做出的下线判断

客观下线(ODOWN)指多个Sentinel实例在对同一个服务器做SDOWN判断,并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断。

下线的判断为Sentinel去PING服务器,如果指定时间没有回复,则判断下线

故障转移

一次故障转移操作由以下步骤组成:

  • 发现主服务器已经进入客观下线状态。

  • 对我们的当前纪元进行自增(详情请参考 Raft leader election ), 并尝试在这个纪元中当选。

  • 如果当选失败, 那么在设定的故障迁移超时时间的两倍之后, 重新尝试当选。 如果当选成功, 那么执行以下步骤。

  • 选出一个从服务器,并将它升级为主服务器。

  • 向被选中的从服务器发送 SLAVEOF NO ONE 命令,让它转变为主服务器。

  • 通过发布与订阅功能, 将更新后的配置传播给所有其他 Sentinel , 其他 Sentinel 对它们自己的配置进行更新。

  • 向已下线主服务器的从服务器发送 SLAVEOF命令, 让它们去复制新的主服务器。

  • 当所有从服务器都已经开始复制新的主服务器时, 领头 Sentinel 终止这次故障迁移操作。

    Sentinel选择新主服务器规则

    排除掉主观下线,以断线,或者最后一个PING大于5秒的

    排除与主服务器断开连接超过down-after指定时长的十倍

    剩下的从服务器使用复制偏移量最大的作为主服务器,如果复制偏移量不够,则选最小运行ID的作为主服务器

-------------本文结束感谢您的阅读-------------
0%