NoSQL入门第三天——Redis配置文件与持久化

一、解析Redis配置文件redis.conf

　　（Linux下配置多于编码）

　　1.它在哪

　　由于我是在root的家目录下载安装的，默认的安装位置就是：

　　conf就在这里：

　　根据经验，出厂的conf永远不要改

　　我们把conf拷贝出来一份改动，这里我们单独拷贝到/root/myredis下了

　　//这里centOS7默认是打开上次离开的位置

　　配置文件比较详细的介绍信息，例如：

　　　　Units单位——大小写不敏感的：

　　　　INCLUDES包含——类似于分模块开发下配置文件分为spring-shiro,spring-context等分模块引入

　　　　GENERAL通用

　　　　出厂默认设置是 no　——设置为yes 使其以 守护进程 的形式可以在后台运行

　　　　默认进程管道id文件——pid

PID就象身份证号码一样,一个进程只有一个PID,但不同每个进程的PID是会改变的,不信你可以结束QQ.EXE进程再开开,PID是不同的\ 
无法靠PID识别病毒进程,PID只是在一段时间帮你识别同宜进程

　　　　端口——默认6379

　　　　TCP -backlog511——默认值511

tcp-backlog
设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值
来达到想要的效果

　　　　绑定：——初学阶段，就绑定本机127.0.0.1即可

　　　　timeout——过期时间，可以设置多少秒后不连接则关闭会话，默认0为不关闭

　　　　查看网络通讯状态

　　　　日志等级——和Log4j类似的级别

　　　　日志文件名字：——可以为空

　　　　日志开关——默认syslog-enabled no，默认是关，如果开了，将会以redis开头

　　　　数据库的配置：——默认16个库 0-15

　　　　SNAPSHOTTING快照

　　快照是将数据保存到磁盘上，保存的格式为：save seconds changes

　　　

　　满足以下条件：（15分钟改过1次；5分钟改过10次；1分钟改过10000次）——改过就是增加或修改等（除了查）

　　如果想禁用可以根据提示放开指定注释：

　　为了测试以下，我们把5分钟修改10次改为120：然后保存退出

 　　测试之前，回忆一下查看redis是否正确启动：

　　启动redis:（详见安装于配置的随笔）

　　执行两分钟改动10次的操作（剩余操作同理）

　　我们去redis目录下查看是否有dump.rdb

 　　//备份后恢复工作，一般备份文件不和工作的机器在同一机器上。

　　我们暂且通过这样模拟备份文件到另外一台机器的过程：

　　　//命名可以改成dump_bak.rdb

　　在配置文件中可以看到，默认是去找dump.rdb：

　　我们可以试试直接FLUSHALL，再SHUTDOWN关机，迅速斩断内存，形成dump.rdb文件，由于之前FLUSHALL清空了，所以此时的dump.rdb是一个空文件；

　　再开机发现KEYS *还是空（因为恢复的是空文件），我们可以模拟运维从另外一台备份机器拷贝过来的备份文件：cp dump_bak.rdb dump.rdb，此时再开机，开启redis后，数据迅速恢复（内存非常快！）

　　测试完成我们再看仔细捋一捋快照的配置：

　　　　1.Save操作： save 秒钟 写操作次数可以实现备份，直接打save命令实现即刻备份生效（不等上面的2分钟10次修改了）

　　　　2.禁用：save ""，见上文

　　　　3.stop-writes-on-bgsave-error：出错了不再执行写操作——默认是yes

　　　　4. rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。——默认是yes

　　　　5. rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验（增加一些消耗）——默认yes

　　　　6. dbfilename：备份文件名（不再赘述）

　　　　7. dir：指定本地数据库存放目录;config getdir获得目录

　　　REPLICATION复制

　　　　SECURITY安全

　　　　启动的时候是发现不用输入密码的，它默认认为装在Linux上，是一个相对安全的地方，所以是不用输入密码的：

 　　访问密码的查看、设置和取消

　　　　输入密码验证：（auth+密码验证）

　　　　取消密码：

　　　　LIMITS限制

 　　　　最大客户端连接数——默认10000

