linux上怎么配置redis的aof持久化

Redis 持久化和配置文件

Reids 持久化

Redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上。

AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

redis配置文件

daemonize no # 默认情况下，redis并不是以daemon形式来运行的。通过daemonize配置项可以控制redis的运行形式

pidfile /path/to/redis.pid#当以daemon形式运行时，redis会生成一个pid文件，默认会生成在/var/run/redis.pid

bind 192.168.1.2 10.8.4.2 # 指定绑定的ip，可以有多个

port 6379 #指定监听端口

unixsocket /tmp/redis.sock #也可以监听socket

unixsocketperm 755 #当监听socket时可以指定权限为755

timeout 0 #当一个redis-client一直没有请求发向server端，那么server端有权主动关闭这个连接，可以通过timeout来设置“空闲超时时限”，0表示永不关闭。

Redis通用配置

tcp-keepalive0 #TCP连接保活策略，可以通过tcp-keepalive配置项来进行设置，单位为秒，假如设置为60秒，则server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接。如果设置为0，则不会进行保活检测。

loglevelnotice #日志级别，有四种debug, verbose, notice, warning

logfile“” #定义日志路径，

syslog-identredis #如果希望日志打印到syslog中，通过syslog-enabled来控制。另外，syslog-ident还可以让你指定syslog里的日志标志。

syslog-facility local0 #指定syslog的设备，可以是USER或者local0-local7

databases 16 #设置数据库的总数量

Redis快照配置（rdb持久化）

save 900 1 #表示每15分钟且至少有1个key改变，就触发一次持久化

save 300 10 #表示每5分钟且至少有10个key改变，就触发一次持久化

save 60 10000 #表示每60秒至少有10000个key改变，就触发一次持久

save “” #这样可以禁用rdb持久化

stop-writes-on-bgsave-error yes #rdb持久化写入磁盘避免不了会出现失败的情况，默认一旦出现失败，redis会马上停止写 *** 作。如果你觉得无所谓，那就可以使用该选项关闭这个功能。

rdbcompressionyes #是否要压缩

rdbchecksumyes #是否进行数据校验

dbfilenamedump.rdb #定义快照文件的名字

dir ./ #定义快照文件储存路劲

Redis安全相关配置

requirepassaminglinux

#设置redis-server的密码

rename-command CONFIG aminglinux.config

#将CONFIG命令更名为aminglinux.config，这样可以避免误 *** 作，但如果使用了AOF持久化，建议不要启用该功能

rename-command CONFIG “”

#也可以后面定义为空，这样就禁掉了该CONFIG命令

Redis限制相关配置

maxclients10000 #限制最大客户端连接数

maxmemory<bytes> #设定最大内存使用数，单位是byte

maxmemory-policy volatile-lru#指定内存移除规则

maxmemory-samples 3 #LRU算法和最小TTL算法都并非是精确的算法，而是估算值。所以你可以设置样本的大小。假如redis默认会检查三个key并选择其中LRU的那个，那么你可以改变这个key样本的数量。

Redis AOF持久化相关配置

appendonlyno #如果是no，则开启aof持久化

appendfilename“appendonly.aof” #指定aof文件名字

appendfsynceverysec#指定fsync()调用模式，有三种no(不调用fsync),always(每次写都会调用fsync),everysec(每秒钟调用一次fsync)。第一种最快，第二种数据最安全，但性能会差一些，第三种为这种方案，默认为第三种。

no-appendfsync-on-rewrite no #使用no，可以避免当写入量非常大时的磁盘io阻塞

auto-aof-rewrite-percentage 10 #规定什么情况下会触发aof重写。该值为一个比例，10表示当aof文件增幅达到10%时则会触发重写机制。

auto-aof-rewrite-min-size 64mb #重写会有一个条件，就是不能低于64Mb

Redis 慢日志相关配置

针对慢日志，你可以设置两个参数，一个是执行时长，单位是微秒，另一个是慢日志的长度。当一个新的命令被写入日志时，最老的一条会从命令日志队列中被移除。

数据持久化顾名思义就是把程序中的数据以某种形式保存到某存贮介质中，以达到持久化的目的。当程序运行时，一些数据是临时保存在内存中，一旦退出系统，这些数据就丢失了。那么，使用某种手段将数据保存在硬盘上或者数据库中，这样即使退出系统后又重新启动系统，那么这些数据仍然可以重新找回来。

例如管理员向一个用户管理系统中添加了一个用户的资料，那么这个系统需要将新添加的资料保存到数据库中，否则系统退出或者电脑重启后该用户资料就会丢失。将数据从内存保存到数据库中，这便是数据的持久化。当然，数据库只是持久化方式中的一种，也可以保存在其他的永久存贮介质中。

图为数据持久化的过程示意图。

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。

持久化是将程序数据在持久状态和瞬时状态间转换的机制。

DBC就是一种持久化机制。文件IO也是一种持久化机制。

