- 1.1 Redis配置文件解析
- 1.2 Redis持久化
- 1.2.1 RDB (Redis DataBase)
- 1.2.2 AOF(Append Only File)
- 1.3 Redis事务
- 1.3.1 三阶段
- 1.3.2 三特性
- 1.4 Redis发布订阅
- 1.5 Redis主从复制
- 1.5.1 使用
- 1.5.2 主从复制相关细节知识点
- 1.5.3 复制原理
- 1.5.4 哨兵模式（setinel）
1.1 Redis配置文件解析
首先讲述一下Redis配置文件中的一些常用配置：
- Units单元
这里对一些字节表示做了相关的定义。配置大小单位，开头定义了一些基本的度量单位，只支持bytes，不支持bit，对大小写不敏感。 - INCLUDE
可以通过includes包含，redis.conf可以作为总闸，包含其他。 - 通用设置：
- Daemonize：守护线程启动
- Pidfile：进程管道文件
- Port： 端口号（默认：6379）
- Tcp-backlog：tcp-backing 551 ，设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列+已经完成三次握手队列。在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backing两个值来达到想要的效果。
- Timeout：0 不关闭，超时连接。
- Bind
- Tcp-keepalive： 单位为秒，如果设置为0，则不会进行Keepalive检测，建议设置成60，心跳机制！！！
- Loglevel：debug verbose notice warning 生产模式 级别越高，日志越少。
- Syslog-enabled： 是否把日志输出到syslog中。
- Syslog-ident： 指定syslog里的日志标志。
- Syslog-facility： 指定syslog设备，值可以是user或local0-local7，默认0。
- Databases： 默认16个库，select+id切换库。
- SNAPSHOTTING快照
Redis加入快照机制，主要也是为了备份。在配置文件里涉及到几个常见的命令。
- Save：RDB是整个内存压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，默认1分钟内改变了1万次，或5分钟内改了10次，或15分钟内改了1次。如果想禁用RDB持久化策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。
- Stop-writes-on-bgsave-error： 默认是yes，如果配置成no，表示不在乎数据不一致或者有其他的手段发现和控制。
- rdbcompression： 默认是yes，rdbcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果不想消耗CPU来进行压缩的话，可以设置为no关闭此功能。
- rdbchecksum： 默认是yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增大大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
1.2 Redis持久化
1.2.1 RDB (Redis DataBase)
- 是什么？
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时将快照文件直接读到内存里。
Redis会单独创建（Fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 - Fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量‘程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。 - 如何触发RDB快照：
- 配置文件中默认的快照配置：1.冷拷贝后重新使用 2.可以cp dump.rdb dump_new.rdb
- 命令save或者是bgsave： 1.Save：save时只管保存，其他不管，全部zuse 2. BGSAVE：Redis会在后台异步进行快照操作，快照操作同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
- 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。
- 如何恢复？
- 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可。
- CONFIG GET dir获取目录。
- 优点和缺点
优势： 适合大规模的数据恢复，对数据完整性和一致性要求不高。
缺点：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。Fork的时候，内存中的数据被克隆了一份，大约2倍的膨胀性需要考虑。 - 如何停止？
动态所有停止RDB保存规则的方法：redis-cli config set save ""。 - RDB总结
内存中的 ---rdbsave---> 磁盘中的
数据对象 <---rdbLoad--- RDB文件
RDB是一个非常紧凑的文件
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所有RDB持久化方式可以最大化redis的性能。
与AOF相比，在恢复大的数据集的时候，RDB方式会更快一些。
缺点：
数据丢失风险大
RDB需要经常fork子进程来保存数据集到硬盘上，当数据集比较大的时候，fork的过程是非常耗时的，可能导致Redis在一些毫秒级不能响应客户端请求。
1.2.2 AOF(Append Only File)
-
是什么？
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。
AOF保存的是appendonly.aof文件。Redis默认是不开启这种备份策略的，要使用必须先在配置文件里找到那一栏将no改为yes启用AOF。 -
正常恢复：将有数据的aof文件复制一份保存到对应目录（config get dir）。恢复：重启redis然后重新加载。
-
异常恢复：备份被写坏的AOF文件,修复：Redis-check-aof --fix进行修复。恢复：重启redis然后重新加载。
-
Rewrite是什么？
AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令gbrewriteaof。
重写原理：AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后在rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。 -
触发机制
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。 -
优势与缺点
优势：每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好不同步：appendfsync no 从不同步。
缺点： 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb。AOF运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。 -
AOF总结
AOF文件时一个只进行追加的日志文件
Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写
AOF文件有序地保存了对数据执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析也很轻松。
缺点：
对相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。
根据所使用的fsync策略，AOF的速度可能会慢于RDB。
RDB和AOF可以共存，但是恢复的时候找的是AOF，如果AOF文件异常，可以通过check-aof进行AOF修复。
1.3 Redis事务
Redis事务：可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞。一个队列中，一次性、顺序性、排他性地执行一系列命令。通过MULTI命令进入Redis事务。通过EXEC执行。
1.3.1 三阶段
- 开启：以MULTI开始一个事务
- 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面。
- 执行：由EXEC命令触发事务
1.3.2 三特性
- 单独的隔离操作：事务中的所有命令都会被序列化、按顺序地执行。事务在执行的构成中，不会被其他客户端发送来的命令请求所打断。
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
- 不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。
1.4 Redis发布订阅
进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接受消息。
- PSUBSCRIBE pattem [pattem......]：订阅一个或多个符合给定模式的频道
- PUBSUB subcommand [argument [argument.....]]：查看订阅与发布系统状态。
- PUBLISH channel message：将信息发送到指定的频道。
- PUNSUBSCRIBE [pattem [pattem....]]：退订所有给定模式的频道。
- SUBSCRIBE channel [channel...]：订阅给定的一个或多个频道的信息。
- UNSUBSCRIBE [channel [channel...]]：指退订给定的频道。
1.5 Redis主从复制
老套路了：主从复制，读写分离。
就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slver机制，Master以写为主，Slave以读为主。
1.5.1 使用
- 配从（库）不配主（库）
- 从库配置：slaveof主库IP主库端口：1。每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件2.Info replication查看当前服务器信息
1.5.2 主从复制相关细节知识点
- 一主二仆：如果主机挂了，其余从机将会原地待命。
- 薪火相传：如果从机数量太多，将会面临一个问题“如何去中心化”？
上一个Slave可以是下一个slave的Master，slave同样可以接受其他slaves的连接和同步请求，那么该slave作为链条中下一个的master，可以有效减轻master的写压力。中途变更转向：会清楚之前的数据，重新建立拷贝最新的。
命令：slaveof 新主库IP 新主库端口。 - 反客为主：SLAVEOF no one：使当前数据库通知与其他数据库的同步，转成主数据库。
1.5.3 复制原理
Slave启动成功连接到master后会发送一个sync命令Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步。
- 全量控制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
- 增量控制：master继续将新的所有收集到的修改命令一次传给slave，完成同步
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。
1.5.4 哨兵模式（setinel）
反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。也就是说当主机宕机后，从机不会傻傻的原地待命，哨兵将会从子机中投票选举出新的master.
- 如何配置哨兵？
在Redis.conf文件中配置哨兵：sentinel monitor被监控数据库名字（自己起名字）127.0.0.1 6379 1。（注意：上面最后一个数字1，表示主机挂掉后slave投票看让谁解题成为主机，得票数多的成为主机。 - 如何启动哨兵？
只需要重新从修改后的配置文件启动Redis服务即可。 - 问题：如果之前的master重启回来，会不会双master冲突？
不会冲突，之前的master回来之后，哨兵监测到，之前的master会编程slave。一定注意之前宕机的那台Master回来后会变成slave. - 复制延时
由于所有的写操作都是先在Master上操作，然后同步更新到slave上，所以从master同步到slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave机器数量的增加也会使这个问题更加严重。
终于完了！撒花！
