Redis(三) Redis的常用配置、持久化机制、事务、消息的发布订阅、主从复制机制

---

Redis学习(三)
Redis的常用配置、持久化机制、事务、消息的发布订阅、主从复制

Redis的配置

• [136] daemonize: 是否后台运行

• [92] port: 设置Redis的监听端口

• [113] timeout: 设置连接超时(如果超过指定时间,则暂时关闭连接)
  

• [130] tcp-keepalive: 设置心跳机制的检测间隔
  

• [166] loglevel: 设置日志级别(类似log4j)
  

• [494] SECURITY: 系统安全(默认不启用)

• [539] maxclients: 设置最大连接数

• [566] maxmemory: 设置最大的缓存

• [196] SNAPSHOTTING: 快照设置(持久化)

  [218] save: 设置持久化规则

• [679] APPEND ONLY MODE 配置aof

  [699] appendonly 设置是否启用aof

  [703] appendfilename “<文件名>” 设置aof的日志名

• [770] 设置aof重写的阈值
  

Redis的持久化

RDB(Redis Database)

存储方式 指定时间间隔将内存中的数据采集快照写入磁盘,恢复时直接将快照读入内存中

特点

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

• 手动备份

>save

• 动态停止所有RDB保存规则的

>Redis-cli config set save “”

• 手动修复dump文件(需要在/usr/local/bin/目录中)

>Redis-check-aof --fixdump.rdb

​

产生快照的途径

1. save

2. bgsave

3. flush[all]

AOF(Append Only File)

注意

如果配置文件中开启了RDB和AOF两种备份机制,优先 使用AOF

存储方式 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)

特点

1. 只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，即重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

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

3. Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发,或者使用命令手动触发

   >bgrewriteaof
   

• 手动修复AOF文件(需要在/usr/local/bin/目录中)

>Redis-check-aof --fix appendonly.aof

---

Redis的事务

注意 Redis支持事务,但是不保证原子性

• MULTI

标记一个事务块的开始

• EXEC

执行所有事务块内的命令

• DISCARD

取消事务,放弃执行事务块内的所有命令

• UNWATCH

取消WATCH命令对所有key的监视

• WATCH key [key]

监视-个(或多个)key , 如果在事务执行之前这个(或这些) key被其他命令所改动,那么事务将被打断。

事务的创建

• 正常执行事务

>MULTI	#开启事务
>[操作1]
>[操作2]
...
>[操作n]
>EXEC	#执行事务

• 取消事务队列

>MULTI	#开启事务
>[操作1]
>[操作2]
...
>[操作n]
>DSICARD	#取消事务队列,则操作1~n全都不执行

注意

1. 如果添加事务队列,出现一个错误,那么整个事务队列也都不执行

2.如果添加事务队列成功,但是在执行时出现错误,那么只回滚出现错误的这一条指令,其他执行正常执行

watch监控

开启watch监控

> WATCH <key>  #监听指定的键
> MULTI	#开启事务
>[操作1]
>[操作2]
....
>[操作n]
>EXEC

• 取消所有key的watch监控

>UNWATCH

Redis的发布订阅(一般不用)

订阅消息

语法

>SUBSCRIBE <消息1> <消息2> ... <消息n>

• 可以使用通配符一次性订阅多个消息

举例 订阅所有以 “new” 开头的消息

>SUBSCRIBE new*

发布消息

语法

>PUBLISH <消息名> <内容>

---

Redis的复制机制

简单的主从复制

作用 读写分离,容灾恢复

• 配置规则

1. 配从不配主

2. 从库配置:slaveof 主节点IP 主节点端口

   每次与master断开连接之后,都需要重新连接,除非将主节点配置进Redis.conf文件

3. 修改配置文件细节操作

• 查看主从配置的信息

>info replication

• 主从复制的特点

1. 如果设置了主从复制,从节点会把主节点所有的信息备份
2. 如果配置了主从节点,只有主节点可以写操作,从节点只能读操作
3. 上一个Slave可以是下一个slave的Master，Slave同样 可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力

• 复制的原理

1. Slave启动成功连接到master后会发送-一个sync命令
2. Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步

• 复制的类型

  • 全量复制

  slave服务在接收到数据库文件数据后，将其存盘并加载到内存中

  • 增量复制

  Master继续将新的所有收集到的修改命令依次传给slave,完成同步但是只要是重新连接master,-次完全同步(全量复制)将被自动执行

哨兵机制

• 使用哨兵的步骤

1. 在自定义目录下面新建sentinel.conf文件(名字绝对不能错)
2. 在sentinel.conf配置文件里填写

sentinel monitor <被监控的主机名> <本机IP> <端口号> <票数>

说明

被监控的主机名: 这个自己起名字

本机IP : 本机的IP地址
端口号: 哨兵使用的端口号
票数: 表示主机宕机之后,slave投票看让谁接替成为主机,得票数多少后成为主机

3. 启动哨兵

[alasky@localhost redis]$ Redis-sentinel <sentinel.conf的路径>

注意

在自定义目录下面新建sentinel.conf文件(名字绝对不能错)
2. 在sentinel.conf配置文件里填写

sentinel monitor <被监控的主机名> <本机IP> <端口号> <票数>

说明

被监控的主机名: 这个自己起名字

本机IP : 本机的IP地址
端口号: 哨兵使用的端口号
票数: 表示主机宕机之后,slave投票看让谁接替成为主机,得票数多少后成为主机

3. 启动哨兵

[alasky@localhost redis]$ Redis-sentinel <sentinel.conf的路径>

注意

当主节点宕机之后,哨兵会自动从几个从节点中选出合适的来顶替主节点,如果之前的主节点恢复启动,那么会作为一个新的从节点加入集群