redis哨兵

一、redis模板类过期时间？
从redis获取key对应的过期时间
如果该值有过期时间，就返回相应的过期时间，
如果该值没有设置过期时间，就返回-1
如果没有该值就返回-2
public Long getExpire(final String key) {
return redisTemplate.opsForValue().getOperations().getExpire(key);
}
二、redis主从复制
主机可以写，从机不能写只能读，主机中所有信息都会被从机保存，主机断开连接，从机依旧连接到主机但是没有写操作，这个时候主机如果回来了，从机依旧可以直接获取到主机写的信息。
如果是命令行配置的主从，这个时候如果重启了，从机会变成主机（redis默认都是主机），只要变回从机，立马从主机中获取值
复制原理：
slave启动成功连接到master后会发送一个sync同步命令
master接收到命令，启动后台的存盘进程，同时收集所有接受的用于修改数据集命令，在后台进程完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：slave服务在接收到数据库文件数据后，将其存盘并加载到内存中
增量复制：Master继续将新的所有收集到的修改命令一次传给slave，完成同步。
但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。
手动配置
如果主机断开连接，我们可以使用slaveof no one让自己变成主机，其他节点可以手动连接到这个新的主节点，如果这个时候老大修复需要重新配置
哨兵模式：
哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，他会独立运行。其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行的多个redis实例。
配置多哨兵模式
哨兵之间也需要互相监控，假设master主服务宕机，哨兵1先检测到这个结果，系统并不会马上failover进程，仅仅是哨兵1主观认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值的时候哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover（故障转移）操作，切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
1.配置哨兵配置文件：sentinel.conf
sentinel monitor 被监控得名称 host port 1
后面的这个数字1，代表主机挂了，给slave投票看让谁接替成为主机
2.启动哨兵
如果主机此时回来了，只能归并到新的主机下当作从机，这就是哨兵模式的规则。
哨兵模式的优点：
1.哨兵集群，基于主从复制模式，所有的主从复制优点全有
2.主从可以切换，故障可以转移，系统可用性好
3.哨兵模式就是主从模式的升级，从手动到自动，更加健壮
缺点：
redis不好在线扩容，集群容量一旦到达上线，在线扩容就十分麻烦。
实现哨兵配置十分麻烦
redis缓存穿透，缓存击穿和雪崩
缓存穿透： 用户查询一个数据发现redis缓存内没有，也就是缓存没命中，于是向持久层数据库查询，发现也没有，于是本次查询失败，当用户很多的时候查询缓存都没命中，这些请求会直接到持久层数据库，这会给数据库很大压力，这就是缓存穿透
解决办法：缓存空对象，用户请求没有的话走缓存内的空
缺点：如果空值被缓存起来，这意味着缓存中需要更多的空间去存储更多的键，这些键很多还都是空的。即使对空值的键设置过期时间，还是会存在缓存层和持久层数据会有一段时间的窗口不一致（持久层已经有数据了缓存层还是空）对于需要保持一致性的业务会有影响。
布隆过滤器
**缓存击穿：**也就是说某个key非常热点，访问频率很高，处于集中式高并发访问的情况，当这个key在失效的瞬间大量的请求就击穿了缓存直接到达数据库就像是在屏障上凿开了一个洞。
解决办法：将热点数据设置为永不过期或者基于redis or zookeeper实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其他请求才能通过该key访问数据
**缓存雪崩：**某个时间段redis内的缓存集中过期失效，redis宕机，系统内涌入大量查询请求，因为大部分数据再redis层已经失效，请求渗进数据库层，大量请求引起数据库压力造成查询堵塞宕机。
解决办法：
1.将缓存失效时间分散开，比如让每个key的过期时间随机，防止大量的数据过期现象发生，这样不会出现同一时间全部请求落在数据库层，如果缓存数据库是分布式部署，将热点数据均匀分布在不同的redis和数据库上，有效分担压力。
2.让redis数据永不过期，业务数据允许的情况下。
五、redis是单线程如何实现高并发？
redis采用多路IO复用技术让单个线程高效处理多个连接请求
Io多路复用有三种发方式select,poll,epoll

select: 注册事件由数组管理, 数组是有长度的, 32位机上限1024, 64位机上限2048. 轮询查找时需要遍历数组。

poll: 把select的数组采用链表实现, 因此没了最大数量的限制。

epoll方式: 基于事件回调机制, 回调时直接通知进程, 无须使用某种方式来查看状态。
redis速度快总结：
Redis是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在IO上，所以读取速度快。
Redis使用的是非阻塞IO，IO多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。
Redis采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。
数据结构也帮了不少忙，Redis全程使用hash结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。
Redis采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。
redis持久化（RDB/AOF）
RDB：在指定时间间隔内将内存数据库快照写入磁盘内，它恢复是将快照文件直接读到内存中。redis会临时创建一个子进程进行持久化，会将数据写到一个临时文件内，持久化进程完成后，用这个临时文件替换上次持久化好的文件dump.rdb。
优势：1.适合大量数据的恢复
2.对数据完整性和一致性要求较低（最后一次持久化可能会丢失数据）
劣势：
1.在一定间隔时间内做一次持久化，如果redis意外宕机就会丢掉最后一次快照的所有修改。
2.创建子进程进行持久化的时候，内存中的数据被复制一份，占用内存空间。
AOF：以日志的形式记录所有的写操作（不记录读操作），它只是追加文件，不会重写，启动的话就从此文件读取所有操作重构数据。
配置的话就只需要在redis.conf中的appendonly no 该为yes，默认存储到appendonly.aof文件中
优势：保证数据完整性
相同数据量的数据效率不如RDB，而且aof文件所占内存大于rdb文件
操作redis使用jedispool获取到jedis，使用spring集成的redistemplate
redis的事务一组操作命令的集合，所有命令都被序列化，有序执行
multi：开启事务
exec：执行事务
watch：监控一个或多个key是否发生变化
discard：取消事务，如果有被监控则取消监控
unwatch：取消监控
项目中的话使用watch+multi+exec+discard来达到一个乐观锁的目的处理页面