Redis一：持久化（RDB+AOF）+发布订阅+主从复制

Redis一：持久化（RDB+AOF）+发布订阅+主从复制

对于配置文件的了解

daemonize no #以守护线程的方式进行运行，默认no，自己手动开启
pidfile /var/run/redis_6379.pid #在后台运行，我们要有一个pid文件
loglevel notice 
logfile ""  #日志位置
databases 16 #数据库的数量默认 0-15，默认16个
always-show-logo yes #是否总是显示logo

快照

持久化，在规定的时间内有多少次操作，会持久化到 .rdb .aof文件

redis是内存数据库，若无持久化，断电即失

\# 900s内 至少有一个key进行了修改，我们就会及时持久化
save 900 1
\# 300s内 至少有10个key进行了修改，我们就会及时持久化
save 300 10
\# 60s内 至少有10个key进行了修改，我们就会及时持久化
save 60 10

stop-writes-on-bgsave-error yes#持久化出错后仍继续工作
rdbcompression yes#是否压缩rdb文件，需要消耗一些cpu资源
rdbchecksum yes#保存rdb文件时，进行错误的校验


dir ./   #文件保存的目录

安全Security

\#requirepass 123456   设置密码

客户端

maxclients 10000   #设置连接redis的客户端的最大数量
maxmemory    #redis配置的最大内存容量

maxmemory-policy noeviction #内存到达上限之后的处理策略
六种方式
1、volatile-lru：只对设置了过期时间的key进行LRU（默认值） 
2、allkeys-lru ： 删除lru算法的key   
3、volatile-random：随机删除即将过期key   
4、allkeys-random：随机删除   
5、volatile-ttl ： 删除即将过期的   
6、noeviction ： 永不过期，返回错误

Append only 模式 aof配置

appendonly no #默认不开启aof模式，默认rdb方式持久化的，在大部分情况下，rbd完全够用
appendfilename "appendonly.aof" #持久化的文件名字


# appendfsync always  #每次修改都会同步，都会sync，消耗性能
appendfsync everysec  #每秒同步一次，可能会丢失这1s的数据
# appendfsync no      #不执行sync，这个时候操作系统自己同步数据，速度最快

持久化

RDB

RDB 实际上是 Redis 内部的一个定时器事件，它每隔一段固定时间就去检查当前数据发生改变的次数和改变的时间频率，看它们是否满足配置文件中规定的持久化触发条件。当满足条件时，Redis 就会通过操作系统调用 fork() 来创建一个子进程，该子进程与父进程享有相同的地址空间。

Redis 通过子进程遍历整个内存空间来获取存储的数据，从而完成数据持久化操作。注意，此时的主进程则仍然可以对外提供服务，父子进程之间通过操作系统的 COW（****Copy-on-Write****写时复制） 机制实现了数据段分离，从而保证了父子进程之间互不影响。

基本流程bgsave

1.fork主进程得到一个子进程，子进程和父进程共享内存空间

2.子进程读取内存数据写入心rdb文件

3.新rdb文件替换旧rdb

手动触发

手动触发是通过SAVAE命令或者BGSAVE命令将内存数据保存到磁盘文件中。如下所示：

127.0.0.1:6379> SAVE
OK
127.0.0.1:6379> BGSAVE
Background saving started
127.0.0.1:6379>  LASTSAVE
(integer) 1611298430
注意：LASTSAVE 命令用于查看 BGSAVE 命令是否执行成功。

上述命令BGSAVE从后台执行数据保存操作，其可用性要优于执行 SAVE 命令。

save命令执行过程

SAVE 命令会阻塞 Redis 服务器进程，直到 dump.rdb 文件创建完毕为止，在这个过程中，服务器不能处理任何的命令请求。

BGSAVE命令是非阻塞式的，所谓非阻塞式，指的是在该命令执行的过程中，并不影响 Redis 服务器处理客户端的其他请求。这是因为 Redis 服务器会 fork() 一个子进程来进行持久化操作（比如创建新的 dunp.rdb 文件），而父进程则继续处理客户端请求。当子进程处理完后会向父进程发送一个信号，通知它已经处理完毕。此时，父进程会用新的 dump.rdb 文件覆盖掉原来的旧文件。

因为SAVE命令无需创建子进程，所以执行速度要略快于BGSAVE命令，但是SAVE命令是阻塞式的，因此其可用性欠佳，如果在数据量较少的情况下，基本上体会不到两个命令的差别，不过仍然建议使用 BGSAVE命令。

简化版本

自动触发

自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中（三条save）

1.save的规则满足后，会自动触发rdb文件

2.执行flushall，也会触发

3.退出redis，也会产生rdb文件

如何恢复rdb文件

1.将rdb文件放入redis启动目录中，redis启动时会自动恢复rdb文件中的数据

2.查看需要存在的位置config get dir

优劣

优点：

1.适合大规模数据恢复 通过dump.rdb文件

2.对数据完整性要求不高

缺点：

1.需要一定的时间间隔进程操作 ，如果redis意外当即，最后一次修改的数据就没了

