1.1. 单机部署

并不推荐单机部署，存在单点问题。

1.1.1. 部署

一、版本
Git地址：https://github.com/antirez/redis
从官网下载4.x版本，在2019年之前，不建议使用5.x版本，官网解释如下：
https://redis.io/download

image.png

部分解释为：Redis 4.0于2017年7月作为GA发布，新用户应该使用Redis 5，但是Redis 4当前是最经生产验证的版本，并将在明年进行更新，直到Redis 6发布。

二、安装
1、操作系统目录划分等内容，参考公司技术标准。将安装包放到/opt/thunisoft/redis下，如果目录不存在，新建如下目录：
mkdir -p /opt/thunisoft/redis
将程序放至此目录下，如redis-4.0.14.tar.gz。
2、解压
tar -zxvf redis-4.0.14.tar.gz
3、进入目录
cd redis-4.0.14/
4、安装依赖
cd deps/
make lua hiredis linenoise jemalloc

使用jemalloc，git地址上的解释：
在构建Redis时，通过设置MALLOC环境变量来选择非默认内存分配器。默认情况下，Redis是针对libc malloc编译和链接的，但jemalloc是Linux系统上的默认值。选择该默认值是因为事实证明，与libc malloc相比，jemalloc的碎片问题更少。

5、编译
cd ..
make
6、安装
make install

将可执行程序复制到/usr/local/bin目录中以便以后执行程序时可以不用输入完整的路径，集群环境下，如果单机多个实例，不建议使用。

7、测试编译
make test

测试Redis是否编译正确，此步骤可以省略，建议生产环境可以运行一次。

8、自启动
在执行如下内容以前，建议将“2.2.2配置”单节内容先配置好后，再执行。
（1）可以使用redis_init_script，但需要手动进行一些工作，如拷备redis.conf到指定目录等
cp utils/redis_init_script /etc/init.d/redis_6379

6379为默认端口，可以更改。
其它内容为修改端口号、配置文件地址、日志地址、存储地址、以及命令生成地址等，不再表述，修改redis_init_script里的内容即可。

（2）推荐使用install_server.sh完成，此命令不适用于Mac OSX，它仅适用于Linux。
cd /opt/thunisoft/redis/redis-4.0.14/utils

可以使用如下两种方式更改。
1）vim install_server.sh
修改端口号、配置文件地址、日志地址、存储地址、以及命令生成地址。
建议端口修改为7000
配置文件地址，可以不变更
日志地址，不做统一日志管控的话，可以不变更。
存储地址，可以自行选择。
:wq # 保存

image.png

2）./ install_server.sh
可以更改，不需要修改的一直回车，直至ok。此处将端口改为7000。

image.png

使用下面的命令查看进程是否存在：
ps -ef|grep redis

此时服务其实已启动，可以使用如下命令重启：
service redis_7000 restart

1.1.1. 配置

不同的使用场景上，需要不同的配置和策略，建议各系统需要充分考虑后使用。

（1）如果已经启动服务，在设置参数之前，将redis停止，如：

service redis_7000 stop

vi /etc/redis/7000.conf

（2）如果未设置服务等内容以前，从安装的根目录里找到redis.conf进行下面的修改。

配置文件目录请自行按设置查找，此为示例。

1.1.1.1. 通用配置

######################## NETWORK ###########################

bind 0.0.0.0

默认为127.0.0.1，绑定IP地址，服务器可能会有多个网卡，推荐使用bind 0.0.0.0，也可以绑定某一个IP，此处不设置，则别的机器无法访问。

port 7000

默认为6379，监听tcp端口。

protected-mode yes

默认为yes，是否开启保护模式，默认开启。要是配置里没有指定bind和密码，开启该参数后，redis只会本地进行访问，拒绝外部访问。要是开启了密码和bind，可以开启。否则最好关闭，设置为no。

tcp-backlog 511

默认为511，此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度， 当然此值必须不大于Linux系统定义的/proc/sys/net/core/somaxconn值，默认是511，而Linux的默认参数值是128。当系统并发量大并且客户端速度缓慢的时候，可以将这二个参数一起参考设定。
Linux调整请参考“操作系统参数”中的somaxconn修改。

timeout 0

