Redis 第3章 Redis配置文件 第4章 持久化
1.单位说明
1k和1kb是不同的；单位的大小写不敏感！
2. include
可以将公共的配置放入到一个公共的配置文件中，然后通过子配置文件引入父配置文件中的内容！
将配置按照模块分开！
3. network
|
属性 |
含义 |
备注 |
|
bind |
限定访问的主机地址 |
如果没有bind，就是任意ip地址都可以访问。生产环境下，需要写自己应用服务器的ip地址。 |
|
protected-mode |
安全防护模式 |
如果没有指定bind指令，也没有配置密码，那么保护模式就开启，只允许本机访问。 |
|
port |
端口号 |
默认是6379 |
|
tcp-backlog |
网络连接过程中，某种状态的队列的长度 |
edis是单线程的，指定高并发时访问时排队的长度。超过后，就呈现阻塞状态。可以理解是一个请求到达后至到接受进程处理前的队列长度。（一般情况下是运维根据集群性能调控）高并发情况下，此值可以适当调高。 |
|
timeout |
超时时间 |
默认永不超时 |
|
tcp-keepalive |
对客户端的心跳检测间隔时间 |
|
4. general
|
属性 |
含义 |
备注 |
|
daemonize |
是否为守护进程模式运行 |
守护进程模式可以在后台运行 |
|
pidfile |
进程id文件保存的路径 |
配置PID文件路径，当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面 |
|
loglevel |
定义日志级别 |
debug（记录大量日志信息，适用于开发、测试阶段） verbose（较多日志信息） notice（适量日志信息，使用于生产环境） warning（仅有部分重要、关键信息才会被记录） |
|
logfile |
日志文件的位置 |
当指定为空字符串时，为标准输出，如果redis以守护进程模式运行，那么日志将会输出到/dev/null |
|
syslog-enabled |
是否记录到系统日志 |
要想把日志记录到系统日志服务中，就把它改成 yes |
|
syslog-ident |
设置系统日志的ID |
|
|
syslog-facility |
指定系统日志设置 |
必须是 USER 或者是 LOCAL0-LOCAL7 之间的值 |
|
databases |
设置数据库数量 |
|
5. 其他
|
属性 |
含义 |
备注 |
|
requirepass |
设置密码 |
|
|
maxclients |
最大连接数 |
|
|
maxmemory |
最大占用多少内存 |
一旦占用内存超限，就开始根据缓存清理策略移除数据如果Redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”， 那么Redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。 |
|
maxmemory-policy noeviction |
缓存清理策略
|
（1）volatile-lru：使用LRU算法移除key，只对设置了过期时间的键 （2）allkeys-lru：使用LRU算法移除key （3）volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键 （4）allkeys-random：移除随机的key （5）volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key （6）noeviction：不进行移除。针对写操作，只是返回错误信息 |
|
maxmemory-samples |
样本数 |
样本数越小，准确率越低，但是性能越好。LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小。一般设置3到7的数字。 |
第4章 持久化
Redis主要是工作在内存中。内存本身就不是一个持久化设备，断电后数据会清空。所以Redis在工作过程中，如果发生了意外停电事故，如何尽可能减少数据丢失。
1. RDB
1.1 RDB简介
RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
工作机制：每隔一段时间，就把内存中的数据保存到硬盘上的指定文件中。
RDB是默认开启的！
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能丢失。
1.2 RDB保存策略
save 900 1 900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10 300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000 60 秒内如果至少有 10000 个 key 的值变化，则保存
save “” 就是禁用RDB模式；
1.3 RDB常用属性配置
|
属性 |
含义 |
备注 |
|
save |
保存策略 |
|
|
dbfilename |
RDB快照文件名 |
|
|
dir |
RDB快照保存的目录 |
必须是一个目录，不能是文件名。最好改为固定目录。默认为./代表执行redis-server命令时的当前目录！ |
|
stop-writes-on-bgsave-error |
是否在备份出错时，继续接受写操作 |
如果用户开启了RDB快照功能，那么在redis持久化数据到磁盘时如果出现失败，默认情况下，redis会停止接受所有的写请求 |
|
rdbcompression |
对于存储到磁盘中的快照，可以设置是否进行压缩存储。 |
如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话， 可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。 |
|
rdbchecksum |
是否进行数据校验 |
在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗， 如果希望获取到最大的性能提升，可以关闭此功能。 |
1.4 RDB数据丢失的情况
两次保存的时间间隔内，服务器宕机，或者发生断电问题。
1.5 RDB的触发
①基于自动保存的策略
②执行save，或者bgsave命令！执行时，是阻塞状态。
③执行flushdb命令，也会产生dump.rdb，但里面是空的，没有意义。
④当执行shutdown命令时，也会主动地备份数据。
1.6 RDB的优缺点
2. AOF
2.1 AOF简介
- AOF是以日志的形式来记录每个写操作，将每一次对数据进行修改，都把新建、修改数据的命令保存到指定文件中。Redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。
- 默认不开启，需要手动开启
- AOF文件的保存路径，同RDB的路径一致。
- AOF在保存命令的时候，只会保存对数据有修改的命令，也就是写操作！
- 当RDB和AOF存的不一致的情况下，按照AOF来恢复。因为AOF是对RDB的补充。备份周期更短，也就更可靠。
2.2 AOF保存策略
appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！
appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。
appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。
推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。
2.3 AOF常用属性
|
属性 |
含义 |
备注 |
|
appendonly |
是否开启AOF功能 |
默认是关闭的 |
|
appendfilename |
AOF文件名称 |
|
|
appendfsync |
AOF保存策略 |
官方建议everysec |
|
no-appendfsync-on-rewrite |
在重写时，是否执行保存策略 |
执行重写，可以节省AOF文件的体积；而且在恢复的时候效率也更高。 |
|
auto-aof-rewrite-percentage |
重写的触发条件 |
当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写 |
|
auto-aof-rewrite-min-size |
设置允许重写的最小aof文件大小 |
避免了达到约定百分比但尺寸仍然很小的情况还要重写 |
|
aof-load-truncated |
截断设置 |
如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load |
2.4 AOF文件的修复
如果AOF文件中出现了残余命令，会导致服务器无法重启。此时需要借助redis-check-aof工具来修复！
命令： redis-check-aof –fix 文件
2.5 AOF的优缺点
优点：
- 备份机制更稳健，丢失数据概率更低
- 可读的日志文本，通过操作AOF稳健，可以处理误操作
-
缺点：
- 比起RDB占用更多的磁盘空间
- 恢复备份速度要慢
- 每次读写都同步的话，有一定的性能压力
- 存在个别Bug，造成恢复不能
3. 备份建议
3.1 如何看待数据“绝对”安全
Redis作为内存数据库从本质上来说，如果不想牺牲性能，就不可能做到数据的“绝对”安全。
RDB和AOF都只是尽可能在兼顾性能的前提下降低数据丢失的风险，如果真的发生数据丢失问题，尽可能减少损失。
在整个项目的架构体系中，Redis大部分情况是扮演“二级缓存”角色。
二级缓存适合保存的数据
- 经常要查询，很少被修改的数据。
- 不是非常重要，允许出现偶尔的并发问题。
- 不会被其他应用程序修改。
如果Redis是作为缓存服务器，那么说明数据在MySQL这样的传统关系型数据库中是有正式版本的。数据最终以MySQL中的为准。
3.2 官方建议
-
官方推荐两个都用；如果对数据不敏感，可以选单独用RDB；不建议单独用AOF，因为可能出现Bug;如果只是做纯内存缓存，可以都不用