设置redis同时可以与多少个客户端进行连接。默认情况下为10000个客户端。当你
无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自
身内部处理逻辑留一些句柄出来。如果达到了此限制，redis则会拒绝新的连接请求，并且向这
些连接请求方发出“max number of clients reached”以作回应。

　　　　　最大内存：——缓存移除策略，过期策略

果redis无法根据移除规则来移除内存中的数据，或者设置了“不允许移除”，
那么redis则会针对那些需要申请内存的指令返回错误信息，比如SET、LPUSH等。


但是对于无内存申请的指令，仍然会正常响应，比如GET等。如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，只有在你设置的是“不移除”的情况下，才不用考虑这个因素

　　　　最大内存策略

　　//过期策略的选择（lru——最近最小策略），默认是永不过期（实际生成不可能采用此策略）

　　　　最大内存样本：默认5个

 

　　APPEND ONLY MODE追加

 

　　默认是异步进行的：

　

　　再往下发现默认是关必的：——为了测试实验，将此项改为 yes 

　　

　　

　　默认的文件名字：——就用默认的就行 appendonly.aof

 　　

　　再稍微往后看混个眼熟，又发现有三种策略：（这里暂时不详细介绍）

　　我们保存退出，来到/usr/local/bin目录下看，发现此时是没有appendonly.aof文件的

　　启动服务，再关闭，发现aof文件就存在了！

　　我们启动服务来设置一点值：（通过前面我们知道，FLUSHALL(删除所有现有的数据库)

　　后dump.rdb其实是为空的，所以如果成功恢复应该是aof的功劳）

　　我们可以打开aof文件来看看：

　　我们启动服务检查是否正确恢复，发现是空！：

　　其实我们再检查备份文件，就会发现aof文件最后一行也忠实的记录了：FLUSHALL —— 删除了所有的数据库！所以当然恢复的也是空了

　　如果想看到恢复效果，可以将FLUSHALL这一行删除（仅作测试用，实际不应该改aof文件，当然，实际也不可能会写FLUSHALL这样的指令）

　　谈到改aof文件，如果aof文件通过认为修改或意外操作导致aof文件损坏！

　　如果aof和rdb同时存在，而aof文件损坏了，能否正常启动redis呢？如果能，说明先找的rdb，数据正常恢复，如果报错，说明先找的aof，而aof文件损坏，导致启动失败：

　　//可以看到，报错了，是aof文件损坏

　　如何修复：

　　//会由checkaof自动删除错乱信息，修复aof

　　再打开配置文件，发现官方说法是可以与RDB和谐共存的：

　　同样的，我们来捋一捋这个配置：

　　　　 1. appendonly，是否开启aof，默认是关(no),改为yes即可开启

　　　　2. appendfilename，配置文件名字，当然就取默认就OK了

　　　　3.appendfsync，三种策略：

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

　　　　　　everysec：出厂默认推荐，异步操作，每秒记录   如果一秒内宕机，有数据丢失

　　　　　　no

　　　　4.no-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。

　　　　5.auto-aof-rewrite-min-size：设置重写的基准值

　　　　6.auto-aof-rewrite-percentage：设置重写的基准值

　　　　常见配置：

参数说明
redis.conf 配置项说明如下：
1. Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
  daemonize no
2. 当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
  pidfile /var/run/redis.pid
3. 指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
  port 6379
4. 绑定的主机地址
  bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
  timeout 300
6. 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
  loglevel verbose
7. 日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
  logfile stdout
8. 设置数据库的数量，默认数据库为0，可以使用SELECT <dbid>命令在连接上指定数据库id
  databases 16
9. 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
  save <seconds> <changes>
  Redis默认配置文件中提供了三个条件：
  save 900 1
  save 300 10
  save 60 10000
  分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
 
10. 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
  rdbcompression yes
11. 指定本地数据库文件名，默认值为dump.rdb
  dbfilename dump.rdb
12. 指定本地数据库存放目录
  dir ./
13. 设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
  slaveof <masterip> <masterport>
14. 当master服务设置了密码保护时，slav服务连接master的密码
  masterauth <master-password>
15. 设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH <password>命令提供密码，默认关闭
  requirepass foobared
16. 设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
  maxclients 128