默认为0，客户端闲置N秒后关闭连接，为0则服务端不会主动断开连接，不能小于0。

tcp-keepalive 300

默认300，服务端周期性时间（单位秒）验证客户端是否处在健康状态，避免服务端一直阻塞。

####################### GENERAL ###########################

daemonize yes

默认为no，设置为自启动后，较新的版本会直接将此处变更为yes。redis采用的是单进程多线程的模式。当redis.conf中选项daemonize设置成yes时，代表开启守护进程模式。在该模式下，redis会在后台运行，并将进程pid号写入至redis.conf选项pidfile设置的文件中，此时redis将一直运行，除非手动kill该进程。当daemonize选项设置成no时，当前界面将进入redis的命令行界面，exit强制退出或者关闭连接工具(putty,xshell等)都会导致redis进程退出。

supervised no

默认为no。如果需要在机器启动（upstart模式或systemd模式）时就启动Redis服务器，可以通过该选项来配置Redis。
支持的模式：
supervised no – 无，不会与supervised tree进行交互
supervised upstart – 将Redis服务器添加到SIGSTOP 模式中
supervised systemd – 将READY=1 写入 $NOTIFY_SOCKET
supervised auto – 根据环境变量UPSTART_JOB 或NOTIFY_SOCKET检测upstart 还是 systemd
注意，上述supervision方法（upstart或systemd）仅发出“程序已就绪”信号，不会继续给supervisor返回ping回复。
pidfile /var/run/redis_7000.pid
如果指定了pid文件，Redis会在启动时写该pid文件，在退出时删除该文件。
当Redis服务器已守护进程启动时，如果指定了配置文件，则直接使用，如果没有指定，则创建/var/run/redis.pid作为配置文件。

loglevel notice

默认为notice，日志级别，有debug(适合开发、测试阶段，日志信息较多)、verbose(相对于debug日志量减少)、notice(适用于生产)、warning(仅有部分重要关键信息才会记录)

logfile /var/log/redis_7000.log

指定了记录日志的文件。空字符串的话，日志会打印到标准输出设备。后台运行的redis标准输出是/dev/null

databases 16

设置数据库的数目。
默认数据库是 DB 0，你可以在每个连接上使用 select <dbid> 命令选择一个不同的数据库，
但是 dbid 必须是一个介于 0 到 databasees - 1 之间的值

###################### SNAPSHOTTING ######################

dir /var/lib/redis/7000

数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录。

######################## SECURITY #########################

requirepass 123456

默认未开启。requirepass配置可以让用户使用AUTH命令来认证密码，才能使用其他命令。这让redis可以使用在不受信任的网络中。为了保持向后的兼容性，可以注释该命令，因为大部分用户也不需要认证。使用requirepass的时候需要注意，因为redis太快了，每秒可以认证15w次密码，简单的密码很容易被攻破，所以最好使用一个更复杂的密码。
@、#符号在程序客户端远程连接是有影响，暂未找到解决方案。如：
redis :// [: password@] host [: port] [/ database][? [timeout=timeout[d|h|m|s|ms|us|ns]] [&database=database]]
客户端连接示例：redis-cli -h 127.0.0.1 -p 7000 -a 123456
停止服务，可以用redis-cli进入后，执行shutdown。
注意此时服务应该是停止状态，否则service redis_7000 stop等命令不会有作用，需要强制删除进程和pid，再启动才可以。
/etc/rc.d/init.d/ redis_7000下可以配置密码，但不安全，不推荐。
$CLIEXEC -a "123456" -p $REDISPORT shutdown

########################## CLIENTS ##########################

maxclients 10000

默认为10000。设置能连上redis的最大客户端连接数量。默认是10000个客户端连接。由于redis不区分连接是客户端连接还是内部打开文件或者和slave连接等，所以maxclients最小建议设置到32。如果超过了maxclients，redis会给新的连接发送’max number of clients reached’，并关闭连接。

#################### MEMORY MANAGEMENT ######################

maxmemory 16gb

建议上线时根据系统情况进行设置。在64bit系统下，maxmemory设置为0表示不限制Redis内存使用，在32bit系统下，maxmemory不能超过3GB；设置完成后，可以用客户端查看内存大小：CONFIG get maxmemory

