Redis核心知识（二）

AOF（Append Only File）

以日志的形式来记录所有的写操作，保存的是appendonly.aof文件，该机制默认关闭，配置文件`appendonly = yes`的形式来激活。

aof持久化策略配置

#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。
#always表示每次写入都执行fsync，以保证数据同步到磁盘。
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。
appendfsync everysec

触发aof重写机制的配置

# aof自动重写配置。当目前aof文件大小超过上一次重写
#的aof文件大小的百分之多少进行重写，即当aof文件增长
#到一定大小的时候Redis能够调用bgrewriteaof对日志文
#件进行重写。当前AOF文件大小是上次日志重写得到AOF文件
#大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
# 设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

如何恢复

正常恢复

将文件放到dir指定的文件夹下，当redis启动的时候会自动加载数据，注意：aof文件的优先级比dump大。

异常恢复

有些操作可以直接到appendonly.aof文件里去修改。

eg：使用了flushall这个命令，此刻持久化文件中就会有这么一条命令记录，把它删掉就可以了
写坏的文件可以通过 redis-check-aof --fix进行修复

优势

根据不同的策略，可以实现每秒，每一次修改操作的同步持久化，就算在最恶劣的情况下只会丢失不会超过两秒数据。
当文件太大时，会触发重写机制，确保文件不会太大。
文件可以简单的读懂

劣势

aof文件的大小太大，就算有重写机制，但重写所造成的阻塞问题是不可避免的
aof文件恢复速度慢

事务

常用命令

命令	描述
multi	标记一个事务的开始
exec	执行所有事务块内的命令
discard	取消事务，放弃执行事务块内的所有命令
watch key [key]	监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
unwatch	取消watch命令对所有 key 的监视。

正常执行
mutil开启事务exec提交事务
放弃事务
mutil开启事务，discard取消事务
全体连坐
mutil开启事务，中间出现代码块错误，exec执行事务命令会全部失败
冤头债主
mutil开启事务，若中间出现逻辑错误，类似于Java中的RuntimeException

watch监控

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，

乐观锁策略:提交版本必须大于记录当前版本才能执行更新

无加塞篡改，先监控再开启multi，保证两笔金额变动在同一个事务内
有加塞篡改，在监控过程中，数据在开启事务之前发生了篡改，最终事务会执行失败，可以在开启事务之前通过unwatch来关闭监控，使事务执行成功

扫描二维码关注公众号，回复： 11370288 查看本文章

总结

一旦执行了exec之前加的监控锁都会被取消掉了
Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行
通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败

整体流程

开启：以MULTI开始一个事务
入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
执行：由EXEC命令触发事务

特性

单独的隔离操作：事务中的所有命令都会序列化，按顺序的执行。事务在等待执行的时候，不会被其他客户端发送来的米命令请求打断
没有隔离级别的概念：队列中的所有命令没有提交exec之前都是不会被执行的
不保证原子性：redis中如果一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis的复制(Master/Slave)

也就是我们所说的`主从复制`，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，`Master以写为主，Slave以读为主`

能干嘛

读写分离
容灾恢复

操作

配从(库)不配主(库)

从库配置

#配置从库
slaveof 主库ip 主库端口
#slaveof 127.0.0.1 6379
#查看主从信息
info replication

常用的主从方式

一主二仆

含义：就是一个Master两个Slave
在这里插入图片描述

1. 第一次slave1 和slave2切入点，是全量复制，之后是增量复制
2. 主机可以写，但是从机不可以写，从机只能读
3. 主机shutdowm后从机待机状态，等主机回来后，主机新增记录从机可以顺利复制
4. 从机shutdowm后，每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
5. 从机复制到的数据，会被本机持久化。就算shutdown断开连接依然会有数据。
6. 重新连接或者变更master，会清除之前的数据，重新建立拷贝最新的数据

薪火相传

含义:就是上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力。在这里插入图片描述
注意，第一个Slave依旧是Slave，不会因为相对关系而变成Master

反客为主

SLAVEOF no one

使当前数据库停止与其他数据库的同步，转成主数据库（需要手动更改其对应关系）
在这里插入图片描述

哨兵模式（sentinel）

反客为主的自动版，能够后台监控Master库是否故障，如果故障了根据投票数自动将slave库转换为主库。一组sentinel能同时监控多个Master。

使用步骤：

在Master对应redis.conf同目录下新建sentinel.conf文件，名字绝对不能错；

配置哨兵，在sentinel.conf文件中填入内容(可以配置多个)：

#说明：最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机。
sentinel monitor 被监控数据库名字（自己起名字） ip port 1

启动哨兵模式(路径按照自己的需求进行配置)：
```
redis-sentinel  /myredis/sentinel.conf
```

注意：

当master挂掉后，会通过选票进行选出下一个master。而且只有使用了sentinel.conf启动的才能开启选票
当原来的master后来后，很不幸变成了slave。

复制原理

Slave启动成功连接到master后会发送一个sync命令；
Master接到命令启动后的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件到slave，以完成一次完全同步；
全量复制：而slave服务在数据库文件数据后，将其存盘并加载到内存中；
增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步；
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。

复制的缺点

延时，由于所有的写操作都是在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使得这个问题更加严重。

命令

命令	作用
slaveof 主库ip 主库端口	配置从库
info replication	查看redis主从复制的情况
slaveof no one	使当前数据库停止与其他数据库的同步，转成主数据库
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1	配置哨兵，监视master
redis-sentinel /myredis/sentinel.conf	以哨兵模式启动redis