redis.conf存放位置：

Redis的安装根目录下，Redis在启动时会加载这个配置文件，在运行时按照配置进行工作。 这个文件有时候我们会拿出来，单独存放在某一个位置，启动的时候必须明确指定使用哪个配置文件，此文件才会生效。

Redis 的网络相关配置

bind：

绑定IP地址，其它机器可以通过此IP访问Redis，默认绑定127.0.0.1，也可以修改为本机的IP地址。

port：

配置Redis占用的端口，默认是6379。

tcp-keepalive：

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

12.3Redis的常规配置

1、loglevel：日志级别，开发阶段可以设置成debug，生产阶段通常设置为notice或者warning.
2、logfile：指定日志文件名，如果不指定，Redis只进行标准输出。要保证日志文件所在的目录必须存在，文件可以不存在。还要在redis启动时指定所使用的配置文件，否则配置不起作用。
3、databases：配置Redis数据库的个数，默认是16个。

Redis的安全配置

requirepass：配置Redis的访问密码。默认不配置密码，即访问不需要密码验证。此配置项需要在protected-mode=yes时起作用。使用密码登录客户端：redis-cli -h ip -p 6379 -a pwd

12.5Redis的RDB配置

1、save ：配置复合的快照触发条件，即Redis 在seconds秒内key改变changes次，Redis把快照内的数据保存到磁盘中一次。默认的策略是：
1分钟内改变了1万次
或者5分钟内改变了10次
或者15分钟内改变了1次
如果要禁用Redis的持久化功能，则把所有的save配置都注释掉。
2、stop-writes-on-bgsave-error：当bgsave快照操作出错时停止写数据到磁盘，这样能保证内存数据和磁盘数据的一致性，但如果不在乎这种一致性，要在bgsave快照操作出错时继续写操作，这里需要配置为no。
3、rdbcompression：设置对于存储到磁盘中的快照是否进行压缩，设置为yes时，Redis会采用LZF算法进行压缩；如果不想消耗CPU进行压缩的话，可以设置为no，关闭此功能。
4、rdbchecksum：在存储快照以后，还可以让Redis使用CRC64算法来进行数据校验，但这样会消耗一定的性能，如果系统比较在意性能的提升，可以设置为no，关闭此功能。
5、dbfilename：Redis持久化数据生成的文件名，默认是dump.rdb，也可以自己配置。
6、dir：Redis持久化数据生成文件保存的目录，默认是./即redis的启动目录，也可以自己配置。

12.6Redis AOF配置

1、appendonly：配置是否开启AOF，yes表示开启，no表示关闭。默认是no。
2、appendfilename：AOF保存文件名
3、appendfsync：AOF异步持久化策略
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差但数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不即时同步，由操作系统决定何时同步。
4、no-appendfsync-on-rewrite：重写时是否可以运用appendsync，默认no，可以保证数据的安全性。
5、auto-aof-rewrite-percentage：设置重写的基准百分比
6、auto-aof-rewrite-min-size：设置重写的基准值

Redis的持久化

redis是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当redis所在服务器发生宕机后，redis数据库里的所有数据将会全部丢失。为了解决这个问题，redis提供了持久化功能——RDB和AOF（Append Only File）。

RDB

RDB（Redis DataBase）是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis重启会通过加载dump.rdb文件来恢复数据。

RDB原理：

Redis会复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，来进行持久化。
整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

RDB保存的文件：

RDB保存的文件是dump.rdb文件 ,位置保存在Redis的启动目录。Redis每次同步数据到磁盘都会生成一个dump.rdb文件，新的dump.rdb会覆盖旧的dump.rdb文件。

配置RDB 持久化策略

在redis.conf的快照配置中，配置RDB保存的策略。
在客户端执行FLUSHDB或者FLUSHALL或者SHUTDOWN时，也会把快照中的数据保存到dump.rdb，只不过这种操作已经把数据清空了，保存的也是空文件，没有意义。

手动保存RDB快照

save命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
由于save指令会阻塞所有客户端，所以保存数据库的任务通常由 BGSAVE 命令异步地执行，而save作为保存数据的最后手段来使用，当负责保存数据的后台子进程不幸出现问题时使用。

RDB数据恢复

通过脚本将Redis产生的dump.rdb文件备份(cp dump.rdb dump_bak.rdb)，每次启动Redis前，把备份的dump.rdb文件替换到Redis相应的目录(在redis.conf中配的的dir目录)下，Redis启动时会加载dump.rdb文件，并且把数据读到内存中。

RDB小结

Redis默认开启RDB持久化方式，适合大规模的数据恢复但它的数据一致性和完整性较差。

AOF

AOF(Append Only File)，Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF原理

Redis以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，
只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF保存的文件

AOF保存的文件是appendonly.aof文件 ,位置保存在Redis的启动目录。如果开启了AOF，Redis每次记录写操作都会往appendonly.aof文件追加新的日志内容。

配置AOF持久化策略

在redis.conf的“APPEND ONLY MODE”配置模块中，配置AOF保存策略。

AOF数据恢复

通过脚本将Redis产生的appendonly.aof文件备份(cp appendonly.aof appendonly_bak.aof)，每次启动Redis前，把备份的appendonly.aof文件替换到Redis相应的目录(在redis.conf中配的的dir目录)下，只要开启AOF的功能，Redis每次启动，会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。会把出现异常的部分往后所有写操作日志去掉。

AOF的重写

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。当然，也可以在配置文件中进行配置。

AOF小结：

Redis 需要手动开启AOF持久化方式，AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。

关于Redis持久化的使用：若只打算用Redis 做缓存，可以关闭持久化。若打算使用Redis 的持久化，建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
AOF与RDB模式可以同时启用，这并不冲突。如果AOF是可用的，那Redis启动时将自动加载AOF，这个文件能够提供更好的持久性保障。