maxmemory-policy allkeys-lru

默认为noeviction。内存容量超过maxmemory后的处理策略。
volatile-lru：加入键的时候如果过限，首先从设置了过期时间的键集合中驱逐最久没有使用的键，利用LRU算法移除设置过过期时间的key。
volatile-random：加入键的时候如果过限，随机移除设置过过期时间的key。
volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL），即从配置了过期时间的键中驱逐马上就要过期的键。
这种策略使得我们可以向Redis提示哪些key更适合被eviction。
如果对数据有足够的了解，能够为key指定hint（通过expire/ttl指定），那么可以选择volatile-ttl进行置换
allkeys-lru：加入键的时候，如果过限，首先通过LRU算法驱逐最久没有使用的键。
如果我们的应用对缓存的访问符合幂律分布（也就是存在相对热点数据），或者我们不太清楚我们应用的缓存访问分布状况，我们可以选择allkeys-lru策略。
在所有的key都是最近最经常使用，那么就需要选择allkeys-lru进行置换最近最不经常使用的key，如果你不确定使用哪种策略。
设置是失效时间expire会占用一些内存，而采用allkeys-lru就没有必要设置失效时间，进而更有效的利用内存
allkeys-random：加入键的时候如果过限，随机移除任何key。
如果我们的应用对于缓存key的访问概率相等，则可以使用这个策略。
如果所有的key的访问概率都是差不多的，那么可以选用allkeys-random策略去置换数据。
noeviction：当内存使用超过配置的时候会返回错误，不移除任何key，只是返回一个写错误。
上面的这些驱逐策略，如果redis没有合适的key驱逐，对于写命令，还是会返回错误。redis将不再接收写请求，只接收get请求。写命令包括：set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort
以下两个内容为4.0以后新增
volatile-lfu：从所有配置了过期时间的键中驱逐使用频率最少的键
allkeys-lfu：重点。从所有键中驱逐使用频率最少的键。和lru不同，lru使用的是最近最少使用的进行淘汰，但是有可能会导致某天某个时间段内不活跃（不活跃跨度超过清理间隔），从而可能导致某条其实整天来说数据量很大的数据，但是由于某个时间段内没有数据访问而导致之前的记录被清除，这样对结果影响会很不好，所以4.0以后加入的这个LFU就很好的弥补了这类需求，LFU可以理解为每条记录的访问频率，当然这个访问频率是随时间有关的，如果数据不变，随着时间递增这个频率值会递减，从而如果某个时间段内某条数据量访问极其频繁，而中途有段时间没有数据访问，但是它的访问频率其实还是很高的，所以即便在某个清理周期内没有任何访问记录，但是它也不一定会被清理，这样就很好的保障了top 100类业务的实现。

maxmemory-samples 5

默认为5。LRU，LFU和最小TTL算法不是精确算法，而是近似算法（以节省内存），因此您可以调整它的速度或准确性。 对于默认情况，Redis将检查五个键并选择最近使用的键，您可以使用以下配置指令更改样本大小。
默认值5产生足够好的结果。10非常接近
真正的LRU，但需要更多的CPU。3更快，但不是很准确。
以有大量key需要删除和处理时，建议按需开启如下内容：

######################## LAZY FREEING #########################

lazyfree-lazy-eviction no

默认为no。是否异步驱逐key，当内存达到上限，分配失败后。即内存满逐出选项。
针对redis内存使用达到maxmeory，并设置有淘汰策略时；在被动淘汰键时，是否采用lazy free机制；
因为此场景开启lazy free, 可能使用淘汰键的内存释放不及时，导致redis内存超用，超过maxmemory的限制。此场景使用时，请结合业务测试。

lazyfree-lazy-expire no

默认为no。是否异步进行key过期事件的处理，即过期key删除选项。
针对设置有TTL的键，达到过期后，被redis清理删除时是否采用lazy free机制；此场景建议开启，因TTL本身是自适应调整的速度。

lazyfree-lazy-server-del no

默认为no。del命令是否异步执行删除操作，类似unlink。内部删除选项，比如rename srckey destkey时，如果destkey存在需要先删除destkey。
针对有些指令在处理已存在的键时，会带有一个隐式的DEL键的操作。如rename命令，当目标键已存在,redis会先删除目标键，如果这些目标键是一个big key,那就会引入阻塞删除的性能问题。 此参数设置就是解决这类问题，建议可开启。

