Redis学习笔记之事务，持久化，主从复制（总体第三篇）

前面两篇文章中已经学习到了redis的数据类型，及SpringBoot项目整合redis，还有一些新的数据类型的相关内容，接下来学习我们的事务等一系列内容。学习资源地址

一、事务

1、redis事务介绍

（1）概念

（2）命令

• 刚刚登录的时候发现报错了【执行以下命令就好啦】
  

（3）命令练习

• 执行multi就开启了组队了
• 当你执行了exec就你的组队的执行完成了
• 当你如下情况不想执行了【你中途不想再组了】
  
  那执行如下命令即可【放弃组队】
  

（4）当有命令错误的情况

• 在组队时候错误【一个错误，其他的所有都不会执行】
  
• 当错误在【在执行的时候】
  

2、redis事务冲突

（1）事务分析

（2）redis怎么处理问题的呢？

• 悲观锁
  
  
  
  
• 乐观锁
  
  

（3）WACTH key命令

在执行multi之前，先执行watch key1 key2 可以监视一个（多个）key，如果在事务执行之前这个（这些）key被其他命令所改动，那么事务将会被打断

（4）UNWACTH

• 它就是终止执行的

（5）redis事务三特性

3、redis事务练习

（1）分析一下逻辑

• 最后就是秒杀过程：库存减一，秒杀成功的用户添加到清单里面去。

（2）编写代码

public class seckill_redis {

    public static void main(String[] args) {

    }


    public static boolean kill(String uid,String prodId) {
        //uid和proiid判断
        if (uid == null || prodId == null) {
            return false;
        }

        //连接redis
        Jedis jedis = new Jedis("localhost",6379);

        //拼接key
            //库存id
        String kcKey = "sk:" + prodId + ":qt";//这个我们要在redis里面创建的一个key，设置值为10
            //秒杀成功用户key
        String userKey = "sk:" + prodId + ":user";

        //获取库存，如果库存为null，秒杀还没有开始
        String kc = jedis.get(kcKey);
        if (kc == null) {
            System.out.println("秒杀还没有开始");
            jedis.close();
            return false;
        }

        //判断用户是否重复秒杀
        Boolean sismember = jedis.sismember(userKey, uid);
        if (sismember != null) {
            System.out.println("你已经秒杀过，不能重复秒杀");
        }

        //判断库存是否大于0
        if (Integer.parseInt(kc) <= 0) {
            System.out.println("秒杀获取已结束");
            jedis.close();
            return false;
        }

        //秒杀过程
        jedis.decr(kcKey);
        //添加秒杀用户到清单页面
        jedis.sadd(userKey,uid);
        System.out.println("秒杀成功了");
        jedis.close();
        return true;
    }
}

二、持久化

• 持久化介绍
  redis基于内存的，但是它也可以写到内存里面去，这个就是持久化，具体写入过程分为RDB和AOF

（一）RDB

1、介绍

（1）概念介绍

• RDB是在指定的时间间隔内存中的数据集快照写入磁盘。【即在一段时间内，你内存中的数据有哪些，把它写到内存中去】
• 如何实现呢？：Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

• Fork是
  • Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
  • 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
  • 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

（2）看下配置文件

• 上面过程是默认有的，不配置也会默认有一个文件【看如下的配置文件】
  
  你启动了你的redis，都会在你的启动目录，生成一个dump.rdb文件。
• 看看如下的一些配置
  
• rdbcompression压缩文件【你磁盘文件是否压缩存储】
  
• rdbchecksum检查完整性。
  

（3）命令

• save
  
  持久化，并不是改一个数据就会持久化，而是在一定的时间范围内，必须修改到了多少次，才会触发持久化。
• bgsave
  
• flushall命令
  执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义

2、代码演示

（1）代码演示

• save名：save 间隔时间 修改次数
  
• 我们修改一个
  
• 演示一下【此时你只要在20秒内往你面设置键值对3次及以上，那就会触发了】
  • 看启动失败解决版本
    
    
    这样解决就OK了
  • 看一下代码演示
    
    
• 上面可能是会存在数据丢失的【比如20秒内，你加了20个key，在20秒内服务器挂掉了，那此时你的数据就会丢失，另外一种情况，你的数量不够也可能会出现问题】

（2）看一下配置文件

• stop-writes-on-bgsave-error
  
  当Redis无法写入磁盘的话，直接关掉Redis的写操作。推荐yes.

• rdbcompression压缩文件
  
  对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。
  如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。推荐yes.

• redbchecksum检查完整性
  
  在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐yes.

3、rdp的备份

之前的数据恢复过来，是什么样子的情况呢

• 首先按当我们redis在你停掉redis之后，你的dump文件假设背删除了，那可以恢复。【其实就是把你之前的数据复制一份，然后再改为dump.rdb的文件】
  

4、优点与缺点

（1）优势

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快
  

（2）劣势

• Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

5、如何停止rdb模式

动态停止RDB：redis-cli config set save “”#save后给空值，表示禁用保存策略

