每日八股-Redis篇-05

1.Redis作为缓存，MySQL的数据如何和Redis进行同步呢？（双写一致性）

设置前提：先介绍自己的业务背景

• 背景1：我们当时是把文章的热点数据存入到了缓存中，虽然是热点数据，但是实时要求性并没有那么高，所以我们当时采用的是异步的方案同步的数据。

我们当时采用的阿里的canal组件实现数据同步：不需要更改业务代码，部署一个canal服务。canal服务把自己伪装成mysql的一个从节点，当mysql数据更新以后，canal会读取binlog数据，然后在通过canal的客户端获取到数据，更新缓存即可。

• 背景2：我们当时是把抢券的库存存入到了缓存中，这个需要实时的进行数据同步，为了保证数据的强一致，我们当时采用的是rdisson提供的读写锁来保证数据的同步。

在读的时候添加共享锁，可以保证读读不互斥，读写互斥。当我们更新数据的时候，添加排他锁，它是读写、读读都互斥，这样就能保证在写数据的同时是不会让其他线程读数据的，避免了脏数据。这里面需要注意的是读方法和写方法上需要使用同一把锁才行。

追问：那这个排他锁是如何保证读写、读读互斥的呢？

其实拍他锁底层使用也是setnx，保证了同时只能有一个线程操作锁住的方法。

追问：你听说过延时双删吗？为什么不用它呢？

延时双删，如果是写操作，我们先把缓存中的数据删除，然后更新数据库，最后再延时删除缓存中的数据，其实这个延时多久不太好确定，在延时的过程中可能会出现脏数据，并不能保证强一致性，所以没有采用它。

2.Redis作为缓存，数据的持久化是怎么做的？

在Redis中数据持久化是指将内存中的数据保存到硬盘上，以确保即使在Redis服务器重启或发生意外故障时，数据也能够被恢复。

在Redis中提供了两种数据持久化的方式：1.RDB 2.AOF

追问：这两种持久化方式有什么区别呢？

RDB（Redis Database Backup file）是一个快照文件，它是把redis内存存储的数据写到磁盘上，当redis实例宕机恢复数据的时候，方便从RDB的快照在文件中恢复数据。

AOF（Append-Only File, AOF）的含义是追加文件，当redis操作写命令的时候，都会存储到这个文件中，当redis实例宕机恢复数据的时候，会从这个文件中再次执行一边命令来恢复数据。

追问：这两种方式，哪种恢复的比较快呢？

RDB因为是二进制文件，在保存的时候体积也是比较小的，它恢复的比较快，但是它有可能会丢数据，我们通常在项目中也会使用AOF来恢复数据，虽然AOF恢复的速度慢一些，但是它丢数据的风险要小很多，在AOF文件中可以设置刷盘策略，我们当时设置的就是每秒批量写入一次命令。

补充1：RDB的执行原理

bgsave开始时会fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据并写入RDB文件，for采用的是copy-on-write技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作；

补充2；AOF配置项

配置项	刷盘时机	优点	缺点
Always	同步刷盘	可靠性高，几乎不丢数据	性能影响大
everysec	每秒刷盘	性能适中	最多丢失1秒数据
no	操作系统控制	性能最好	可靠性较差，可能丢失大量数据

当对同一个key的多次写操作，但只有最后一次写操作才有意义，通过bgrewriteaof命令，可以让aof文件执行重写功能，用最少的命令达到相同效果。

补充3：RDB与AOF对比

	RDB	AOF
持久化方式	定时对整个内存做快照	记录每一次执行的命令
数据完整性	不完整，两次备份之间会丢失	相对完整，取决于刷盘策略
文件大小	会有压缩，文件体积小	记录命令，文件体积很大
宕机恢复速度	很快	慢
数据恢复优先级	低，因为数据完整性不如AOF	高，因为数据完整性更高
系统资源占用	高，大量CPU和内存消耗	低，主要是磁盘IO资源但AOF重写时会占用大量CPU和内存资源
使用场景	可以容忍数分钟数据丢失，追求更快的启动速度	读数据安全性要求较高常见

如果您认为这篇文章对您有所帮助，希望能给我点一个免费的赞或收藏，这将是我创作的动力和鼓励！