slave-lazy-flush no

默认为no。replica client做全同步的时候，是否异步flush本地db。slave接收完RDB文件后清空数据选项
针对slave进行全量数据同步，slave在加载master的RDB文件前，会运行flushall来清理自己的数据场景，
参数设置决定是否采用异常flush机制。如果内存变动不大，建议可开启。可减少全量同步耗时，从而减少主库因输出缓冲区爆涨引起的内存使用增长。

######################## SLOW LOG #########################

slog log是用来记录redis运行中执行比较慢的命令耗时。当命令的执行超过了指定时间，就记录在slow log中，slog log保存在内存中，所以没有IO操作。

slowlog-log-slower-than 10000

默认为10000。执行时间比slowlog-log-slower-than大的请求记录到slowlog里面，单位是微秒，所以1000000就是1秒。注意，负数时间会禁用慢查询日志，而0则会强制记录所有命令。

slowlog-max-len 128

默认为128。慢查询日志长度。当一个新的命令被写进日志的时候，最老的那个记录会被删掉。这个长度没有限制。只要有足够的内存就行。你可以通过 SLOWLOG RESET 来释放内存。
它决定 slow log最多能保存多少条日志，slow log 本身是一个 FIFO 队列，当队列大小超过 slowlog-max-len 时，最旧的一条日志将被删除，而最新的一条日志加入到 slow log，以此类推。
英文地址：https://redis.io/commands/slowlog

###################### LATENCY MONITOR ####################

latency-monitor-threshold 0

默认为0。redis延时监控系统在运行时会采样一些操作，以便收集可能导致延时的数据根源。排查性能和问题比较有用的命令！！
通过 LATENCY命令 可以打印一些图样和获取一些报告，方便监控
这个系统仅仅记录那个执行时间大于或等于预定时间（毫秒）的操作,
这个预定时间是通过latency-monitor-threshold配置来指定的，
当设置为0时，这个监控系统处于停止状态
redis的slowlog在2.2.12版本引入，latency monitor在2.8.13版本引入
slowlog仅仅是记录纯命令的执行耗时，不包括与客户端的IO交互及redis的fork等耗时。
latency monitor监控的latency spikes则范围广一点，不仅包括命令执行，也包括fork(2)系统调用，key过期等操作的耗时
英文地址：https://redis.io/topics/latency-monitor
中文地址：http://www.redis.cn/topics/latency-monitor.html

################### EVENT NOTIFICATION ####################

notify-keyspace-events ""

默认为""。事件通知。这个双引号是一定要的，否则配置不成功，启动也不报错。可以尝试用到以下两个场景：
设置了生存时间的Key，在过期时能不能有所提示？
如果能对过期Key有个监听，如何对过期Key进行一个回调处理？
可以将notify-keyspace-events ""改为notify-keyspace-events "Ex"。

##################### ADVANCED CONFIG #####################

基本是优化方法，未经过实测，后续补充
其中有部分推荐使用的内容，参考“常见场景”篇章。

activerehashing yes

默认为yes。Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用。当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存。
Redis为了解决输出缓冲区消息大量堆积的隐患，设置了一些保护机制，主要采用两种限制措施：
大小限制，当某一客户端缓冲区超过设定值后直接关闭连接；
持续性限制，当某一客户端缓冲区持续一段时间占用过大空间时关闭连接。

client-output-buffer-limit normal 0 0 0

对于normal client，第一个0表示取消hard limit，第二个0和第三个0表示取消soft limit，normal client默认取消限制，因为如果没有寻问，他们是不会接收数据的。
对于普通客户端来说，默认限制为0，也就是不限制。因为普通客户端通常采用阻塞式的消息应答模式，何谓阻塞式呢？如：发送请求，等待返回，再发送请求，再等待返回。这种模式下，通常不会导致Redis服务器输出缓冲区的堆积膨胀。

client-output-buffer-limit slave 256mb 64mb 60

