redis 更改配置文件后重启修改redis

转载

mob64ca1416b5a8 2023-12-24 16:07:38

文章标签 redis 更改配置文件后重启 redis怎么修改 redis 数据 Redis 文章分类 Redis 数据库

前言

我们都知道，redis是基于内存的K-V数据库。由于内存是断电易失的，所以redis提供了相应的持久化机制。

本篇主要讲解redis提供的RDB和AOF两种持久化方式，以及他们的实现原理。

RDB

RDB(Redis DataBase)是指把某个时刻内存中的数据生成快照(snapshot)，以dump.rdb文件的形式存在磁盘上。RDB每次生成的快照(snapshot)都是redis中的全量数据。

生成快照可以由两个命令完成，分别是save和bgsave，先看下这两个命令的描述

127.0.0.1:6379> help save  SAVE -  summary: Synchronously save the dataset to disk  since: 1.0.0  group: server

127.0.0.1:6379> help bgsave  BGSAVE -  summary: Asynchronously save the dataset to disk  since: 1.0.0  group: server

从描述上来看，这两个命令实现的功能一模一样，只是save是以同步的方式写入磁盘，而bgsave是以异步的方式，bg就是Background的意思。

事实上调用save命令后，redis进程会被阻塞，直到快照生成完成，期间redis不能对外提供服务。而bgsave会调用Linux的fork()函数来创建一个子进程，让子进程来生成快照，期间redis依然可以对外提供服务。

了解了RDB的相关命令，再来思考下这个问题：假设redis中有6G数据，要给这6G数据生成一个快照，不可能在一瞬间完成，肯定会持续一段时间。那么从快照开始生成(t1)，到快照生成成功(t2)的这段时间内，redis中被修改的数据应该怎么处理？持久化的数据应该是t1时刻的数据，还是t2时刻的数据呢？

对于save的方式来说，生成快照期间，redis不能对外提供服务，所以在t1到t2期间不会有数据被修改。但是对于bgsave方式来说，生成快照期间，redis依然可以对外提供服务，所以极有可能有些数据被修改。这时子进程是根据t1时刻的数据来生成快照的。t1到t2期间被修改的数据只能在下一次生成快照时处理。但是在t1到t2期间被修改的值，对外部调用方来说是可以实时访问的。也就是说redis不仅要存储快照生成点(t1)时刻的所有值，还要存储变量的最新值。这样的话，redis中6G的数据，在生成快照的时候，会瞬间变成12G。

但是事实并非如此，以性能著称的redis肯定不允许这样的事发生。那这个问题是如果解决的呢？这样就不得不说copy on write机制了

copy on write(COW，写时复制)是一种计算机程序设计领域的优化策略。

其核心思想是，如果有多个调用者(callers)同时请求相同资源(如内存或磁盘上的数据存储)，他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本(private copy)给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的(transparently)。

前文提到调用bgsave时，会调用linux系统的fork()函数来创建子进程，让子进程去生成快照。fork()函数实现了copy on write机制。

如下图所示，redis调用bgsave之后，bgsave调用fork。也就是在t1时刻，内存中的数据并不会为了两个进程而复制成两份，而是两个进程中的指针都指向同一个内存地址。

redis 更改配置文件后重启修改redis_数据

此时子进程开始生成快照，如果在生成快照期间，redis中的数据被修改了，k3的值由c变成了d。操作系统仅仅会把k3复制一份，而没有变化的k1和k2不会被复制。这就是写时复制(copy on write)机制。可以看到此时子进程取到的数据还是t1时刻的数据，而redis对外提供的服务也能获取最新数据。

redis 更改配置文件后重启修改redis_数据_02

此处用copy on write优化的前提是生成快照的过程持续的时间较短，期间只有少量的数据发生了变化。如果期间所有的数据都发生了变化，也就相当于真的把6G数据变成了12G。

写时复制是一种优化思想，在JDK中也能看它的实现

配置

前文说RDB模式生成快照的命令是save和bgsave，但是在实际使用redis的时候，也没见我们定期手动执行这两个命令。所以快照的生成还有一种自动的触发方式，在配置文件中可以找到相关的配置

