本文主要是介绍IV-day17-Redis&Aop技术整合/Redis数据持久化,Redis事务处理，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

1.@EnableCaching注解，@Cacheable注解，@CachePut注解

1.@EnableCaching
//开启AOP方式的缓存应用
2.@Cacheable
	/**
     * 由此注解描述的方法为切入点方法,此方法执行时,底层会通过AOP机制
     * 先从缓存取数据,缓存有则直接返回,缓存没有则查数据,最后将查询的数据
     * 还会向redis存储一份
     * @param id
     * @return
     */
    @Cacheable(value = "menuCache",key = "#id")//使用方法参数的id作为key
    @Override
    public Menu selectById(Long id) {
        log.info("Get Data from Database");
        return menuMapper.selectById(id);
    }
3.@CachePut
	/**
     * @CachePut 注解描述的方法同样是要给缓存切入点方法
     * 主要用于更新缓存中的数据
     * @param menu
     * @return
     */
    @CachePut(value = "menuCache",key = "#menu.id")//value是方法的返回值
    @Override
    public Menu updateMenu(Menu menu) {
        menuMapper.updateById(menu);
        return menu;
    }

2.Redis数据持久化

2.1持久化方式

Redis中为了保证在系统宕机(类似进程被杀死)情况下，能更快的进行故障恢复，设计了两种数据持久化方案，分别为rdb和aof方式。

2.2配置准备工作

redis.io官方：

https://redis.io/topics/config/

2.3Rdb方式持久化

Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式，系统启动时会自动开启这种方式的持久化机制。
实验1:

在redis中保存几条数据，然后执行shutdown关闭redis,然后再重启redis，看看刚才插入的数据是否还在？假如数据还在，为什么？
因为,通过redis-cli
shutdown这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照。

实验2：

在redis中再保存几条新的数据，用kill -9粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景？
这次就发现，redis进程异常被杀掉，几条最新的数据就丢失了。

实验3：

手动调用save(同步保存)或者bgsave(异步保存)执行rdb快照生成.然后杀掉redis进程,再重启检测是否还有刚刚保存的数据。

2.4Aof方式数据持久化

Aof方式是通过记录写操作日志的方式,记录redis数据的一种持久化机制,这个机制默认是关闭的。
AOF方式持久化实践：

第一：打开AOF的开关，启用AOF持久化 第二：写入一些数据，观察AOF文件（appendonly.aof）中的日志内容 第三：kill
-9杀掉redis进程，重新启动redis进程，发现数据被恢复回来了，就是从AOF文件中恢复回来的，redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中的数据恢复回来。

3.Redis事务

事务是一个业务,也可以看成是一个逻辑工作单元,是为了保证业务的完整,数据的正确而推出的一种控制机制,原则上来讲,事务必须要满足ACID四个特性(原子性,一致性,隔离性,持久性),在多个事务
在并发执行,为更好保证事务的四个特性的实现,通常会对事务加锁,Redis为了性能,采用了乐观锁方式进行事务控制，它使用watch命令监视给定的key，当exec（提交事务）的时候,如果监视的key从调用watch后发生过变化，则整个事务会失败。也可以调用watch多次监视多个key。注意watch的key是对整个连接有效的，如果连接断开，监视和事务都会被自动清除。当然exec，discard，unwatch命令都会清除连接中的所有监视。
Redis保证一个事务中的所有命令要么都执行，要么都不执行(原子性)。如果在发送EXEC命令前客户端断线了，则Redis会清空事务队列，事务中的所有命令都不会执行。而一旦客户端发送了EXEC命令，所有的命令就都会被执行，即使此后客户端断线也没关系，因为Redis中已经记录了所有要执行的命令。

3.1基本指令

multi：开启事务
exec：提交事务
discard：取消事务
redis事务太简单，没有回滚，只有取消。
当出现错误指令时，事务也会自动取消。
watch：监控，如果监控的值发生变化，则提交事务时会失败 /watch ticket 乐观锁，对值进行观察，改变则事务失败。
unwatch：取消监控

4.总结

Redis中的save和bgsave有什么不同？

Redis Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis。
进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

RDB持久化机制有哪些优点？

第一：RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据。
第二：RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。
第三：相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

RDB持久化机制有哪些缺点？

假如redis故障时，要尽可能少的丢失数据，那么RDB方式不太好，它都是每隔5分钟或更长时间做一次快照，这个时候一旦redis进程宕机，那么会丢失最近几分钟的数据。

如何理解AOF方式中的rewrite操作？

redis中的可以存储的数据是有限的，很多数据可能会自动过期，也可能会被用户删除或被redis用缓存清除的算法清理掉。也就是说redis中的数据会不断淘汰掉旧的，只有一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，最好导致文件很大。
所以,AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，但redis内存现在10万数据;
于是，基于内存中当前的10万数据构建一套最新的日志，然后到AOF文件中;
覆盖之前的老日志，从而，确保AOF日志文件不会过大，保持跟redis内存数据量一致。

AOF持久化机制有哪些优点？

第一：AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据.
第二：AOF日志文件通常以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，并且文件不容易破损，即使文件尾部破损，也很容易修复。
第三：AOF日志文件过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite
log的时候，会对其中的日志进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
第四：AOF日志文件的命令通过易读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

AOF持久化机制有哪些缺点？

第一：对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。
第二：AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
第三：AOF这种基于命令日志方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

如何选择redis的持久化方式？

第一：不要仅仅使用RDB，因为那样会导致你丢失很多数据。
第二：也不要仅仅使用AOF，因为AOF做冷备没有RDB做冷备进行数据恢复的速度快,并且RDB简单粗暴的数据快照方式更加健壮。
第三：综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备。

为什么AOP方式应用redis？

优势-简单，劣势-不灵活。

Spring工程中CacheManager作用是什么？

管理缓存，定义缓存配置及实现，也可以定制。

为什么要持久化？

更好的保证数据的可靠性，防止数据断电丢失。

生产环境下如何应用Rdb和Aof的持久化方式？

两种都要配置。

这篇关于IV-day17-Redis&Aop技术整合/Redis数据持久化,Redis事务处理的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！