简介： redis事务、持久化、发布订阅、主从复制。
redis实战
（1）redis事务
-
redis不存在事务隔离级别
-
redis对单条命令保证原子性，对事务不保证
--队列 set set set 执行--
开启事务（multi）
命令入队（写命令）
事务执行（exec）
取消事务（discard）
1、事务开启时，所有的命令都会进入到队列中，并不会执行，只有当我们执行exec命令时，所有的命令才会执行。
2、当我们出现编译错误时，执行exec命令时，所有的命令都不会被执行。
3、出现 运行时异常 ，执行exec命令时，并不影响其他代码的操作。
1、redis锁机制
redis的锁实现是乐观锁。
redis的watch可以当作乐观锁使用。修改失败后，我们放弃监视（unwatch）的值，从新监视就行了。
springboot2.x之后，对redis的操作底层已经不是jedis了，而是 lettuce-core。
lettuce-core 采用的是netty，可以减少线程数据，更像NIO模式。
（2）redis持久化
redis是内存数据库，当进程结束或服务器关闭时，我们不去做数据的持久化的话，那么数据就会丢失在我们下次使用时，所以redis的持久化很重要。
1、RDB（redis database）
SNAPSHOTTING：快照
save 900 1 //自动保存策略,表示900秒内,至少1个key发生变化,保存
-
stop-writes-on-bgsave-error ： 默认值为yes。持久化失败了，还继续工作。
-
rdbcompression： 默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
-
rdbchecksum： 默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验。
-
dbfilename ： 设置快照的文件名，默认是 dump.rdb
-
dir： 设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。
持久化机制：
优点：
- 可以对大规模数据恢复。
- 利用fork子进程操作持久化，效率高。
缺点：
- 操作持久化有时间间隔，突然的宕机可以导致一些数据无法保存。
2、持久化AOF
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录) , 只可以追加文件但不可以改写文件, redis启动之初会读取该文件重新构建数据换言之 , redis重 启的话就根据日志文件的内容将写指令 从前到后执行一-次以完成数据的恢复工作。
# appendfsync always 同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
appendfsync everysec #默认选项，1秒异步执行一次
# appendfsync no Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上
正常情况下appendonly.aof文件生成在到redis的安装目录的bin目录下，重启redis服务时就可以读取该配置文件。因为某些原因导致appendonly.aof文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。
AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以 Redis 就有了重写机制， Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof 。
**触发机制：**Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
auto-aof-rewrite-percentage 100 （一倍）
auto-aof-rewrite-min-size 64mb
**优点：**数据的完整性很高。
**缺点：**当数据库内容很多时，数据恢复的速率会很慢
（3）redis的发布订阅
客户端命令订阅一个频道，就会接收服务端队列发来信息。非常简单。
（4）redis主从复制
1、主从复制，是指将一台Redis服务器的数据 ,复制到其他的Redis服务器。前者称为主节点(master/leader) ,后者称为从节点(slave/follower) ;数据的复制是单向的,只能由主节点到从节点。Master以写为主, Slave以读为主。
127.0.0.1:6379> info replication #查看redis的信息
# Replication
role:master #当前库的角色
connected_slaves:0 #连接从机的个数
master_replid:43d783d6c91ccee4bf9e97099f104f1d0740e92f
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
2、 默认每一台服务器都是主机（主节点），
slaveof ip port #找给地址的redis服务器当老大。
3、slaveof 127.0.0.1 6379，默认将该地址下的redis服务器当主机，此时运行该命令的服务器就会默认当作从机了。
role: slave #变成了从机
master host:127 .0.0.1 #主机的ip地址
master port:6379 #主机端口
master_ Link_ status:up #在线状态
master last io seconds ago :3
master sync_ in progress:0
slave_ repl_ offset:14
4、命令配置主从复制是暂时的，想要永久生效我们要通过配置文件配置。
5、 在主从复制中，从机只可以进行读操作
- 当主机宕机的话，从机依然连接这主机，但是不可以进行写操作了。
- 如果是使用命令行，来配置的主从,这个时候如果重启了，就会变回主机！只要变为从机,立马就会从主机中获取值！
Slave启动成功连接到master后会发送一个sync同步命令，Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave ,并完成一次完全同步。
**全量复制:**而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制: Master继续将新的所有收集到的修改命令依次传给slave ，完成同步。
6、 配置集群的方法我们可以：一主二从，层层链表
当主机挂了，我们可以使用 slaveof no one 命令，在第二个服务器中使用，将该服务器当作主机。
1、哨兵模式
主从切换技术的方法是： 当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预,费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel (哨兵)架构来解决这个问题。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。如果故障了根据投票数自动将从库转换为主库。
配置哨兵模式
sentinel.conf #哨兵默认的配置文件
-------------------------------------
# time while performing the synchronization with the master.
sentinel monitor mymaster 127.0.0.1 6379 2 #核心配置:sentinel monitor 名称（随意) IP 端口 票数
# sentinel failover-timeout <master-name> <milliseconds>
打开后会自动找出主机下面的从机
当主机挂了，就会随机从从机服务服务器中随机选择（投票算法）一个当作主机，如果主机此时回来了,只能归并到新的主机下，当做从机，这就是哨兵模式的规则!
