什么是Redis持久化?
持久化就是把内存的数据写到磁盘中去,防止服务宕机了内存数据丢失。
Redis 的持久化机制是什么?各自的优缺点?
Redis 提供两种持久化机制 RDB(默认) 和 AOF 机制:
RDB:是Redis DataBase缩写快照
RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中,对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。
优点:
1、只有一个文件 dump.rdb,方便持久化。
2、容灾性好,一个文件可以保存到安全的磁盘。
3、性能最大化,fork 子进程来完成写操作,让主进程继续处理命令,所以是 IO 最大化。使用单独子进程来进行持久化,主进程不会进行任何 IO 操作,保证了 redis 的高性能
4.相对于数据集大时,比 AOF 的启动效率更高。
缺点:
1、数据安全性低。RDB 是间隔一段时间进行持久化,如果持久化之间 redis 发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
2、AOF(Append-only file)持久化方式:是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。
如何选择合适的持久化方式
一般来说, 如果想达到足以媲美PostgreSQL的数据安全性,你应该同时使用两种持久化功能。在这种情况下,当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
如果你非常关心你的数据, 但仍然可以承受数分钟以内的数据丢失,那么你可以只使用RDB持久化。
有很多用户都只使用AOF持久化,但并不推荐这种方式,因为定时生成RDB快照(snapshot)非常便于进行数据库备份, 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快,除此之外,使用RDB还可以避免AOF程序的bug。
如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
vim /etc/redis/6379.conf
以下三个save条件满足任意一个时,都会引起bgsave的调用
219 save 900 1 ##当时间到900秒时,如果redis数据发生了至少1次变化,则执行bgsave
220 save 300 10 ##当时间到300秒时, 如果redis数据发生了至少10次变化, 则执行bgsave
221 save 60 10000 :当时间到60秒时,如果redis数据发生了至少10000次变化, 则执行bgsave
AOF:持久化
AOF持久化(即Append Only File持久化),则是将Redis执行的每次写命令记录到单独的日志文件中,当重启Redis会重新将持久化的日志中文件恢复数据。
当两种方式同时开启时,数据恢复Redis会优先选择AOF恢复。
优点:
1、数据安全,aof 持久化可以配置 appendfsync 属性,有 always,每进行一次 命令操作就记录到 aof 文件中一次。
2、通过 append 模式写文件,即使中途服务器宕机,可以通过 redis-check-aof 工具解决数据一致性问题。
3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前(文件过大时会对命令 进行合并重写),可以删除其中的某些命令(比如误操作的 flushall))
缺点:
1、AOF 文件比 RDB 文件大,且恢复速度慢。
2、数据集大的时候,比 rdb 启动效率低
优缺点是什么?
AOF文件比RDB更新频率高,优先使用AOF还原数据。
AOF比RDB更安全也更大
RDB性能比AOF好
如果两个都配了优先加载AOF
开启AOF
Redis服务器默认开启RDB,关闭AOF
要开启AOF,需要在配置文件中配置
vim /etc/redis/6379.conf
700 appendonly yes ##修改成yes,开启AOF
704 appendfilename "appendonly.aof" ##指定A0F文件名称
796 aof-load-truncated yes ##是否忽略最后一条可能存在问题的指令
/etc/ init.d/redis_ 6379 restart ##重启redis
执行流程
由于需要记录Redis的每条写命令,因此A0F不需要触发,下面介绍AOF的执行流程。
AOF的执行流程包括:
命令追加(append)
将Redis的写命令追加到缓冲区aof_buf; (为了尽量不因为持久化而影响redis性能)
文件写入(write)和文件同步(sync)
根据不同的同步策略将aof_buf中的内容同步到硬盘,所以Redis系统同时提供了fsync、fdatasync等同步函数,可以强制操作系统立刻将缓冲区中的数据写入到硬盘里,从而确保数据的安全性。
AOF缓存区的同步文件策略存在三种同步方式,它们分别是
vim /etc/redis/6379.conf
729 appendfsync always
##命令写入aof_buf后立即调用系统fsync操作同步到AOF文件,fsync完成后线程返回。这种情况下,每次有写命令都要同步到A0F文件,硬盘IO成为性能瓶颈,Redis只能支持大约几百TPS写入,严重降低了Redis的性能;即便是使用固态硬盘(SSD),每秒大约也只能处理几万个命令,而且会大大降低SSD的寿命。
729 appendfsync no
命令写入aof_buf后调用系统write操作,不对AOF文件做fsync同步;同步由操作系统负责,通常同步周期为30秒。这种情况下,文件同步的时间不可控,且缓冲区中堆积的数据会很多,数据安全性无法保证。
729 appendfsync everysec(默认配置)
命令写入aof_buf后调用系统write操作,write完成后线程返回;fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中,是性能和数据安全性的平衡,因此是Redis的默认配置,也是我们推荐的配置。
文件重写的触发分类
文件重写的触发,分为手动触发和自动触发
手动触发
直接调用bgrewriteaof命令;通过fork子进程进行具体的工作,且只有在fork时阻塞。
自动触发
通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEA0F,且两个选项同时满足时,才会自动触发AOF重写,即bgrewriteaof操作
vim /etc/ redis/ 6379. conf
AOF同步的策略
729 # appendfsync always
730 appendfsync everysec
731 # appendfsync no
771 auto-aof-rewrite-percentage 100 ##当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时,发生BGREWRITEAOF操作
772 auto-aof-rewrite -min-size 64mb ##当前A0F文件执行BGREWRITEAOF命令的最小值,避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEA0F
哨兵模式
哨兵的介绍
sentinel,中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件,主要有以下功能:
集群监控:负责监控 redis master 和 slave 进程是否正常工作。
消息通知:如果某个 redis 实例有故障,那么哨兵负责发送消息作为报警通知给管理员。
故障转移:如果 master node 挂掉了,会自动转移到 slave node 上。
配置中心:如果故障转移发生了,通知 client 客户端新的 master 地址。
哨兵用于实现 redis 集群的高可用,本身也是分布式的,作为一个哨兵集群去运行,互相协同工作。
故障转移时,判断一个 master node 是否宕机了,需要大部分的哨兵都同意才行,涉及到了分布式选举的问题。
即使部分哨兵节点挂掉了,哨兵集群还是能正常工作的,因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的,那就很坑爹了。
哨兵的核心知识
哨兵至少需要 3 个实例,来保证自己的健壮性。
哨兵 + redis 主从的部署架构,是不保证数据零丢失的,只能保证 redis 集群的高可用性。
对于哨兵 + redis 主从这种复杂的部署架构,尽量在测试环境和生产环境,都进行充足的测试和演练。
Redis性能管理
查看Redis内存使用
127.0.0.1:6379> info memory
总结
高可用中的持久化
RDB和AOF;RDB是默认开启的,AOF需要手动开启
1、持久化方式
①:RDB:周期性的快照;二进制压缩格式
②:A0F:接近实时的持久化(以everysec方式)基于日志文件持久化;还有一个文件重写功能,可以帮助AOF减少持久化文件的大小
2、redis 启用的优先级
AOF>RDB,同时仅当AOF功能关闭的情况下,redis才会在重新启动时使用RDB的方式进行恢复
3、RDB和AOF中持久化模式
①:RDB
由redis主进程( 周期性) fork 派生出子进程对redis内存中的数据进行持久化(二进制压缩),生成到.rd文件中,自动触发的方式是使用的bgsave持久化
②:AOF
根据持久化策略(alawys、no、everysec(默认) ),先将redis中的语句保存在缓冲区中,再从缓冲区同步到.aof文件中;bgrewriteaeof