Redis的持久化和缓存

redis持久化的机制的和方式和优缺点
1、redis持久化有两种方式rdb和aof；
（1）、rdb持久化（就是redis database缩写快照）
    rdb是redis默认的持久化方式，是按照指定的时间间隔内将内存中的数据以快照的方式保存到磁盘中，对应产生的数据文件为dump.rdb.
        通过配置文件中save参数来定义快照的周期
    恢复数据时，将rdb文件直接读取到内存中，具体做法：将rdb文件放到redis的启动目录上，redis会自动检查dump.rdb文件，恢复数据
        具体操作：当满足条件时，redis需要执行rdb的时候服务器会执行一下操作：
            （1）redis调用系统的fork(）函数创建一个子进程
            （2）子进程将数据集写入一个临时的rdb文件
            （3）当子进程完成对临时的rdb文件的写入时，redis用新的rdb文件来替换原来旧的rdb文件，并删除旧的rdb文件
优点：（1）适合大规模的数据恢复（使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能）

缺点:    (1) 需要一定时间的时间间隔进行操作，无法做到实时的持久化，所以适合对数据完整性不高的持久化操作

          （2）fork子进程的时候，会占用一定的内存空间

（2）、aof持久化（即 append only  file持久化）是将redis执行的每次（写命令）记录到日志文件中，当重启redis会加载appendonly.aof文件
来恢复数据
    默认是不采用aof，需要在配置文件中修改
aof是存放每条写命令的，所以会不断的增大，当大的一定程度时，aof会做rewrite操作，rewrite操作就是（基于当时redis的数据重新构造）一个小的aof文件，然后将大的aof文件删除

优点：（1）、aof日志文件适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，
那么就可以将日志文件中的flushall删除，进行恢复。
          （2）、每进行一次命令操作就记录到aof文件中一次，保证了数据的安全性和完整性
          （3）、aof以append-only的模式写入，所以没有任何的磁盘寻址的开销，写入性能非常的高

缺点：（1）、aof文件比rdb文件大，且恢复速度慢

主从复制（主：master ，从：slaver）:   主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，master以写为主，slave以读为主

优点：1、读写分离  2、容灾的快速恢复

配置从服务器：在从服务器上执行：slaveof  主机ip  端口号  

一主二仆：
    1、从服务挂掉后！
         （1）如果我们的连接不是直接在配置文件中写好的，而是启动6380端口和6381端口后使用SLAVEOF 127.0.0.1 6379命令，让他成为6379服务器的从机的话，当他们发生宕机之后，再次启动，他们    将作为主机重启，且数据不会自动跟6379进行同步（须使用命令让其再次变成从机）
       只有再次变成从机才能同步主机的数据
    （2）如果我们的主从关系，在从机的配置文件中写好了。那么，从机重启后，将会自动作为主机的从机启动，且同步彼此的数据。
    2、主服务器挂了后！
      主服务器挂了，   不做任何操作，重新启动后，从机会继续将6379当做大哥（主机）来对待。

主从复制原理：
    1、当从服务器连接上主服务器之后，从服务器向主服务器发送进行数据同步的消息
    2、主服务器接到从服务器发送过来的同步消息，把主服务器数据进行持久化，rdb文件
    把rdb文件发送到从服务器，从服务器拿到rdb进行读取
    3、每次主服务器进行写操作之后，和从服务器进行同步

薪火相传：
    主机下面的从服务器的下面还可以有从服务器
好处：这么做的好处了，减轻了主机的负担，但是，也有个缺点就是，前面的如果宕机的话，那么后边的将无法跟主机同步数据。

反客为主：
    当Master宕机后，后面的Slave可以立刻升级为Master，且后面的slave不用做任何修改，这就是反客为主。

    实现也很简单，在主服务器后面的从服务器中执行命令：SLAVEOF NO ONE即可（不自动，须要人来执行命令启动）

哨兵模式：反客为主的自动版。能够后台监控主机是否故障，如果故障了，根据投票数自动将从机转换为主机。

哨兵模型选择从服务器的条件优先顺序依次为：
1、优先级靠前的（redis.conf中replica-priority 的值越小，优先级越高）
2、偏移量最大的（获得原主机数据最全的）
3、runid最小的（每个redis实例启动后都会随机生成一个40位的runid）

开启哨兵模式：redis-sentinel sentinel.conf
复制延时：由于所有的写操作都在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器的数量也会使这个问题更加严重。

redis缓存：https://www.cnblogs.com/laiyw/p/15174422.html?ivk_sa=1024320u
    1、缓存穿透：访问缓存获取不到数据，都去访问数据库，因为数据库中就没有这个值，所以他会一直访问数据库，
    最终数据库压力过大，服务器崩溃了，这个过程就是缓存穿透
    特点：（1）应用服务器压力变大了 （2）redis命中率降低 （3）一直查询数据库
    （4）redis查询不到数据 （5） 出现不正常的url访问

    解决方案 1、对空值缓存：如果一个查询返回的数据为空，不管是否不存在，我们仍然把这个空结果null进行缓存
        2、设置可访问的名单（白名单）：可以使用bitmaps类型定义一个可以访问的名单
        名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在里面，进行拦截
        3、采用布隆过滤器：底层还是bitmaps
        4、进行实时监控：当发现redis的命中率开始急速降低，需要排查访问对象和访问数据
            （通过运维人员配合，可以设置黑名单限制服务）

缓存击穿：redis中某个key过期了，大量访问使用这个key 不断访问数据库 这个过程叫做缓存击穿
    特点：（1）数据库访问压力瞬间增加
        （2）redis里面并没有出现大量key过期
        （3）redis正常运行
    解决方案：(1)、预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis中
    加大这些热门数据key过期时长
        （2）实时调整：现场监控哪些数据热门，实时调整key的过期时长。
        
        （3）使用锁

雪崩：

分布式锁：分布式锁对整个集群都有效，一旦上锁，不管下一个操作是在当前机器，还是集群中
    的其他机器，都识别，只能等待，等锁释放之后，才能进行操作。
    1、使用setnx上锁，通过del释放锁
    2、锁一直没有释放，可以设置key过期的时间，自动释放锁
    3、上锁之后突然出现异常，无法设置过期时间。（可以在上锁的同时设置过期时间）

确保分布式锁可用：1、互斥性，在任意时候，只有一个客服端能持有锁
        2、不会发生死锁，即使有一个客户端在持有锁的期间崩溃而没有主动解锁，
        也能保证后续其他客户端能枷锁
        3、加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了
        4、加锁和解锁必须具有原子性

什么是集群？（无中心结构）
    redis集群实现了redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中。
每个节点存储总数据的1/N

优点：redis集群通过分区，来提供一定程度的可用性：即使集群中有一部分节点失效或者无法进行通讯
集群也可以继续处理命令请求。

插槽：一个redis集群中包含16384个插槽（0-16383）数据库中每一个键都属于这16384个插槽的其中一个
（集群中每个节点负责处理一部分插槽）