17. 指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
  maxmemory <bytes>
18. 指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
  appendonly no
19. 指定更新日志文件名，默认为appendonly.aof
   appendfilename appendonly.aof
20. 指定更新日志条件，共有3个可选值： 
  no：表示等操作系统进行数据缓存同步到磁盘（快） 
  always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全） 
  everysec：表示每秒同步一次（折衷，默认值）
  appendfsync everysec
 
21. 指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
   vm-enabled no
22. 虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
   vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
   vm-max-memory 0
24. Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
   vm-page-size 32
25. 设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
   vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
   vm-max-threads 4
27. 设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
  glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
  hash-max-zipmap-entries 64
  hash-max-zipmap-value 512
29. 指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
  activerehashing yes
30. 指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
  include /path/to/local.conf

二、Redis的持久化

　　核心就是RDB和AOF两种方式

　　1.概述

　　　详细概述可以参见官网（这里给出中文网站介绍）：http://www.redis.cn/topics/persistence.html

　　 2.RDB（Redis DataBase）

　　　　2.1 是什么：

　　　　在指定的时间间隔内将内存中的数据集快照写入磁盘，
　　　　也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

　　　　

　　　　Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到
　　　　一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。
　　　　整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能
　　　　如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方
　　　　式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。——可能还没到5分钟就出故障了，此次持久化数据就可能丢失！

　　　　2.2 fork （并不是github的fork）

　　　　fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）
　　　　数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

　　　　2.3 rdb 保存的是dump.rdb文件

 　　　　更多在上一节conf配置快照部分

　　　　如何触发RDB：

　　　　　　配置文件中默认的快照配置

　　　　　　　　冷拷贝后重新使用，可以cp dump.rdb dump_new.rdb

　　　　　　命令save或者是bgsave

　　　　　　　　bgsave是后台异步备份

　　　　　　执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

　　　　如何恢复：

　　　　　　将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可

　　　　　　CONFIG GET dir获取目录

　　　　优势:

　　　　　　适合大规模的数据恢复

　　　　　　对数据完整性和一致性要求不高

　　　　劣势:　　　　　　　　

　　　　　　　在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改

　　　　　　fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

　　　　如何停止：

　　　　　　动态所有停止RDB保存规则的方法：redis-cli config set save ""

　　3.AOF（Append Only File）

　　　　既然有了RDB，为什么要有AOF呢，它与RDB的区别是什么？它的优势劣势又分别是什么？它与RDB是二选一还是协同工作？带着这些问题，我们来看看AOF。

　　2.1 是什么

 

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

　　2.2 Aof保存的是appendonly.aof文件

　　更多在上一节conf配置 APPEND ONLY MODE追加

 　　配置位置

　　　　conf配置文件，APPEND ONLY MODE，详见上一节相关位置

　　启动与恢复

　　　　修改默认的appendonly no，改为yes，即可启动

　　　　将有数据的aof文件复制一份保存到对应目录(config get dir)

　　　　恢复：重启redis然后重新加载

　　　　异常修复：redis-check-aof --fix进行修复（dump修复同理）

　　rewrite

　　　　上节配置出也有相关的配置介绍

　　　　是什么？

 

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,
当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

 

　　　　重写原理

 

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，
遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，
而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似

 

　　　　触发机制（在萌芽的时候便进行扼杀）

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发

　　　优势

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

　　　　每秒同步：appendfsync everysec    异步操作，每秒记录   如果一秒内宕机，有数据丢失

　　　　不同步：appendfsync no   从不同步

　　  劣势

　　　　相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb

　　　　aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同

　　4.小结

　　　　关于持久化的方案选择，我们可以先看看官网的建议：

 

• 如何选择使用哪种持久化方式？

 

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

 

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

 

有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

 

Note: 因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是一个长期计划。） 接下来的几个小节将介绍 RDB 和 AOF 的更多细节。

 

　　　　RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

　　　　AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些
　　　　命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.
　　　　Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

　　　　只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

　　　　同时开启两种持久化方式

　　　　　  1.　在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,
　　　　　　因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.

　　　　　2. RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？

　　　　　　作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，
　　　　　　快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

　　　　　　建议：

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。


如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。


如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构