Redis基础

redis持久化
RDB快照，在某个时刻触发，触发后存储这个时刻所有的数据；
优点：相较于aof恢复数据速度快，储存的体积小
缺点：宕机时，最后一个触发点到之后所有的数据都丢失了；
AOF：每个指令都存储起来，或者每1秒储存一次指令(这个用的多)
优点：数据不会丢失，有也是丢失一秒
缺点：体积庞大，恢复慢
AOF重写：当AOF文件的大小达到一定程度的时候，将自动开启AOF重写将垃圾命令去掉，留下有效指令；
redis 4.0混合持久化
取RDB和AOF共同的优点，根为AOF持久化，但是每做AOF重写的时候，不再式压缩指令，而是以快照的方式去存储aof数据。
新版本之后一般都使用混合方式持久化redis；
redis主从架构
概念：从节点只读不写，分担主节点的读压力。
流程：再redis文件配置了主从架构后，先建立连接，然后主节点生成最新的rdb快照文件，(再此期间生成的数据将会缓存起来)，发送rdb快照文件到从节点，从节点清空数据加载主节点rdb文件，然后主节点再把缓存数据发送过来。如果连接不断，那么主节点就是通过命令的方式把数据同步到从节点中。
断点续传：
重新连接后，先建立长连接，从节点把数据复制到哪一条(偏移量)发给主节点，主节则在自己缓存的指令中找这个指令，如果找到了那么将该数据之后的所有数据发给从节点。如果找不到那么就会全量复制。
哨兵模式：在主从架构的基础上，添加redis节点只用于监听是否有节点宕机了。如果主节点宕机了，那么哨兵通过投票在从节点选出一个来当主节点。
redis集群
由多个主从架构组成，不需要哨兵，自身就能完成主节点故障后自动在从节点中选举一个主节点；
redis集群原理
将储存空间分成16384个虚拟槽位，均匀的分给每个主从架构。每天主节点只负责自己虚拟槽位的数据。
跳转重定向
客户端维护一个本地映射表，如果映射表不对的时候，key就会访问到错误的redis服务器上。当redis服务器意识到访问错误后将返回正确的地址给客户端，客户端重新发起请求，并且修改本地映射表。
redis脑裂
主节点与其他节点失联，但是依旧与客户端关联，并且写了数据。当这个主节点与其他节点失联时间达到限制后，将会被其他节点废除，被其他从节点取代。那么这段时间写的数据都将丢失。
解决方案：配置主节点写数据时，必须写到另外从节点至少一个成功才能算成功与客户端交互。但一般不这么做，这样会降低效率。
为什么搭建奇数个节点
因为选举是过半数选举，当三台机器的时候允许一宕机，四台的时候也只是允许一台宕机，防故障效率没有提高。奇数台更好。
redis缓存穿透
不存在的数据一直访问服务器，不断的穿透redis去数据库中查找数据。
布隆函数：有效key通过hash运算得到散列值，将这些散列值存储在一个足够大的数组中，比如数十亿，百亿大小的数组。当有key来访问，通过hash运算得到的散列值在在数组上都得到对用那么其可能存在，否则就一定不存在。
java把布隆函数已经做了封装我们直接使用就可以了。
缓存失效(击穿)
大批缓存同时到期导致大量请求直接到了数据库；
设置缓存时间时，可以是固定时间+一些随机时间，使得他们到期时间不一致。
缓存雪崩
就是访问量巨大，redis支撑不住，redis宕机或者出现故障；
1、使用redis哨兵或者集群，加强rendis高可用性能；
2、后端限流，熔断并降级；
缓存与数据库双写不一致
使用redis分布式锁，在关键步骤上串行执行。并行处理这些数据没办法保证百分百一致而且代价很大。
key与value
key：可读性，不重复性，长度不宜过长，避免特殊字符。
value：String格式控制在10kb大小，hash,list,set,zset:不能超过5000kb
连接池关键参数配置
最大连接数，允许最大空闲的连接数，最少空闲的连接数(redis预热，将其连接数预热到最少空闲连接数，避免压力过大处理不了)
redis删除策略
被动删除：只有在getkey的时候才会把过期的key清理掉。
主动删除：redis通过一些自身的策略去删除key
LRU算法：淘汰很久没有被访问过的数据。(热点数据，我们平常都使用这总算法)
LFU算法：近期访问最少的数据。(周期性，批量处理的数据使用这种算法)
redis锁：
INCR：初始化为0，加锁时多加1动作，返回，如果等于1加锁成功。
SETNX：设置key，value，如果已存在则会设置失败。获取锁失败。
SET:在原有基础上加了超时设置，这些都是原子操作。

①在finally中删除rediskey，防止抛出异常情况下rediskey没有被清理；
②超时时间设置为10秒,防止主机崩溃，重启等情况，redis的key无法清理，永远存在的情况，并且以原子的方式设置超时时间，避免还未设置超时时间就被重启，redis永远存在，其他redis永远无法设置成功
③高并发场景下，如果有单子超过10秒以上执行完毕，那么会出现非常严重的问题，
例子：A线程超时，自动删除a锁，B线程获取了锁进入代码块并设置b锁，A线程又继续进行执行finally中代码删除锁，这时删除的锁会会是b锁，以此类推，我们的redis锁就失效了，加完锁马上被前面一个线程删除掉了；
方案：将UUID设置到value中，确保每一个线程删除的锁，是自己线程的锁；
④因为存在可能有极少情况下超时的情况，也不能把锁的时间无限增长，出现②那种情况等太久也不行
方案： 可以添加一个多线程，当线程没有停止运行，每过一段时间给这把锁延长一定的时间