2.fork进程时，会占用内存空间

AOF

每当有一个修改数据库的命令被执行时，服务器就将命令写入到 appendonly.aof 文件中，该文件存储了服务器执行过的所有修改命令，因此，只要服务器重新执行一次 .aof 文件，就可以实现还原数据的目的，这个过程被形象地称之为“命令重演”

重写机制(no-appendfsync-on-rewrite)

1.AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof，aof默认是文件无限追加，因为写操作是源源不断的，文件会越来越大，通过执行bgrewriteaof命令，使aof执行重写功能，用最少的命令达到相同的效果

如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，降低数据安全性，提高性能

如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里写，数据安全，但是性能降低

appendonly no #默认不开启aof模式，默认rdb方式持久化的，在大部分情况下，rbd完全够用
appendfilename "appendonly.aof" #持久化的文件名字

redis-check-aof --fix#如果aof被恶意篡改导致redis启动失败，redis为我们提供了一个修复aof的工具



#重写规则
auto-aof-rewrite-percentage 100 # 达到上次压缩文件的二倍 ，100意思比上次文件增长超过了百分之百
auto-aof-rewrite-min-size 64mb  #aof到达 64mb 触发重写机制

aof策略配置

# appendfsync always  #每次修改都会同步，都会sync，消耗性能，但数据完整性更好

appendfsync everysec  #每秒同步一次，可能会丢失这1s的数据   默认
#写命令执行完先放入aof缓冲区，然后每隔一秒将缓冲区数据写入aof文件，默认方案

#appendfsync no      #不执行sync，这个时候操作系统自己同步数据，速度最快
#写命令执行完先放入aof缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

优点：

1.每一次修改都同步，文件完整性更好 appendfsync always

2.每秒同步一次，可能会丢失这一秒的数据 appendfsync everysec

3.从不同步，效率最高 appendfsync no

缺点：

1.相对于数据文件来说，aof文件比rdb文件更庞大，修复数据时，aof速度较慢

2.运行效率低于rdb，所以默认持久化模式是rdb

rdb和aof区别

	RDB持久化	AOF持久化
	全量备份，一次保存整个数据库。	增量备份，一次只保存一个修改数据库的命令。
	每次执行持久化操作的间隔时间较长。	保存的间隔默认为一秒钟（Everysec）
	定时对整个内存做快照	记录每一次执行的命令
	数据保存为二进制格式，其还原速度快。	使用文本格式还原数据，所以数据还原速度一般。
	执行 SAVE 命令时会阻塞服务器，但手动或者自动触发的 BGSAVE 不会阻塞服务器	AOF持久化无论何时都不会阻塞服务器。

发布订阅

Redis PubSub 模块又称发布订阅者模式，是一种消息传递系统，实现了消息多播功能

redis发布订阅是一种消息通信模式：发送者发送消息，订阅者接收消息，redis客户端可以订阅任意数量的频道

PUBLISH CHANNEL message 发布消息
SUBSCRIBE CHANNEL  订阅频道
UNSUBSCRIBE CHANNEL 取消订阅频道

右侧发布者，左侧订阅者，发布者发送消息后，订阅者会接收到

基本原理：

通过SUBSCRIBE订阅某频道后，redis-server里维护一个字典，字典的键就是频道的名称，字典的值是一个链表，链表中存储每一个订阅这个频道的客户端，SUBSCRIBE命令的关键就是把每一个订阅者客户端添加到该频道对应的链表中

通过PUBLISH命令发布消息，redis-server以该频道作为建，在他所维护的channel字典中查找键对应的值，值就是又存储订阅者客户端的链表，遍历这个链表获取每一个订阅者客户端，然后发送信息给订阅者

主从复制

replicaof  手动配置文件设置从机

slaveof hast port（主机端口） 命令行设置从机

info replication 查看当前主机从机状态

主机能读能写，从机只能读不能写，主从复制，读写分离

经过实际操作，主机服务关闭后，从机依旧链接到主机，但是没有写操作，如果主机服务重新启动并写入新数据，从机依旧可以直接获取主机写的信息数据信息

如果使用命令行而不是配置文件来设置主从古砚曦，如果从机服务关闭，再重新启动后，从机此时不再是从机，但如果再次变为主机的从机，就可以获取主机的值

复制原理

slave启动成功连接到master后会发送一个sync同步命令

master接收到命令后，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕后，master将传送整个文件到slave，完成一次完全同步（全量复制）

全量复制：而slave服务在接收到数据库文件数据后，将其存盘加载到内存

增量复制：master继续将新的收集到的修改命令依次传给slave，完成同步

从机断开后，在重新成为从机连接到master，一次完全同步（全量复制）将被自动执行

主从从

81是80的从节点，82是81的从节点，但82不是80的从节点，80此时只有81一个从节，一句话，我附庸的附庸不是我的附庸，

如果80 shutdown宕机了，81执行命令 slaveof no one 成为主机，谋朝篡位，在哨兵模式之前采取这种手动形式。