redis 发布订阅，redis 事务，持久化

redis的发布订阅以及持久化

redis 发布订阅

redis 发布订阅是一种消息通信模式：发送者发送消息，订阅者接收消息，redis 客户端可以订阅任意数量的频道

subscribe channel1 订阅通道 客户端1
publish channel1 hello 给订阅的通道发送消息 客户端2

jedis操作redis

/**引入依赖即可*/
><dependency>
>     <groupId>redis.clients</groupId>
>     <artifactId>jedis</artifactId>
>     <version>4.0.1</version> 
> </dependency>
> 
> Jedis jedis=new Jedis("121.59.09.158",6379); String lihaiqiao =
> jedis.set("liqiao", "123"); System.out.println(lihaiqiao);
> 
> springboot整合redis
> 
> <dependency>
>     <groupId>org.springframework.boot</groupId>
>     <artifactId>spring-boot-starter-test</artifactId>
>     <scope>test</scope> </dependency> <dependency>
>     <groupId>org.springframework.boot</groupId>
>     <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency>
>     <groupId>org.springframework.boot</groupId>
>     <artifactId>spring-boot-starter-data-redis</artifactId> 
> </dependency> 
> <dependency>
>     <groupId>org.apache.commons</groupId>
>     <artifactId>commons-pool2</artifactId> 
> </dependency>
> 
> @Autowired 
> private  RedisTemplate<String,String> redisTemplate;
> 
> 
> @Test 
> public void redisTest1(){
>     redisTemplate.opsForValue().set("zhangshan","1231231");
>     System.out.println(redisTemplate.opsForValue().get("zhangshan")); 
>     }

redis 事务

redis事务是一个单独的隔离操作：事务中的所有命令都会序列化，按顺序的执行，事务在执行的过程中，不会被其他客户端发送过来的命令请求所打断
redis事务的主要作用就是串联多个命令防止别的命令插队

命令
Multi （开启事务）
discard（拒绝组队不执行命令）
exec（提交事务类似 ）
从输入multi命令开始，输入的命令都会依次进入命令队列中，但是不会执行，直到输入Exec后，redis会将之前的命令依次执行。组队偶成中可以通过discard来放弃组队


1.组队中某个命令出现报错，执行时整个的所有的队列都会被取消
2.如果执行阶段某个命令报错，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚 组队过程中语法错误 在执行的时候都不会成功，如果组队成功则只有错的那条不会成功，其他成功

redis的持久化

RDB 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是快照，它在回复时时将快照文件读到内存里 备份是如何执行的？
redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，持久化过程就结束了，再用这个临时文件替换上次持久化好的文件整个过程中，主进程不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效，RDB的缺点是最后一次持久化的数据可能丢失

fork
fork的作用是复制一个与当前进程一样的进程，新进程的所有数据数值都和原进程一致但是是一个全新的进程，并且作为原进程的子进程
在linux程序中，fork()会产生一个和父进程完成相同的子进程，但子进程在此后多会exec系统调用，处于效率考虑，linux引入写时复制技术
一般情况父进程和子进程会公用同一段物理内存，只是进程空间的各段内容要发生变化时才会将父进程的内容复制一份给子进程

dunp.rdb文件

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

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

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

AOF默认不开启 可以在redis.conf中配置文件名称，默认appendonly.aof，AOF文件保存的路径和RDB一样

AOF和RDB同时开启？
系统默认取AOF的数据（数据不会存在丢失）

AOF 启动/修复/恢复
1.AOF的备份 机制和性能虽然和RDB不同，但是备份和恢复的操作时一样的，都是拷贝备份文件，需要恢复的时候在拷贝到redis工作目录下，启动系统即加载。
正常恢复 修改默认的appendonly no 改为yes 将有数据的aof文件复制一份保存到对应目录 恢复：重启redis然后重新加载；
异常恢复 修改默认的appendlnly no 改为yes 如遇到AOF文件损坏，通过bin目录下 redis-check-aof --fix appendonly.aof 进行修复 备份被写坏的AOF文件 恢复：重启redis，然后重新加载

AOF 同步频率设置 appendfsync always (始终同步，每次redis的
写入都会立刻记入日志-------性能较差，单数数据的完整性比较好) appendfsync everysec
(每秒同步，每秒记入日志一次，如果宕机本秒的数据可能丢失) appendfsync no
（redis不主动进行同步，把同步时机交给操作系统）

rewrite 压缩
1.AOF采用文件追加方式,文件会越来越大为避兔出现此种情况,新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis 就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
2.原理
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。达到这个值开始重写。

重写流程
( 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重写。

优势

1.备份机制更稳健，丢失数据概率更低
2.可读的日志文件，通过操作AOF文件，可以处理误操作、

劣势

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

总结 RDB和AOF用哪个好
1.官方推荐两个都启用。
2.如果对数据不敏感,可以选单独用RDB。
3.不建议单独用AOF ,因为可能会出现Bug。
4.如果只是做纯内存缓存，可以都不用。

官方描述

●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这条规则。