2.AOF (Append only file->每一个动作)
什么是AOF？
将我们执行的所有命令都记录下来，类似于history，恢复的时候就把这个文件全部再执行一遍！
工作原理：
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件而不可以改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。Aof保存的是 appendonly.aof 文件。
如何使用？
如果要使用AOF,需要修改配置文件：
- AOF默认不开启，我们需要手动进行配置！我们只需要将 appendonly 改为yes就开启了 aof！
- 重启，redis 就可以生效
- 如果这个 aof 文件有错误，那么这时候的 redis 是启动不起来的，我们需要修复这个aof文件
- redis 给我们提供了一个工具redis-check-aof，通过执行 redis-check-aof --fix appendonly.aof 命令就可以将aof文件恢复正常。
配置文件说明：
aof 默认就是文件的无限追加，这样导致的结果就是文件会越来越大。
优点：
- 每一次修改都同步。
- 每秒同步一次，最多可能会丢失一秒的数据。
缺点：
- 相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢！
- aof运行效率也要比 rdb 慢，所以redis默认的配置就是rdb持久化！
扩展：
- rdb持久化能够在指定的时间间隔内对数据进行快照存储。
- aof持久化记录每次对服务器的写操作，每当服务器重启时都会执行这些命令以此来恢复数据
- aof方式追加每次写操作到文件的末尾，同时在redis配置文件中还设置了对aof文件进行后台重写，使得aof文件不至于过大。
- 同时开启两种持久化方式
- 这种情况下redis在重启时会先载入aof文件来恢复原始数据（因为aof文件保存的数据比rdb文件保存的数据更完整）
- 建议不要只开启aof持久化，因为rdb更适合用于数据库的备份，同时可以快速重启
- 性能建议
- 建议只开启rdb文件，而且只要15分钟备份一次就可以，只保留 save 900 1
- 如果使用aof，带来的好处是即使在最恶劣的情况下也不会丢失超过2秒的数据，在重启时只加载自己的aof文件即可。坏处是带来了持续的IO，二是aof重写过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的，只要硬盘许可，应该尽量减少aof重写的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
- 如果不使用aof，仅用rdb实现高可用性也可以，这样可以省掉一大笔 IO，也减少了重写时带来的系统波动。代价是如果Master/Slave宕机，这样就会丢失十几分钟的数据。
3、如何选择 RDB和AOF
- 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。
- 如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
- 有很多用户都只使用 AOF 持久化， 但并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快。
(十二)、Redis订阅
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
第一个: 消息发布者。第二个频道。第三个:消息订阅者
当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：
1.命令
- 订阅-个或多个给定模式的频道: PSUBSCRIBE 【预定节目】
- 退阅-个或多个给定模式的频道: PunsubScribe 【表演节目】
- 查看订阅/发布系统状态:PUBSUB
- 向指定频道发布消息: PUBLISH 【发送者】
- 订阅一个或多个频道: SUBSCRIBE
- 退订一个或多个频道: UNSUBSCRIBE 【退订】
我们先开启订阅端，然后再开启推送端
订阅者 127.0.0.1:1245> SUBSCRIBE jsxs # 订阅的频道名字是: jsxs Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "jsxs" 3) (integer) 1 # 以上说: 我们订阅成功! 1) "message" 2) "jsxs" 3) "hello jsxs" #以上是: 说哪一个频道给我们发送了消息 1) "message" 2) "jsxs" 3) "hello redis" #以上是: 说哪一个频道给我们发送了消息 推送者: 127.0.0.1:17> PUBLISH jsxs "hello jsxs" #向jsxs这个频道推送一个消息 (integer) 1 127.0.0.1:17> PUBLISH jsxs "hello redis" (integer) 1 目前活跃的频道 127.0.0.1:17> PUBSUB CHANNELS 1) "jsxs"
2.原理
每个 Redis 服务器进程都维持着一个表示服务器状态的 redis.h/redisServer 结构， 结构的 pubsub_channels 属性是一个字典， 这个字典就用于保存订阅频道的信息，其中，字典的键为正在被订阅的频道， 而字典的值则是一个链表， 链表中保存了所有订阅这个频道的客户端。
客户端订阅，就被链接到对应频道的链表的尾部，退订则就是将客户端节点从链表中移除。
3.缺点
- 如果一个客户端订阅了频道，但自己读取消息的速度却不够快的话，那么不断积压的消息会使redis输出缓冲区的体积变得越来越大，这可能使得redis本身的速度变慢，甚至直接崩溃。
- 这和数据传输可靠性有关，如果在订阅方断线，那么他将会丢失所有在短线期间发布者发布的消息。
4.应用
- 消息订阅：公众号订阅，微博关注等等（起始更多是使用消息队列来进行实现）
- 多人在线聊天室。
(十三)、Redis主从复制💥
1.概念
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（Master/Leader）,后者称为从节点（Slave/Follower）， 数据的复制是单向的！只能由主节点复制到从节点（主节点以写为主、从节点以读为主）。
默认情况下，每台Redis服务器都是主节点，一个主节点可以有0个或者多个从节点，但每个从节点只能有一个主节点。
作用
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余的方式。
- 故障恢复：当主节点故障时，从节点可以暂时替代主节点提供服务，是一种服务冗余的方式
-负载均衡：在主从复制的基础上，配合读写分离，由主节点进行写操作，从节点进行读操作，分担服务器的负载；尤其是在多读少写的场景下，通过多个从节点分担负载，提高并发量。 - 高可用基石：主从复制还是哨兵和集群能够实施的基础。
2.搭建环境
只配置从节点的库，不配置主节点的库。
查看当前库的信息：
127.0.0.1:1217> info replication # Replication role:master # 默认是主分支 connected_slaves:0 master_failover_state:no-failover master_replid:638a5e8b3d24d6f67fe30fe351452573b1470827 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0
既然需要启动多个服务，就需要多个配置文件。每个配置文件对应修改以下信息：
- 端口号 【port】
- pid文件名 【pid】
- 日志文件名 【logfile】
- rdb文件名 【dump.rdb】
`复制三个配置文件` [root@Jsxs jconfig]# cp redis.conf redis79.conf [root@Jsxs jconfig]# cp redis.conf redis80.conf [root@Jsxs jconfig]# cp redis.conf redis81.conf [root@Jsxs jconfig]# ls redis79.conf redis80.conf redis81.conf redis.conf
启动单机多服务集群：
一主二从配置
默认情况下，每台Redis服务器都是主节点; 我们一般情况下只用配置从机就好了！
认老大！一主（79）二从（80，81）
SLAVEOF xxx.xxx.xxx.xxx(主机号) 6379(端口号)
假如主机设置的有密码,那么在从机中添加配置.并且从机不能设置Requiress
masterauth zn20011007(参数根据自己主机密码来）
注意在linux的个人ip(8.xxxx),在本地控制台就是127.0.0.1。
# Replication role:master # 当前的角色是主机 connected_slaves:2 #发现有两个从机 slave0:ip=127.0.0.1,port=6380,state=online,offset=280,lag=1 slave1:ip=127.0.0.1,port=6381,state=online,offset=280,lag=0 master_failover_state:no-failover master_replid:9ac622bf6137444efe7c2d93b3b70d8eb4e0df09 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:280 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:280
然后主机上也能看到从机的状态：
SLAVEOF NO ONE
我们这里是使用命令搭建，是暂时的，真实开发中应该在从机的配置文件中进行配置，这样的话是永久的。
3.使用规则
- 从机只能读，不能写，主机可读可写但是多用于写。
- 当主机断电宕机后，默认情况下从机的角色不会发生变化 ，集群中只是失去了写操作，当主机恢复以后，又会连接上从机恢复原状。
- 当从机断电宕机后，若不是使用配置文件配置的从机，再次启动后作为主机。是无法获取之前主机的数据的。若此时重新配置成从机，又可以获取到主机的所有数据。这里就要提到一个同步原理(从机会复制其他从机数据）
4.复制原理
Slave 启动成功连接到master后会送一个sync命令。
Master 接收到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,并完成一次同步。
全量复制: 而Slave服务在接收到数据库文件数据后，将其存盘加载到内存中。
增量复制: Master继续将所有收集到的修改命令依次传给slave,完成同步。
但是只要重新连接master,一次完全同步(全量复制)将自动执行。
5.宕机后手动配置主机
层层链路
第三个节点隶属于第二个节点，第二个节点隶属于第一个节点。第二个节点依旧是从节点。
- 第二条中提到，默认情况下，主机故障后，不会出现新的主机，有两种方式可以产生新的主机：从机手动执行命令slaveof no one,这样执行以后从机会独立出来成为一个主机。假如使用哨兵模式（自动选举） 我们就不用手动改了。
slaveof no one
如果主机断开了连接，我们可以使用SLAVEOF no one让自己变成主机！其他的节点就可以手动连接到最新的主节点（手动）！如果这个时候老大修复了，那么就只能手动重新设置隶属关系！(如果配置到配置文件，那么宕机我们就要去修改配置文件)