################################ SNAPSHOTTING  ################################## Save the DB on disk:##   save ##   Will save the DB if both the given number of seconds and the given#   number of write operations against the DB occurred.##   In the example below the behaviour will be to save:#   after 900 sec (15 min) if at least 1 key changed#   after 300 sec (5 min) if at least 10 keys changed#   after 60 sec if at least 10000 keys changed##   Note: you can disable saving completely by commenting out all "save" lines.##   It is also possible to remove all the previously configured save#   points by adding a save directive with a single empty string argument#   like in the following example:##   save ""save 900 1save 300 10save 60 10000

save配置表示调用bgsave。save 60 10000表示如果在60秒内，超过10000个key被修改了，就调用一次bgsave。同理save 300 10表示300秒内，超过10个key被修改了，就调用一次bgsave。多个save不是互斥的，如果配置多个save，只要满足其中一个就会执行bgsave，配置多个是为了适应不同的场景。

配置save ""或者注释所有的save表示不开启RDB。

从配置文件配置的save参数来看，如果每60秒执行一次bgsave，而在59秒的时候服务宕机了，这样就丢失了59秒内修改的数据，因为还没来得及生成快照。数据丢失量这么大，肯定是不被允许的。为此，redis还提供了另一种持久化方式，那就是AOF

AOF

AOF(Append Only File)是把对redis的修改命令以特定的格式记录在指定文件中。也就是说RDB记录的是数据快照，而AOF记录的是命令。AOF默认是关闭的。

############################## APPEND ONLY MODE ################################ By default Redis asynchronously dumps the dataset on disk. This mode is# good enough in many applications, but an issue with the Redis process or# a power outage may result into a few minutes of writes lost (depending on# the configured save points).## The Append Only File is an alternative persistence mode that provides# much better durability. For instance using the default data fsync policy# (see later in the config file) Redis can lose just one second of writes in a# dramatic event like a server power outage, or a single write if something# wrong with the Redis process itself happens, but the operating system is# still running correctly.## AOF and RDB persistence can be enabled at the same time without problems.# If the AOF is enabled on startup Redis will load the AOF, that is the file# with the better durability guarantees.## Please check http://redis.io/topics/persistence for more information.appendonly no# The name of the append only file (default: "appendonly.aof")appendfilename "appendonly.aof"

如果开启了AOF，相应的命令会记录在appendonly.aof文件中。

appendonly.aof这个文件的内容本身也需要写到磁盘中，如果appendonly.aof还未来得及写入磁盘，服务就宕机了，也会造成appendonly.aof文件内容丢失，而丢失redis的修改命令，进而丢失redis的修改数据。

为此redis为appendonly.aof的持久化提供了三种配置方式：

# The fsync() call tells the Operating System to actually write data on disk# instead of waiting for more data in the output buffer. Some OS will really flush# data on disk, some other OS will just try to do it ASAP.## Redis supports three different modes:## no: don't fsync, just let the OS flush the data when it wants. Faster.# always: fsync after every write to the append only log. Slow, Safest.# everysec: fsync only one time every second. Compromise.## The default is "everysec", as that's usually the right compromise between# speed and data safety. It's up to you to understand if you can relax this to# "no" that will let the operating system flush the output buffer when# it wants, for better performances (but if you can live with the idea of# some data loss consider the default persistence mode that's snapshotting),# or on the contrary, use "always" that's very slow but a bit safer than# everysec.## More details please check the following article:# http://antirez.com/post/redis-persistence-demystified.html## If unsure, use "everysec".# appendfsync alwaysappendfsync everysec# appendfsync no

这三种方式都是通过参数appendfsync来指定。

no：并不是不持久化，只将数据写到OS buffer，由操作系统决定何时将数据写到磁盘，这种方式速度最快
always：每次在appendonly.aof中追加内容，都调用fsync()将数据写入磁盘，这种方式最慢，但是最安全
everysec：默认配置，表示每秒调用一次fsync()，将数据写入磁盘，是一种折中的方式

根据配置可以知道，如果每秒将appendonly.aof的内容写到磁盘一次。那么在两次写磁盘的间隔，如果服务宕机了，还是有可能丢失部分命令，从而导致redis的修改数据丢失，不过相比于RDB来说，这种丢失已经非常非常小了。

除此之外，appendonly.aof文件是以追加的方式写入命令，对于长时间运行的服务，必定会导致该文件过大。万一服务宕机需要根据appendonly.aof文件恢复数据，将会消耗相当长的时间来执行appendonly.aof中记录的命令。

