redis(三)

1、发布订阅模式

Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。
Redis 客户端可以订阅任意数量的频道。
如下展示了频道channel1和订阅了这个频道的三个客户端之间的关系

当有新的消息通过publish命令发送给频道channel1时，这个消息就会被发送到这三个客户端

2、redis中事务

re 1、发布订阅模式
Redis 发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。 Redis 客户端可以订阅任意数量的频道。 如下展示了频道channel1和订阅了这个频道的三个客户端之间的关系 当有新的消息通过publish命令发送给频道channel1时，这个消息就会被发送到这三个客户端

2、redis中事务

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
redis中事务并没有原子性，事务中任意命令执行失败，其他命令仍会被执行(没什么用)

redis事务的三个阶段：

开始事务
命令入队
执行事务

常用命令

MULTI 开启事务 
EXEC 执行事务 
DISCARD 取消事务 
WATCH key 监听某个 key的值是否发生变化,如果发生变化, watch 之后的操作会失败

3、持久化机制

1、RDB

RDB(snapshotting快照)是将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢 复。
优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严 谨的时候

默认方式，将内存中以快照的方式写入到二进制文件中，默认为dump.rdb，可以通过配置设置自动做快照持久化的方式。我们 可以配置redis在n秒内如果m个key修改，就自动做快照

vim /usr/local/redis/conf/redis.conf 修改配置文件
RDB默认开启，redis.conf中的具体配置参数如下:

 save 900 1 : 900秒内，超过1个key被修改，则发起快照保存 
 save 300 10 : 300秒内，超过10个key被修改，则发起快照保存
 save 60 10000 : 60秒内，超过10000个key被修改，则发起快照保存 
 dbfilename dump.rdb  : 持久化数据存储在本地的文件 
 dir ./  : 持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当 前src目录下

持久化过程： 当满足save的条件时，比如更改了1个key，900s后会将数据写入临时文件，持久化完成后将临时文件替换旧的dump.rdb。 （存储数据的节点是到触发时间时的的节点） 使用RDB恢复数据： 自动的持久化数据存储到dump.rdb后。实际只要重启redis服务即可完成（启动redis的server时会从dump.rdb中先同步 数据）

使用命令进行持久化save存储：

 ./redis-cli -h ip -p port save 
 ./redis-cli -h ip -p port bgsave 

一个是在前台进行存储，一个是在后台进行存储。

2、AOF

AOF(append-only file) : 是将执行过的指令记录下来，数据恢复时按照从前到后的顺序再将指令执行一遍，实现数据恢复

优点：可以保持更高的数据完整性，如果设置追加file的时间是1s，如果redis发生故障，最多会丢失1s的数据；且如果日志 写入不完整支持redis-check-aof来进行日志修复；AOF文件没被rewrite之前（文件过大时会对命令进行合并重写），可 以删除其中的某些命令（比如误操作的flushall）。

缺点：AOF文件比RDB文件大，且恢复速度慢。

类似于mysql日志，由于快照方式是在一定时间间隔做一次，所以可能发生redis意外宕机的情况就会丢失最后一次快照后的 所有被修改的数据，aof比快照方式有更好的持久化型，是由于redis在使用aof时，redis会将每一个收到的写命令都通过 write函数追加到命令中，在redis重新启动时会重新执行文件中保存的写命令在内存中重建这个数据库的内容，这个文件在 redis/bin目录下，appendonly.aof。aof不是立即写到硬盘上，可以通过配置文件修改强制写到硬盘中。

修改配置:
appendonly yes : 启动aof持久化 ,持久化有三种方式：

#appendfsync always:收到写命令就立即写入到磁盘，效率最慢，但是保证完整的持久化（最常用） 
#appendfsync everysec : 每秒写一次硬盘，在性能和持久化方面做了很好的这种 #appendfsync no : 完全依赖os，性能最好，持久化没保证。

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

3、混合持久化

redis4.0之后支持混合RDB和AOF混合持久化
如果把混合持久化打开，aof rewrite 的时候就直接把 rdb 的内容写到 aof 文件开头，rdb会将aof的所有命令写成二进制.

4、缓存的淘汰策略

什么是缓存淘汰策略、简单的说就是当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的缓存的大小

5、主从复制

1、概念

Redis多副本，采用主从（replication）部署结构，相较于单副本而言最大的特点就是主从实例间数据实时同步，并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上，根据公司的基础环境配置，可以实现同时对外提供服务和读写分离策略。

将一台Redis服务器作主库(Matser)，其他三台作为从库(Slave)，主库只负责写数据，每次有数据更新都将更新的数据同步到它所有的从库，而从库只负责读数据。 这样一来，就有了两个好处： 读写分离，不仅可以提高服务器的负载能力并且可以根据读请求的规模自由增加或者减少从库的数量棒极了； 数据被复制成了了好几份，就算有一台机器出现故障，也可以使用其他机器的数据快速恢复。 需要注意的是：在Redis主从模式中，一台主库可以拥有多个从库，但是一个从库只能隶属于一个主库。

特点

1、Master可以拥有多个Slave
2、多个salve可以连接同一个Master，还可以链接到其他的slave 
3、主从复制不会阻塞Master，在同步数据时，master可以继续处理client请求 
4、提供系统的伸缩性

优点:

• 高可靠性：一方面，采用双机主备架构，能够在主库出现故障时自动进行主备切换，从库提升为主库提供服
  务，保证服务平稳运行；另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和
  数据异常丢失的问题
• 读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发量的读操作

6、哨兵模式

1、概念

Redis Sentinel是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel集群和Redis数据集群。其中Redis Sentinel集群是由Sentinel节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知

有了主从复制的实现之后，我们如果想从服务器进行监控，那么在redis2.6以后提供了一个”哨兵“机制，并在2.8版本以后功 能稳定起来。
哨兵：顾名思义，就是监控Redis系统的运行状况

2、特点

1、不时地监控redis是否按照预期良好地运行;
2、如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
3、能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一 个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。
4、哨兵为客户端提供服务发现，客户端链接哨兵，哨兵提供当前master的地址然后提供服务，如果出现切换，也就是master 挂了，哨兵会提供客户端一个新地址。

3、优点

• Redis Sentinel集群部署简单
• 能够解决Redis主从模式下的高可用切换问题
• 很方便实现Redis数据节点的线形扩展，轻松突破Redis自身单线程瓶颈，可极大满足Redis大容量或高性能的业务需求
• 可以实现一套Sentinel监控一组Redis数据节点或多组数据节点

4、缺点

• 部署相对Redis主从模式要复杂一些，原理理解更繁琐
• 资源浪费，Redis数据节点中slave节点作为备份节点不提供服务
• Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换，对Redis的数据节点做失败判定分为主观下线和客观下线两种，对于Redis的从节点有对节点做主观下线操作，并不执行故障转移
• 不能解决读写分离问题，实现起来相对复杂

5、配置

1、将Redis解压目录下的sentinal.xml文件复制到 /usr/local/zhucong/目录下

2、配置sentinal.xml文件

#配置的是配置文件的目录
dir /usr/local/zhucong/
#配置的是监听主服务器信息  最后一个参数很重要 一般设置为1  当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了
sentinel monitor mymaster 39.99.200.54 6379 1
#sentinel会向master发送心跳PING来确认master是否存活
sentinel down-after-milliseconds mymaster 5000
    
哨兵的启动命令
./redis-server /usr/local/zhucong/sentinel.conf  --sentinel &