Redis(二)持久化和集群选举机制

持久化，主从，哨兵架构，内存淘汰机制
这次来介绍redis持久化，主从，哨兵架构。对于持久化而言，除非是那种数据无关紧要，数据量少，说明是当纯内存在做缓存。其他情况下一般是开启持久化，因为如果不开启持久化，当redis宕机时，缓存被击穿，大量请求落到mysql上，mysql会撑不住的，redis的持久化方式分为三种，包括rdb，aof和混合模式。

RDB

所谓的rdb就是一个快照机制，是对redis中的数据执行周期性的持久化。可以在conf文件下设置多少秒内改动多少次数据会触发rdb快照机制，他会将内存中的所有数据一次性的快照成dump.rdb 二进制文件，放在指定文件夹中，如果原来有这个文件，就会覆盖。他是经过压缩的二进制，所以打开这个文件后，我们是读不懂的，而二进制文件名和所在的文件夹是可以conf设置的。除了自动触发快照外，我们还可以用命令来主动执行快照，他包括save和bgsave，区别是是否异步，bgsave会从redis主进程中调用linux的fork出一个子进程来专门用来生成rdb文件，不会阻塞客户端，而且会用cow，copy on write子进程创建后，父子进程共享数据，父进程继续提供写服务，写脏的页面数据会逐渐和子进程分离开。想要关闭rdb只用把conf中的save策略注释掉就可以。rdb的 的特点是二进制压缩文件。二进制可以直接读取到内存，所以读取快，在重启的时候数据恢复的速度快，而且压缩后的rdb文件大小比较小，比aof小，但他容易在宕机时丢失数据，因为两次快照之间有时间间隔，数据不够完整，所以rdb的启动优先级比aof低，也就是说，两种方式都开启时，优先用aof。rdb适合做冷备份，aof适合做热备份。优点是启动恢复快，文件小，且有某时刻的redis里面的数据。缺点数据不太安全。

AOF

所谓的aof，他和rdb的区别有两点。一是在于aof文件存的不再是数据了，而是命令，所以他的大小比rdb二进制压缩文件小。二是策略不一样，rdb的触发策略是完全基于时间的，aof有三种策略，一种是每条set命令后就会触发，二是每秒触发，三是不确定何时触发，交给操作系统决定。我们一般折中选择使用策略二，也就是每秒触发一次aof，因为策略一触发太频繁，影响速度，而策略三又是个不确定的，所以选择策略二，兼顾速度和安全性，虽然看似还是会失去一秒钟的数据，但是这点缓存交给mysql还是能够抗住的。接下来说一下aof文件，他的全名是appendonly.aof，文件名可以设置，文件夹和dump.rdb共用。aof文件中的内容也是经过处理的，存的是resp格式，包括了参数个数和下一个命令的长度，发生aof重写，很显然，多条set中基本上只有最后一条set有意义，所以根据最新数据，aof重写会把多个set合并成一条，重写的频率也可以通过conf来配置，配置的选项有aof文件的大小，大小达到阈值后会触发，还有就是距离上一次重写，数据增大100%会触发重写。和rdb一样，可以手动触发aof重写，命令是bgrewirteaof，显然是fork出子进程在后台执行重写。优点是数据安全性高，缺点是文件大，命令执行也慢，但他数据足够安全，所以两种持久化方式都开启时，优先选择aof，而且默认是aof持久化。

混合策略

混合策略是在aof上改进的，之所以在aof上改进是为了保证数据安全性，采用的还是appendonly.aof，他改变的是aof文件中的存储格式和aof重写，他的存储格式是之前重写之前的文件格式是rdb，而set时存入的是aof格式加在文件尾部，在重写时，把aof改为rdb，进行文件覆盖。这样既利用了aof的安全性的优点，又利用了rdb的加载快的优点。

集群

最后来说一下为了解决单机瓶颈采用的集群，首先是redis的最基础的主从架构。如果是单机的redis的话，无法处理宕机，读写操作放在一起的话，效率也低。先来说宕机，主从架构中，主结点挂后，从结点可以变成主结点，但并不涉及选举，需要手动，当然，他的缺点就是这个转换过程太长了，也就存在宕机问题。再来说一下主从的读写分离，主结点只执行写命令，而从结点执行读命令，所以他们之间的数据需要同步，这就涉及到主从复制数据同步，主从复制的原理步骤分为两步，一是全量同步，他发生在第一次的主从复制中和某些特殊情况，大致的步骤是从结点发送让主结点同步数据的命令psync命令，主结点在收到这个同步命令后，执行bgsave，fork出子进程来生成最新的rdb快照数据，然后把快照发送给从结点，这样就完成了数据同步。当然，全量同步有个小问题，就是master在执行bgsave命令时，可能有新的写命令被master，而这些命令是没有被生成rdb的，而redis这个小问题也被考虑到了，master会有一个缓冲区来存放这一小段时间的新命令，然后把这些缓冲区中的新命令发送给slaver，这就是全量同步的所有内容了。除了第一次数据同步，剩下的数据同步是增量同步，包括从结点断连的情况。增量同步的一个特点就是从结点向主结点发送psync会携带偏移量offset，主结点在执行一次全量同步后，会维护一个缓存队列，来缓存全量同步后的命令。主结点利用offset在缓存队列中进行定位，生成快照时只会生成偏移量后面的数据，但也有特殊情况，就是可能因为从结点断连太长，导致offset定位的命令已经出了缓存队列，这时又会触发全量同步。

为了解决宕机问题，提出了哨兵架构。所谓的哨兵，他也是redis客户端，他也可以集群。他不提供读写服务，他唯一的作用就是解决主从架构的宕机问题，他会监听所有的主结点和从结点，并且进行消息通知，并主从切换。当我们第一次来连接时，通过哨兵来获取主结点的ip地址，以后就可以直接访问，但是，当主结点宕机后，从结点变成主结点时，哨兵就会监听到这个动作，马上更新主结点的ip，并告诉客户端更新后的主节点ip。哨兵模式的效果是，在我们kill掉主结点模拟宕机后，应用程序不断抛出异常，一段时间后恢复，又可以设置值了，之所以需要挺长的时间，是因为选举主结点需要时间。查看redis的配置文件可以看到，里面的身份信息被动态更新了，当原来的master重启后，无法再恢复身份，而是变成slaver。哨兵架构也有很大的两个缺点，首先就是主从切换导致选举时的间隔太长了，此时会不断抛出异常，用户体验不好。第二个确定是哨兵架构他的master只有一个，无法处理写请求的高并发。这需要集群架构来解决，后面说。

接下来说一下java操作redis哨兵架构，需要的maven包有两个，包括spring-boot-start-date-redis和common-pool2。再配置好yml后就能使用了。在使用时，需要注意使用的是stringRedisTemplate.opsForValues.set(key,value)，而不是使用RedisTemplate，他们之间的区别是序列化的方式，前者是后者的子类，提供的api都一样，但是使用的是string的序列化方式，存的数据我们能够看懂，而后者提供的是jdk提供的序列化方式，虽然不影响使用，但是redis客户端存的数据，人类看不懂。推荐使用前者。

最后说一下redis的过期策略和内存淘汰机制。过期策略就是定期删除+惰性删除，用到了，发现过期才删。若定期没删，也没查询，那么就内存淘汰机制，分为lru，random，ttl等等