对于slave client和MONITER client，如果client-output-buffer一旦超过256mb，又或者超过64mb持续60秒，那么服务器就会立即断开客户端连接。
对于slave客户端来说，大小限制是256M，持续性限制是当客户端缓冲区大小持续60秒超过64M，则关闭客户端连接。

client-output-buffer-limit pubsub 32mb 8mb 60

对于pubsub client，如果client-output-buffer一旦超过32mb，又或者超过8mb持续60秒，那么服务器就会立即断开客户端连接。
对于Pub/Sub客户端（也就是发布/订阅模式），大小限制是8M，当输出缓冲区超过8M时，会关闭连接。持续性限制是，当客户端缓冲区大小持续60秒超过2M，则关闭客户端连接。

client-query-buffer-limit 1gb

默认1gb。客户端查询缓冲区累积新命令。默认情况下，它们被限制为固定数量，以避免协议不同步（例如由于客户端错误）导致查询缓冲区中的未绑定内存使用。 但是，如果您有非常特殊的需求，例如巨大的multi / exec请求等，则可以在此处进行配置。

proto-max-bulk-len 512mb

默认512mb。在Redis协议中，批量请求（即表示单个字符串的元素）通常限制为512 mb以上。但是，您可以在此处更改此限制。

aof-rewrite-incremental-fsync yes

默认为yes。当AOF重写时，子进程根据内存快照，按照命令合并规则写入到新的AOF文件中。如果启用，则每生成32MB的数据，文件就会进行同步处理，为了将文件更多地提交到磁盘，并避免单次刷盘数据过多造成硬盘阻塞，这很有用。

################# ACTIVE DEFRAGMENTATION #############

主动碎片整理，因为在4版本里是试验性的，存在不稳定性，先不开启，依赖Jemalloc。

1.1.2.2. RDB

建议使用场景：
（1） 内容较固化。业务系统处理过程中，不会经常性的变化缓存内容，针对Redis不会经常进行修改、新增。
（2） 成批变化或插入数据量大。
（3） 如果依赖RDB的自动持久化，则业务系统必须允许存在丢失场景，且丢失后不会影响业务系统使用，比如丢失后可以去数据库获取，但需要考虑数据库的并发以及性能。
（4） 手动触发持久化，比较推荐，建议业务系统统一封装调用，每次完成后（前提是缓存修改量不大）或固定的时间（前提是允许丢数据），需要调用“bgsave”，让Redis fork子进程去进行，但还是会影响Redis的性能，如果考虑不周，修改/插入频繁，则线程、磁盘IO等都会成为问题。

###################### SNAPSHOTTING ######################
save 900 1
save 300 10
save 60 10000

默认开启。
设置redis进行数据库镜像的频率。
900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）

stop-writes-on-bgsave-error yes

默认为yes。当RDB持久化出现错误后，是否依然进行继续进行工作，yes：不能进行工作，no：可以继续进行工作，可以通过info中的rdb_last_bgsave_status了解RDB持久化是否有错误

rdbcompression yes

默认为yes。使用压缩rdb文件，rdb文件压缩使用LZF压缩算法，yes：压缩，但是需要一些cpu的消耗。no：不压缩，需要更多的磁盘空间

rdbchecksum yes

是否校验rdb文件。从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC64的校验和。这跟有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗，所以如果你追求高性能，可以关闭该配置。

dbfilename dump.rdb

rdb文件的名称

#################### APPEND ONLY MODE #####################
appendonly no

默认为no。是否打开aof持久化。

aof-use-rdb-preamble no

4版本默认为no，5版本默认为yes。是否开启混合模式。

1.1.2.3. 混合模式

可以算是AOF的增强版，保留了部分RDB的特性
建议使用场景：
（1） 业务流程过程中，会对缓存进行新增、修改，数据不能丢失。
（2） 一般不会是成批修改或新增，如果要做的话需要调整缓存策略，参考“配置信息”。
（3） 因其是将命令写入文件，需要定期进行重写，可以调用bgrewriteaof，此命令可以放到定时任务里。
比AOF配置多了一个aof-use-rdb-preamble yes（4版本默认no，5版本默认为yes），以下为最常用的配置，研发人员可以直接使用，参数中也加入了一些特殊场景时的建议，可以参考，需要各设计、研发人员注意的是no-appendfsync-on-rewrite参数，可以按需求选择性关闭。