日常持久化的方法

在一定周期内保持不变就是持久化,持久化是针对时间来说的。数据库中的数据就是持久化了的数据,只要你不去删除或修改。比如在浏览器中一次Session会话中Session对象变量也是不变的,是Session容器中持久化。对象持久化的方式有很多种,根据周期不同有,page,Session,Application。对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态. 对象序列化的过程是对象持久化的方法之一,把对象保存到文件中。

简单的理解持久化可以在二个层面：应用层和系统层、

应用层

如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。

系统层

如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。

持久化是一种对象服务实现至少3个接口

，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：

void Save(object o) 把一个对象保存到外存中

Object Load(object oid) 通过对象标识从外存中取回对象

boolExists(object oid) 检查外存中是否存在某个对象.

类似概念序列化

我们先跳开一下，看看另一个类似的有用概念：序列化Serialize也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：

void Serialize(Stream stream,object o) 把对象序列化到流中

object Deserialize(Stream stream) 把流反序列化成对象

序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在线程之间、进程之间、内存外存之间、主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。

持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案

现今主流的持久化方案是关系数据库方案，

关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。关系数据库和面向对象之间有一条鸿沟，因为二者模式不匹配，所以就存在一个OR映射问题。

Redis支持两种数据持久化方式：rdb方式和aof方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。

1、RDB方式

RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，redis默认开启该持久化功能，具体配置如下：

save 900 1

save 300 10

save 60 10000

stop-writes-on-bgsave-error yes

rdbcompression yes

rdbchecksum yes

dbfilename dump.rdb

#文件名称

dir ./

#rdb文件存放路径

配置后系统会自动进行快照，save 60 10000表示60秒内有10000次写入，那么就会调用bgsave

除了系统自动进行快照外，我们也可以手动执行SAVE或BGSAVE命令主动进行快照 *** 作：

执行SAVE或BGSAVE命令

执行FLUSHALL命令

2、AOF方式

在使用Redis存储非临时数据时，一般都需要打开AOF持久化来降低进程终止导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能。

默认情况下，Redis没有开启AOF（append only file）持久化功能，可以通过在配置文件中作如下配置启用：

appendonly no    #是否开启aof，开启时将no改为yes

appendfilename "appendonly.aof"   持久化文件名称

auto-aof-rewrite-percentage 100

#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 64mb

#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。

appendfsync :everysec (推荐配置)

#持久化策略

always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)

everysec (异步 *** 作，每秒记录，如果一秒钟内宕机，有数据丢失)

no  （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）

一般来说可以考虑同时使用两种持久化方案.

Redis支持RDB和AOF两种持久化机制 ，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

手动触发分别对应save和bgsave命令：

◆ (1).save命令

save命令： 阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。 运行save命令对应的Redis日志如下：

◆ (2).bgsave命令

bgsave命令Redis进程执行fork *** 作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。 运行bgsave命令对应的Redis日志如下：

RDB相关参数：

RDB启动方式，sava配置

RDB工作过程

RDB的优点：

1.RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

2.Redis加载RDB恢复数据远远快于AOF的方式。

RDB的缺点：

1.RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork *** 作创建子进程，属于重量级 *** 作，频繁执行成本过高。

2.RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

● AOF（append only file）持久化： 以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

● 开启AOF功能需要设置配置： appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。AOF的工作流程 *** 作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，appendfsync参数有以下几种设置方式。

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。

重写后的AOF文件为什么可以变小？有如下原因：

1）进程内已经超时的数据不再写入文件。

2）旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。

3）多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型 *** 作，以64个元素为界拆分为多条。

AOF重写过程可以手动触发和自动触发： ·

● 手动触发： 直接调用bgrewriteaof命令。 ·

● 自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。

bgrewriteaof流程如下：

当Redis做RDB或AOF重写时，一个必不可少的 *** 作就是执行fork *** 作创建子进程，对于大多数 *** 作系统来说fork是个重量级错误。虽然fork创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。例如对于10GB的Redis进程，需要复制大约20MB的内存页表，因此fork *** 作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是Xen虚拟 机，fork *** 作会更耗时。

fork耗时问题定位：

对于高流量的Redis实例OPS可达5万以上，如果fork *** 作耗时在秒级别将拖慢Redis几万条命令执行，对线上应用延迟影响非常明显。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统计中查latest_fork_usec指标获取最近一次fork *** 作耗时，单位微秒。

如何改善fork *** 作的耗时：

1）优先使用物理机或者高效支持fork *** 作的虚拟化技术，避免使用Xen。

2）控制Redis实例最大可用内存，fork耗时跟内存量成正比，线上建议每个Redis实例内存控制在10GB以内。

3）合理配置Linux内存分配策略，避免物理内存不足导致fork失败 4）降低fork *** 作的频率，如适度放宽AOF自动触发时机，避免不必要的全量复制等。

---