开发者学堂课程【Redis 入门实战演练： 配置文件详解、RDB 及 AOF 备份机制（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/653/detail/10835
配置文件详解、RDB 及 AOF 备份机制（一）
内容介绍
一、Redis 配置文件
二、Redis 持久化
三、选择与使用
一、Redis 配置文件
讲解 appendonly no#，它的简称是 AOF。
appendonly no#是否开启 AOF 日志记录，默认 redis 使用的是 rdb 方式持久化,这种方式在许多应用中已经足够用了，但是redis如果中途宕机，会导致可能有几分钟的数据丢失(取决于dumpd 教据的间隔时间)，根据save来策略进行持久化，Append Only File 是另一种持久化方式，可以提供更好的持久化特性，Redis 会把每次写入的数据在接收后都写入 appendonly.aof 文件，每次启动时 Redis 都会先把这个文件的数据读入内存里，先忽略 RDB 文件。
1、appendfsync everysec
打开 appendonly no#文件多久保存一次是由appendfsync everysec #aof 这个参数来控制的，appendfsync everysec #aof 持久化策略的配置。有三个选项可以设置appendfsync everysec #aof，一个是 always，一个是 everysec,一个是 no,这三个选项各有代表的含义，no 表示不执行 fsync，即由操作系统保证数据向步到磁盘；always 表示每次写入都执行 fsync，以保证数据同步到磁盘；everysec 表示每一秒执行一次 fsync，把文件保存到磁盘上，但是每秒的保存方式可能会导致这1s数据的丢失。每一秒钟执行一次 fsync，把文件保存到磁盘上，向磁盘刷新数据，就可能导致一秒数据的丢失，我们知道一秒钟有1000毫秒，假设在一个时间点刚作了一次 appendfsync，下一个时间点就是1秒钟之后，把数据向磁盘刷新一次，但假如过了800毫秒或是900毫秒还没有达到一秒钟的时候突然断电，这只是一种极端情况，这时候有一部分内容还没写入磁盘，这可能就会导致内容的丢失。一秒钟往磁盘上写一次，间隔时间很短，所以我们通常都使用默认参数 everysec，这个参数就是一秒钟往磁盘写入一次。如果认为这个时间比较长，可以更改为 always。always 是一旦往里面写入数据，就把它直接写入到磁盘上的AOF文件里，这种的数据一致性写入效果最好，但是每一个 key 都写入一次会消耗磁盘。因此最好选择每秒钟一次的写入方式，即 everysec，这一秒钟无论发生多少key，10个、100个或是1000个都只在一秒钟写入一次。
2、no-appendfsync-on-rewrite
(1) 是否重写
no-appendfsync-on-rewrite，在 aof rewrite 期间,会涉及到 aof-rewrite 机制，通过参数设置 aof-rewrite 的大小。auto-aof-rewrite-min-size 64mb是触发 aof rewrite 的最小文件大小，最小文件的大小可以更改，不仅仅是64mb,也可以是128mb等。如果达到了最小文件的大小，会进行重写，达到减小 aof 文件的效果，这是因为aof文件的特性就是从上到下顺序记录，会把创建在 del 之后的数据清空掉，从而降低日志内容。auto-aof-rewrite-percentage 100，则表示当 Aof log 增长超过指定百分比例时，例如当最小文件大小设置为64mb 时，它的百分比例就是128mb，同理最小文件大小为1228mb 时，百分比例为256mb.也会重写一次 AOF 文件，设置为0表示不自动重写 Aof 日志。当然重写依据实际数量的大小来进行更改，如果数据量很少就没有必要进行重写，而数据量很大的时候，也要对最小文件大小进行更改，不一定非要是64mb。重写与否不会影响后续的使用，重写是为了使 aof 体积保持最小，但同时还可以确保保存最完整的数据；并且可以时 redis 在后期更快的恢复数据。如果日志文件不进行重写，创建出来之后占用了磁盘空间，并消耗了磁盘性能。
(2) 是否延迟
是否对 aof 新记录的 append 暂缓使用文件同步策略(前文所讲 always、everysec、no),主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no,表示"不暂缓"，表示新的 aof 记录仍然会被立即同步到日志文件里。Linux 的默认 fsync 策略是30秒，如果为 yes，表示暂缓一段时间再将日志同步到 aof 文件里，这可能会导致30秒数据的丢失,但是由于 yes 性能较好而且会避兔出现阻塞因此比较推荐。当然，如果磁盘性能较好，可以设置为 no，不暂缓使用文件同步策略，进行实时的数据同步。
3、aof-load-truncated yes
是否加载由于其他原因导致的末尾异常的 AOF 文件，异常通常是主进程被ki/断电等强制撤掉，导致 redis 没有正常退出，进而导致尾部的异常。yes 表示正常加载异常文件。
4、aof-use-rdb-preamble no
redis4.0 新增的 RDB-AOF 混合持久化格式，在开启了这个功能之后，AOF 重写产生的文件将同时包含RDB格式的内容和 AOF 格式的内容，其中 RDB 格式的内容用于记录已有的数据，而 AOF 格式的内存则用于记录最近发生了变化的数据，这样Redis就可以同时兼有 RDB 持久化和 AOF 持久化的优点，既能够快速地生成重写文件,也能够在出现问题时，快速地载入数据以及发生变化的数据，数据的一致性比 RDB 好。默认以 no 打开，因为这是 redis4.0新增的一种模式，技术还不够成熟，不确定是否能将数据的一致性完整地保留下来，因此我们再次不加以使用了。而 RDB 和 AOF 已经在多个版本加以使用了，技术相对成熟了，因此对这两个技术我们使用的更多一些。
RDB 和 AOF 主要用于备份数据，不考虑数据丢失，也可以不使用重写。为了安全考虑，最好将 rdb 开启。
5、LUA 脚本
一般情况下我们 对 LUA 脚本的执行也是很少的，如果想要执行，可以进行配置，lua time limit5000表示限制的执行时间为5000毫秒，即5秒。lua 脚本的最大执行时间单位为毫秒。
6、REDIS CLUSTER
cluster-enabled yes 是否开启集群模式,默认情况下不开启集群模式。而如果要创建Redis Cluster则必须要开启集群模式，否则是无法完成创建的。
cluster-config-file nodes-6379.conf，表示 Redis Cluster 的配置文件，只需要指定名称就可以了。这个文件会由 node 集群节点自动生成，即不需要进行手动支配。
cluster-node-timeout 15000，表示 Redis 集群中 node 节点连接超时时间，即确定经过多长时间后节点还没有完成配置就可以认为连接超时。单位也是毫秒，15000毫秒就是15秒，即15秒之后 Redis Cluster 的节点还没有完成连接成功，就认为连接超时了。
cluster-replica-validity-factor 10，在执行故障转移的时候可能有些节点和master断开一段时间，数据比较旧。这些节点就不适用于选举为master，超过这个时间(即10秒)的节点就不会被进行故障转移。例如三个 monster，六个节点，表示一主两从，每一个 monster 和两个节点各有关系，当一个 monster 所对应的节点表示12秒之前的内容，另一个节点表示8秒之前的内容，很明显12秒的节点就比较旧，故12秒的节点就不会进行故障转移了。此处的单位是秒，10秒的时间已经足够长了，因此我们选用默认值10即可。
cluster-migration-barrier 1表示集群迁移屏障,1指的是个数，表示一个主节点(monster)拥有的至少可以正常工作的从节点个数，即如果主节点的 slave 节点故隙后会将多余的从节点分配到当前主节点成为其新的从节点，当 monster 没有出现故障但 slave 出现故障时，这种情况也是有可能出现的，这时候会将故障节点移除，从其他地方移入可以正常工作的节点作为当前 monster slave，从而保证monster 有一个可以正常使用的从节点。monster 出现故障后，从节点就会接替它的工作，进行数据的传递，从节点的接替工作是自动的，相对于 MYSQl 来说更加的智能，不需要人为的操作。
cluster-require-ful-coverage no ，表示集群请求槽位全部覆盖，这是redis集群的一个特性，redis集群实现的机制是分片，整个 redis 共用16384个槽位，可以理解成有16384个槽位去存储数据。这16384个槽位会平均分配给 monster，即槽位只在 monster 中产生，slave是没有槽位的，只对 monster 的数据进行继承。只有当 monster 出现故障被剔除之后，slave 才会结果 monster 的职能，从而也就继承了 monster 的槽位。如果一个主库宕机且没有备库就会出现集群槽位不全，此时yes情况下redis集群槽位验证不全，就不会再对外提供服务，这是因为yes情况要求整个集群的槽位必须是16384个，一旦少了一个，经校验后，读取数据时都会报错，无法进行数据的读取；而no情况下则可以继续使用但是会出现查询数据查不到或是写入不成功的情况，这是因为有数据的丢失。后续我们会学到一种算法(取模法)去决定读取的数据位于哪一个主机，应用程序在写入数据时，会把数据进行16384取模校验，因此取完模之后数据一定在16384以内(小于等于16384)取完模之后在1-5000的数据就会在第一个主机，5001-10000的数据就在第二个主机里，其余的数据全部存储在第三主机里。假设第一个 monster 中有5000个槽位，第二个 monster 中也有5000个槽位，最后一个 monster 具有6384个槽位，如果最后一组 redis 服务器全部出现了故障，那么最后一个 monster 槽位的数据也会全部丢失，出发具有跨主机的备份文件，否则这些数据就是彻底的丢失，此时整个机位的可用数据就只剩下10000个，这种情况就称为 redis 机位的不全。
7、Slow log
Slow log 是 Redis 用来记录查询执行时间的日志系统，slow log 保存在内存里面，读写速度非常快，因此你可以放心地使用它,不必担心因为开启 slow log 而损害Redis 的速度。
设置慢日志：设置慢日志时要开启两个参数，一个是slowlog-log-slower-than 10000，超过设定时间就记录为慢日志，设置时以微秒为单位进行记录慢日志；slowlog-max-len 128表示记录多少条慢日志保存在队列，超出后会删除最早的慢日志，是以轮询的方式写入慢日志的。相当于一个数据环，从数据环中的一侧开始写入慢数据，直到写满规定的条数，写满之后会把最初写入的慢数据覆盖掉，覆盖成新的慢日志，以此在该数据环上滚动删除。
进入 redis 的命令行窗口，使用slowlog len查看是否具有数据，可以看到在10毫秒内没有数据，将slowlog-log-slower-than 10000更改为1毫秒时，就具有了数据，使用slowlog get 就可以将所有数据返回出来，这样就可以查询出 redis 中操作较慢的地方，并把这些地方调出来发给开发商让他们进行修改提升。使用slowlog reset可以将日志清空。