###################### SNAPSHOTTING ######################
# save 900 1
# save 300 10
# save 60 10000

默认开启，需要注释掉。注释掉“save”这一行配置项就可以让RDB保存数据库功能失效。
设置redis进行数据库镜像的频率。
900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化）
300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化）
60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化）

#################### APPEND ONLY MODE #####################
appendonly yes

默认为no。打开aof持久化。

appendfilename "appendonly.aof"

默认为"appendonly.aof"，保存的文件名称。开启aof之后，每条命令（除读之外的命令），均会写入到文件中,这里即实际写入的文件。

appendfsync everysec

默认为everysec。
aof持久化策略的配置
no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
always表示每次写入都执行fsync，以保证数据同步到磁盘。
everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
always对硬盘压力大；everysec是一个平衡值；no对硬盘压力最小，但调度由系统控制，丢失数据风险最大，在大数据操作时可以考虑。

no-appendfsync-on-rewrite yes

重点关注！！默认为no。是否在后台写时同步单写，默认值no（表示需要同步）。这里的后台写，表示后台正在重写文件（包括bgsave和bgrewriteaof。bgrewriteaof网上很多资料都没有涉及到。其实关掉bgsave之后，主要的即是aof重写文件了）。no表示新的主进程的set操作会被阻塞掉，而yes表示新的主进程的set不会被阻塞，待整个后台写完成之后再将这部分set操作同步到aof文件中。但这可能会存在数据丢失的风险(机率很小)，如果对性能有要求，可以设置为yes，仅在后台写时会异步处理命令。
bgrewriteaof机制，在一个子进程中进行aof的重写，从而不阻塞主进程对其余命令的处理，同时解决了aof文件过大问题。
现在问题出现了，同时在执行bgrewriteaof操作和主进程写aof文件的操作，两者都会操作磁盘，而bgrewriteaof往往会涉及大量磁盘操作，这样就会造成主进程在写aof文件的时候出现阻塞的情形，现在no-appendfsync-on-rewrite参数出场了。如果该参数设置为no，是最安全的方式，不会丢失数据，但是要忍受阻塞的问题。如果设置为yes呢？这就相当于将appendfsync设置为no，这说明并没有执行磁盘操作，只是写入了缓冲区，因此这样并不会造成阻塞（因为没有竞争磁盘），但是如果这个时候redis挂掉，就会丢失数据。丢失多少数据呢？在linux的操作系统的默认设置下，最多会丢失30s的数据。
因此，如果应用系统无法忍受延迟，而可以容忍少量的数据丢失，则设置为yes。如果应用系统无法忍受数据丢失，则设置为no。

auto-aof-rewrite-percentage 100

默认为100。aof文件增长比例，指当前aof文件比上次重写的增长比例大小。aof重写即在aof文件在一定大小之后，重新将整个内存写到aof文件当中，以反映最新的状态(相当于bgsave)。这样就避免了，aof文件过大而实际内存数据小的问题(频繁修改数据问题)。
aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb

默认为64mb。aof文件重写最小的文件大小，即最开始aof文件必须要达到这个文件时才触发，后面的每次重写就不会根据这个变量了（根据上一次重写完成之后的大小）。此变量仅初始化启动redis有效。如果是redis恢复时，则lastSize等于初始aof文件大小。
设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写

以上两个设置为且的关系。

aof-load-truncated yes

默认为yes。aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
指redis在恢复时，会忽略最后一条可能存在问题的指令。默认值yes。即在aof写入时，可能存在指令写错的问题（突然断电，写了一半），这种情况下，yes会log并继续，而no会直接恢复失败。

aof-use-rdb-preamble yes

4版本默认为no，5版本默认为yes。是否开启混合模式。
重写AOF文件时，Redis可以使用AOF文件中的RDB前同步码来更快地进行重写和恢复。 启用此选项后，重写的AOF文件由两个不同的节组成：
[RDB文件] [AOF尾巴]
加载时，Redis会识别AOF文件以“ REDIS”字符串开头并加载带前缀的RDB文件，然后继续加载AOF尾部。
当前默认情况下处于关闭状态，以避免出现格式更改的意外情况，但是在某些时候将用作默认值。