1、发布订阅模式
例子：比如说你们家有个收音机 你收听了 xxxxx 频道 那么只要你打开这个频道 你就能收听到这个频道的所有的内容
你的收音机-----------接收方(订阅方)
频道的内容发送方-------内容的发布者
subscribe 订阅的频道的名称
publish 频道名字 内容
场景：这个功能实际上就是咋们的 MQ中的功能
2、Redis中事务问题
事务应该是具有原子性，一串的操作要么同时成功、要么同时失败
multi 开启事务
.....
.....
exec 提交事务
3、rdb模式实现持久化
Redis是基于内存的、所以速度快、但是Redis的数据放到内存里面、当Redis重启的时候 这个数据会发生丢失
假设我们能把写入到内存的数据、持久化到硬盘 那是不是就能保证我们的数据即使发生丢失 也不会全部丢失、或者全部不丢失呢?
Redis的持久化就产生了----默认情况下 Redis本身也是有持久化策略的
我们即使不配置 那么这个Redis的持久化依然存在的
rdb是数据库默认的持久化模式-----又称为快照模式
这个模式是将内存的数据内容 直接保存到 dump.rdb这样的一个二进制文件中的
特点：因为保存的是二进制文件、所以做数据的恢复是相当的快的—适合于做数据的备份
rdb到底是如何保存我们的数据库的：rdb每一次在保存这个数据的时候、首先都会清空原有的dump.rdb文件、然后将整个内存的数据全部写入到这个文件中 rbd-------保存的是redis内存中某一个时刻的数据(适合备份、不适合开发用)
rdb模式的问题：
假设刚好清空dump.rdb这个文件、现在断电了------------数据全丢了
什么时候 rdb模式会触发内存的数据和硬盘进行同步呢?
save 900 1 在900秒的时间内如果有1和key发生改变 那么将触发内存和硬盘同步
save 300 10 在300秒的事件内如果有10个key发生改变 那么将会触发内存和硬盘同步
save 60 10000 在60秒的时间类假设有10000个key发生改变那么也变触发内存和硬盘同步
rdb模式是不用开启的、这个模式的redis自动开启的
4、aof实现持久化
aof模式是在redis1.1的版本的时候、才增加的一种持久化模式
aof模式在使用的时候 保存的不是数据 是我们操作的时候的一条一条的命令
只要调用了Redis 那么只要有命令的使用那么都会被记录到aof文件中
aof---------------记录的是操作的命令 不记录实际的数据
aof模式如果是在数据恢复还原的时候 效率并不高 数据恢复的话采用rdb文件恢复是最快的
aof模式如何使用
appendonly yes ：表示的是开启 aof 的模式
*3 *代表的是命令的开始 3 ：这个表示的是命令中一共有3块内容
$3 $使用修饰命令中的每一个参数的 3代表的是下面的这个命令一共有3个字符
set
$5
email
$5
xxxxx
rdb 存在 aof 现在也存在 ? 会以谁优先呢？
这里如果是开启了aof模式 那么会以aof模式为优先
aof模式是否有触发策略?
appendfsync always ：只要有键发生改变 立马同步(每一次都触发IO操作、速度就慢下来、这种情况是不会丢数据)-----一般不用（效率太低了）
appendfsync everysec ：每一秒钟进行数据同步一次(开发的时候一般选用他----速度上也比较快 即使出现数据的丢失也只会丢失1秒钟的数据)
appendfsync no ：永远不同步、数据只是放到缓存里面 速度快 但是数据容易丢失
aof模式是如何同步数据的呢?
每一次在进行数据同步的时候 使用的是 追加的模式 以前的数据不用删除 只需要追加新的操作即可
aof模式消息的重写
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100 (这个表示的是必须达到100%的增加才重写 64M+64M=128M )
auto-aof-rewrite-min-size 64mb aof文件（简单的说就是至少aof文件达到64M才重写）
手动重写
bgrewriteaof ：这个命令就是手动重写
重写的好处是对aof文件进行优化(最终的结果都是一样的)
如果你要去手动重写(需要关闭混合持久化的开关才能看到功能)
aof-use-rdb-preamble no
5、混合持久化的问题
我们在开发的时候到底是选择 rdb 还是aof呢?
如果你关心的是你的数据、但是任然可以接受在一段时间内依然可以接受一些数据的丢失 那么你可以使用rdb(速度快)
我们以前开发的时候基本上都使用aof模式来做开发、如果你用的版本是4.0以前的版本那么建议你呢还是使用aof
在4.0以后 就出现了一种新的持久化模式(混合持久化)
这个混合持久化 就集成了 rdb的有点和aof所有的有点
画图：理解混合持久化
6、缓存的淘汰策略
什么是缓存淘汰策略、简单的说就是咋们的redis中的内存已经满了、现在要保证内存中的Redis的数据 一定是最新的、那么这个时候就需要配置缓存的淘汰策略了
noeviction：只要缓存满了、那么就不继续服务器里面的写的请求、读的请求是可以完成的、这种模式缓存里面的所有数据 都不会丢失、这种情况会导致参与Redis的业务会失败
volatile-lru：他会优先淘汰掉 设置了过期时间的这个key、然后第二步才淘汰掉使用的比较少的key 假设我们的key没有设置过期时间的话 那么不会优先淘汰
这种模式也是咋们在开发中使用的比较多的一种缓存策略模式
allkeys-lfu：和lru是有区别的、这个在淘汰的时候、淘汰的是全体key的集合、不是过期的key的集合(过期这一说法没有)、这就意味着你没有设置过期时间的key 只要使用的比较少那么依然会被淘汰
volatile-ttl：这个淘汰策略不是LRU 、而是key剩余的寿命的ttl值 ttl值越小 越先被淘汰
allkeys-random：使用这个淘汰策略的时候 淘汰的是随机的key
maxmemory-policy volatile-lru 这个就是配置缓存的淘汰策略的
maxmemory <bytes> ：这个是配置Redis的缓存的大小
7、主从复制问题
一台服务器主服务器(39.99.200.54)
另外两台作为从服务器
106.54.13.167 47.96.119.26
实操
主服务器更改
daemonize yes //后台启动
bind 0.0.0.0 //表示的是允许所有人访问
从服务器配置的更改
daemonize yes //后台启动
bind 0.0.0.0 //表示的是允许所有人访问
slaveof 主服务器的ip地址 主服务器端口
使用如下命名 检查主从是否配置好
./redis-cli
info
如果主服务器是如下的
8、哨兵模式
哨兵是安装在任意一台服务器上 、跟咋们的主服务器 并没有任何的关联
哨兵配置的节点：47.96.119.26
哨兵的配置
1、将Redis解压目录下的sentinal.xml文件复制到 /usr/local/zhucong/目录下
2、配置sentinal.xml文件
#配置的是配置文件的目录
dir /usr/local/zhucong/
#配置的是监听主服务器信息 最后一个参数很重要 一般设置为1 多少票通过
sentinel monitor mymaster 39.99.200.54 6379 1
#配置的是意思是心跳信号发给你了 多久没回应就认为主服务器死了...
sentinel down-after-milliseconds mymaster 5000
哨兵的启动命令
./redis-server /usr/local/zhucong/sentinel.conf --sentinel &