6、小结

（二）AOF

• 上面我们讲到了，如果你的数据要求很精确，不能有一个错误的情况下，不适合使用rdp进行处理

1、什么是AOF（Append Only File）

• 以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2、AOF持久化流程

• 客户端的请求写命令会被append追加到AOF缓冲区内；
• AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
• AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
• Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；
  

##3、AOF的一些配置

• AOF默认不开启【appendonly no】
  

• 同样的生成位置和dump一样的位置【如果上面修改，重启服务】

• AOF和RDB
  

• AOF的恢复

  • 正常恢复
    
  • 异常恢复【就比如你的aof文件被人通过不正当手段给修改了，也会报如下的错误】
    
    
    然后重启redis就OK了

3、其他的一些设置

（1）AOF同步频率设置

（2）Rewrite压缩

• 是什么：
  AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
• 重写原理，如何实现重写
  AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。
  no-appendfsync-on-rewrite：
  如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
  如果 no-appendfsync-on-rewrite=no, 还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）
  触发机制，何时重写
  Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
  重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。
  auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）
  auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。
  例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB
  系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,
  如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。
• 重写流程
  （1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
  （2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。
  （3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
  （4）1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
  （5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

4、优缺点

（1）优点

• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作AOF稳健，可以处理误操作。

（2）劣势

• 比起RDB占用更多的磁盘空间。
• 恢复备份速度要慢。
• 每次读写都同步的话，有一定的性能压力。
• 存在个别Bug，造成恢复不能。

5、小结

（三）总结

官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。

	RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
	AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾. 
	Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
	只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
	同时开启两种持久化方式
	在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据, 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整.
	RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？ 
	建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)， 快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
	性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
 
如果使用AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。
代价,一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。
默认超过原大小100%大小时重写可以改到适当的数值。

四、主从复制

1、介绍

• 主机数据更新后，根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。

• 分析
  
  如果想要多个主机的情况，建议处理为集群
  

2、一主多从

（1）如何查询

怎么说呢，这个需要多态主机演示，具体的我这里就不具体的演示了，可以看一下如下的过程

• 可以通过info replication打印主从复制的相关信息
  
  role是master就是主机，如果是slave就是从机。

（2）如何设置主从关系

• 在从机上执行如下命令：slaveof ip就是你主机的ip地址，port就是主机端口号。

（3）写和读的关系

• 在主机上可以写和读

• 而在从机上只能读，不能写，如果写就会报错。

另外情况是，主机什么都不用设置，如果重启了，还是什么都不用配置，就可以使用，而从机器要从新执行slaveof命令 ，但是可以在文件里面配置

3、一主二仆

（1）看几个比较经典的问题

• 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的k1,k2,k3是否也可以复制？
• 从机是否可以写？set可否？
  • 答案是不可以，会报错 。
• 主机shutdown后情况如何？从机是上位还是原地待命？
  • 从机还是原地待命，主机回来后，也是会连接上的。
• 主机又回来了后，主机新增记录，从机还能否顺利复制？
  • 主机回来后，数据还是可以复制过来的。
• 其中一台从机down后情况如何？依照原有它能跟上大部队吗？
  • 从机挂了后，没有配置的话，就跟不上大部队了

（2）主从复制的原理

• Slave启动成功连接到master后会发送一个sync命令
• Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令， 在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
• 全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
• 但是只要是重新连接master,一次完全同步（全量复制)将被自动执行
  

4、主从复制之薪火相传

上一个Slave可以是下一个slave的Master，Slave同样可以接收其他 slaves的连接和同步请求，那么该slave作为了链条中下一个的master, 可以有效减轻master的写压力,去中心化降低风险。

• 设置从服务器和从服务器用： slaveof ，执行之后，此时你的主机就只有一个从服务器了。
  中途变更转向:会清除之前的数据，重新建立拷贝最新的
  风险是一旦某个slave宕机，后面的slave都没法备份
  主机挂了，从机还是从机，无法写数据了
  

5、主从复制之反客为主

• 当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。【只要在某一台从机上执行命令后，即可身为这样的机器】：slaveof no one

• 这种模式怎么说呢，就是如果晚上3点钟，你的主机挂掉了，那你叫你去执行命令，你愿意吗，不愿意吧，所以看如下的

6、主从复制之哨兵模式

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

（1）配置哨兵模式

• 首先要在指定的位置创建一个文件sentinel.conf文件，名字不能错。
• 然后就执行：sentinel monitor mymaster 127.0.0.1 6379 1
  其中mymaster为监控对象起的服务器名称， 1 为至少有多少个哨兵同意迁移的数量。

（2）启动哨兵

启动redis服务后：执行命令如下：redis-sentinel /你的文件路径/sentinel.conf

(大概10秒左右可以看到哨兵窗口日志，切换了新的主机)
哪个从机会被选举为主机呢？根据优先级别：slave-priority 原主机重启后会变为从机。

（3）复制延时

由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重。

（4）故障恢复