因为Redis是内存操作,意味着掉电就GG, 所以为了保证异常重启等问题后能尽快恢复服务,还是需要一定的持久化机制来保证。Redis提供了两种持久化机制:
- AOF Append Only File
- RDS Redis Database
AOF
AOF文件记录的命令本身,是写完内存之后再写AOF缓冲区。
- Always 每次
- EverySec 每秒
- No 操作系统自己决定
当然了,频次越高,数据越可靠(越不容易丢失)但对性能的影响越大,这其中的trade-off需要根据业务场景具体考虑。
为了避免AOF文件过大,Redis会进行AOF重写(因为AOF是记录的命令本身,比如三个set a xxx的命令重写过后就只剩最后一个set命令会减少存储量)。如何确定AOF是否太大,有两个参数控制, auto-aof-rewrite-min-size
默认64MB, 和 auto-aof-rewrite-percentage
即上一次重写后体量的差值。
对AOF的重写是 后台线程进行的,当AOF大小超过设定值时,主线程会fork出一个子线程 bgrewriteof,(注:fork的过程其实是会阻塞主线程的),然后子线程对AOF进行重写,当新的客户端请求到来时,需要既写新的AOF又写原来的AOF。
RDB
RDB文件保存的是内存快照,也就是实际的内存数据。生成RDB的方式有两种
- save命令,主线程执行
- bgsave 子线程执行,也是Redis默认的配置
快照,就有一个问题,比如我想保存t0时刻的内存快照,我整个保存过程需要5s,如果这5s中,没有任何改变内存数据的客户端请求,那没问题。但是如果有,那如果没有其他机制保证,我的内存快照其实是掺杂了t1,t2等5s内修改了数据的结果。
解决办法也很简单,就像其他数据库一样,我有多个数据”版本”就行了呀,我t1改的数据a,改成a1,两个我都存着。Redis采用的就是操作系统提供的 Copy-on-write机制,究其本质就是有多个版本啦。
混合使用AOF,RDB
Redis4.0提出混合使用AOF,RDB来取得性能和可靠性的折中。即两次生成RDB的期间用AOF日志记录这其中的操作。
Original: https://www.cnblogs.com/rachel-aoao/p/redis_persistence.html
Author: rachel_aoao
Title: Redis-持久化
原创文章受到原创版权保护。转载请注明出处:https://www.johngo689.com/601466/
转载文章受原作者版权保护。转载请注明原作者出处!