为了解决appendonly.aof文件过大的问题redis提供了一种机制，叫bgrewriteaof。

bgrewriteaof

bgrewriteaof命令描述如下

127.0.0.1:6379> help bgrewriteaof  BGREWRITEAOF -  summary: Asynchronously rewrite the append-only file  since: 1.0.0  group: server

这个命令的作用就是fork()出一个子进程来对appendonly.aof文件进行重写。这个重写操作在redis4.0以前和4.0以后有不同的实现方式。

redis4.0以前的重写主要有两点：删除抵消的命令、合并重复的命令。对于set key1 a和del key1这样相互抵消的命令会被直接删除。对于set key1 a和set key1 b这样重复的命令会进行合并。这样一通操作之后，AOF文件可能会变得很小。

redis4.0之后，开启了RDB和AOF的混合模式。也就是将已有的数据以RDB的方式记录在appendonly.aof文件的头部，对于之后的增量数据以AOF的方式继续追加在appendonly.aof文件中，也就是appendonly.aof文件前半段是快照数据，后半段是redis指令。

这样的混合模式结合了RDB和AOF的优点，既能最大限度的减少数据丢失，又能在Redis重启后迅速恢复数据。

那么在什么情况下会触发bgrewriteaof呢？除了手动触发，配置文件中提供了几个相关参数来实现自动触发

# Automatic rewrite of the append only file.# Redis is able to automatically rewrite the log file implicitly calling# BGREWRITEAOF when the AOF log size grows by the specified percentage.## This is how it works: Redis remembers the size of the AOF file after the# latest rewrite (if no rewrite has happened since the restart, the size of# the AOF at startup is used).## This base size is compared to the current size. If the current size is# bigger than the specified percentage, the rewrite is triggered. Also# you need to specify a minimal size for the AOF file to be rewritten, this# is useful to avoid rewriting the AOF file even if the percentage increase# is reached but it is still pretty small.## Specify a percentage of zero in order to disable the automatic AOF# rewrite feature.auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-min-size参数设置成64mb，意思是redis尚未执行过bgrewriteaof(从启动开始算)，AOF文件需要达到64mb才会第一次执行bgrewriteaof(此后不会再使用auto-aof-rewrite-min-size参数)，redis会记录每次执行bgrewriteaof之后，AOF文件的大小。

auto-aof-rewrite-percentage设置成100，表示当前的AOF文件大小超过上一次bgrewriteaof后AOF文件的百分比后触发bgrewriteaof。如果上次bgrewriteaof后，AOF为200mb，现在需要AOF文件达到400mb才会执行bgrewriteaof。

auto-aof-rewrite-percentage设置成0，表示禁用bgrewriteaof。auto-aof-rewrite-min-size参数的作用就是在AOF文件比较小的时候，防止因为增长过快而频繁调用bgrewriteaof。

no-appendfsync-on-rewrite

redis主进程在写AOF文件采用always或者everysec配置，和子进程在重写AOF文件的时候，都会产生大量的I/O操作。可能会使fsync阻塞很长时间，为了缓解这个问题，redis提供了no-appendfsync-on-rewrite这个参数

# When the AOF fsync policy is set to always or everysec, and a background# saving process (a background save or AOF log background rewriting) is# performing a lot of I/O against the disk, in some Linux configurations# Redis may block too long on the fsync() call. Note that there is no fix for# this currently, as even performing fsync in a different thread will block# our synchronous write(2) call.## In order to mitigate this problem it's possible to use the following option# that will prevent fsync() from being called in the main process while a# BGSAVE or BGREWRITEAOF is in progress.## This means that while another child is saving, the durability of Redis is# the same as "appendfsync none". In practical terms, this means that it is# possible to lose up to 30 seconds of log in the worst scenario (with the# default Linux settings).## If you have latency problems turn this to "yes". Otherwise leave it as# "no" that is the safest pick from the point of view of durability.no-appendfsync-on-rewrite no

如果开启该参数，表示在bgsave和bgrewriteaof的过程中，主线程写入AOF不会调用fsync()，相当于配置appendfsync no。这样有可能会导致redis的修改命令丢失，Linux默认配置下，最多丢失30秒的数据。

如果关闭该参数，表示在bgsave和bgrewriteaof的过程中，主线程写入AOF会调用fsync()，并且被阻塞，这样是最安全的，不会丢失数据。