Redis相关笔记

事务:

Redis的事务能保证一批原子性的执行，即所有命令或者都执行或者都不执行。并且在事务执行的过程中不会为其他任何命令提供服务。当Redis重新启动或者加载AOF文件时也会保证事务命令的完整性。

 

由于要保证事务的原子性，Redis提供了multi和exec命令来显式开启与提交事务。开启事务之后所有的命令会首先入队而不是直接执行，只有显式的提交事务之后该事务才会执行。multi incr incrby decr decrby exec discard watch unwatch

放弃一个事务选择discard，即将exec替换成discard，使用watch命令来提供一种乐观锁机制，watch命令可以监听多个key，只有当被监听的key修改时，事务才会执行。当被监听的键在事务开始之前被修改了，那么事务不会被执行，但是，注意：当一个事务发送exec或者discard命令的时候，所有的key会自动unwatch

 

事务命令有watch，unwatch，multi，exec和discard。watch和unwatch实现了一种乐观锁的机制，multi用来显式的开启一个事务，exec用来提交并执行事务，discard用来放弃事务。

watch：监听指定的key，只有当指定的key没有变化时该连接上的事务才会执行，返回值为OK

格式：watch key[key...]

 

发布订阅命令：

一个客户：subscribe msg1（订阅） ，另一个客户端：publish msg1 helloworld（发布），回到订阅的客户端，观察输出：数组形式，第一项为固定的“message”字符串，第二行为你订阅的channel名称，我们这里为：“msg1”，第三项为消息体，本例中为helloword，还可以发送数组等，eg：publish msg1 [s1,s2,s3...]。

也可以通过通配符订阅多个
PSUBSCRIBE * 订阅所有发布的信息
PSUBSCRIBE test* 订阅所有已test开头的

publish命令执行完毕之后会同步到Redis从服务中，这样如果一个客户端订阅了从服务的channel，在主服务中会向该channel推送消息时候，该客户端也能收到推送消息

取消订阅命令

unsubscribe，如果不指定，该客户端所有的订阅都会被取消 unsubscribe  channel1,channel2  ,  punsubscribe取消所有订阅

查看订阅状态，pubsub channels[pattern]，不指定pattern时候，将会返回给该客户端所有的channels列表，

pubsub NUMPAT ，返回模式订阅的个数

 

持久化：

Redis是一个内存数据库，当机器重启之后内存中的数据就会全部丢失。所以对于Redis来说，持久化显得尤其重要。Redis有两种持久化的方式，一种为RDB方式，RDB保存着某一时间点之前的数据；；另一种为AOF方式，AOF保存的是Redis服务器端执行的每一条命令。两种方式各有优劣，在接下来的章节中会详细介绍。我们会通过在客户端输入info命令，查看Redis服务端记录的相关持久化状态信息，然后分别详细介绍RDB和AOF

RDB：RDB快照有两种触发方式，其一为通过配置参数，例如在配置文件中写入如下配置：

save 60 1000，则在60秒内有1000个key发生变化，就会触发一次RDB快照的执行。

其二则是通过在客户端执行bgsave命令触发一次RDB快照的执行。bgsave执行流程如下：

 

 

 在客户端输入bgsave命令后，redis调用bgsaveCommand函数，该函数fork一个子进程执行rdbSave函数进行实际的快照存储工作，而父进程可以继续处理客户端的请求。当子进程退出后，父进程会调用相关回调函数进行后续处理。

RDB文件结构  https://www.cnblogs.com/huangxincheng/p/5074998.html

 

AOF是Redis的另一种持久化方式，简单来说，AOF就是将Redis服务端执行过的每一条命令都保存到一个文件，这样当Redis重启时只要按顺序回放这些命令就会恢复到原来的状态

区别:RDB保存的是一个时间点的快照，那么如果Redis出现了故障，丢失就是从最后一次RDB执行的时间点到故障发生的时间间隔之间的数据，如果数据量很大，QPS很高（每秒查询率很高），那么执行一次RDB需要的时间会相应增加，发生故障时丢失的数据也会增多。

而AOF保存的是一条条命令，理论上可以做到发生故障时候只丢失一条命令，但由于操作系统执行写操作代价很大，Redis提供了配置参数，通过安全性和性能的折中，我们可以设置不同的策略。

既然AOF数据安全性能很高，是否可以只用AOF呢，为什么Redis推荐RDB和AOF同时开启呢？

我们再深入考量一下这两种实现方式：RDB保存的是最终的数据，是一个最终的状态，而AOF保存的是到这个最终状态的过程，很明显，如果Redis有大量的修改操作，RDB中一个数据的最终态可能会通过大量的命令才能达到，这会造成AOF文件过大或者加载过慢，Redis提供了一种重写AOF的策略，来解决上述问题。

再来考虑一下AOF和RDB文件的加载过程。RDB只需要把相应的数据加载到内存中并生成相应的数据结构，而AOF文件的加载过程需要先创建一个伪客户端，然后把命令一条条发送给服务端，服务端再完整执行一遍相应的命令。根据Redis作者的测试，RDB10s~20s能加载1GB的文件，AOF的速度则是RDB速度的一半（如果做了AOF重写会更快）

因为RDB和AOF各有优缺点，所以Redis会同时开启AOF和RDB

但如果线上同时选择了这两种配置，那么重启的时候到底先加载哪个，RDB会速度更快，但是数据不是很全；如果优先加载AOF，加载速度会很慢，但是数据会比RDB中的要完整，能否结合两者的优点呢？

答案是AOF和RDB的混合持久化方案

混合持久化：

混合持久化指的是进行AOF重写是子进程将当前时间点的数据快照保存为RDB文件格式，随后父进程累计命令保存为AOF格式，最终生成的格式为：

RDB FIle

AOF file

 

加载时，首先会识别AOF文件是否以REDIS字符串（是否能存储为RDB所需要的条件验证）开头，如果是，就按RDB格式加载，加载完后继续按照AOF格式加载剩余部分