Redis事务_锁机制 _秒杀

Redis的事务定义

Redis事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断

Redis事务的主要作用就是串联多个命令防止别的命令插队

MUlti 、Exec、discard

从输入Mulit命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行

组队过程中可以通过discard来放弃组队

事务的错误处理

组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消

如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚

悲观锁

悲观锁，顾名思义就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿到这个数据就会block直到他拿到锁。传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁

乐观锁

乐观锁，每次去拿数据的时候都认为别人不会修改，所以不上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

Redis事务三特性

单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端对象发送来的命令请求所打断

没有隔离级别的概念

队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

不保证原子性

事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

Redis持久化之RDB

RDB：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，他恢复时是将快照文件直接读到内存里

备份如何执行的

Redis会单独创建（fork）一个子进行来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加高效。RDB的缺点是最后一次持久化后的数据可能丢失

Fork

• Fork的作用是复制一个与当前进程一样的进程，新进程的所有数据数值都和原进程一致，但是是一个全新的进行，并作为原进程的子进程。

• 在Linux程序中，fork（）会产生一个和父进程完全相同的子进程，但子进程在此后会exec系统调用，处于效率考虑，Linux中引入了写时复制技术

• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容发生变化时，才会将父进程的内容复制一份给子进程

  优势

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

劣势

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

AOF

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

AOF持久化流程

1）客户端的请求写命令会被append追加到AOF缓冲区内；

2）AOF缓冲区根据AOF持久化策略将操作sync同步到磁盘的AOF文件中

3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量

4）Redis重启服务时，会重新load加载AOF文件中的写操作达到数据恢复的目的

AOF默认不开启

AOF和RDB同时开启，Redis听谁的？

系统默认取AOF的数据（数据不会存在丢失）

优势

• 备份机制更稳健，丢失数据概率更低

• 可读的日志文本，通过操作AOF稳健，可以处理误操作

劣势

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

用哪个好？

• RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储
• AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候就会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次的写操作到文件末尾
• Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
• 只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不用任何持久化方式
• 同时开启两种持久化方式
• 在这种情况下，当Redis重启的时候就会优先载入AOF文件来恢复原始的数据，因为正常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
• RDB的数据不实时，同时使用两者服务器重启也只会找AOF文件，那要不要只用AOF呢？
• 建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段

Redis主从复制

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

能干嘛

读写分离，性能扩展

容灾快速恢复

复制原理

• Slave启动成功连接到master后会发送一个sync命令

• Master接到命令启动后台的存盘进程，同时手机所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步

• 全量复制：而slave服务在接受到数据库文件后，将其村哦按并加载到内存中

• 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步

• 但是只要重新连接master，一次完全同步将被自动执行