Redis(十一)--关于redis的一些常见问题（2）

最新推荐文章于 2021-10-07 22:12:23 发布

想飞的盗版鱼

最新推荐文章于 2021-10-07 22:12:23 发布

阅读量244

点赞数

分类专栏： Redis

本文链接：https://blog.csdn.net/chen772209/article/details/106926522

版权

Redis 专栏收录该内容

14 篇文章 3 订阅

订阅专栏

Redis(十一)–关于redis的一些常见问题（2）

这篇博士的内容主要包括：

1，watch命令和基于cas乐观锁
2，什么是缓存和数据库双写不一致，怎么解决？
3，关于持久化：
几个链接：

1，watch命令和基于cas乐观锁

Redis 通过MULTI 、EXEC、WATCH等命令来实现事物功能。事物提供了一种将多个命令请求打包，然后一次性、按顺序的执行多个命令的机制，并且在事物执行期间，服务器不会中断事物而去执行其他客户端的命令请求，它会将事物中所有的命令都执行完毕。Redis事物不支持回滚操作，所以事物队列中某个命令执行错误，整个事物也会继续执行下去（所以redis是部分支持事务的）。

在Redis的事务中，WATCH命令可用于提供CAS(check-and-set)功能。假设我们通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Null multi-bulk应答以通知调用者事务执行失败。例如，我们再次假设Redis中并未提供incr命令来完成键值的原子性递增，如果要实现该功能，我们只能自行编写相应的代码。其伪码如下：

 	  val = GET mykey
      val = val + 1
      SET mykey $val

以上代码只有在单连接的情况下才可以保证执行结果是正确的，因为如果在同一时刻有多个客户端在同时执行该段代码，那么就会出现多线程程序中经常出现的一种错误场景–竞态争用(race condition)。比如，客户端A和B都在同一时刻读取了mykey的原有值，假设该值为10，此后两个客户端又均将该值加一后set回Redis服务器，这样就会导致mykey的结果为11，而不是我们认为的12。为了解决类似的问题，我们需要借助WATCH命令的帮助，见如下代码：

	  WATCH mykey
      val = GET mykey
      val = val + 1
      MULTI
      SET mykey $val
      EXEC

和此前代码不同的是，新代码在获取mykey的值之前先通过WATCH命令监控了该键，此后又将set命令包围在事务中，这样就可以有效的保证每个连接在执行EXEC之前，如果当前连接获取的mykey的值被其它连接的客户端修改，那么当前连接的EXEC命令将执行失败。这样调用者在判断返回值后就可以获悉val是否被重新设置成功。

2，什么是缓存和数据库双写不一致，怎么解决？

解释：连续写数据库和缓存，但是操作期间，出现并发了，数据不一致了。

通常，更新缓存和数据库有以下几种顺序：

先更新数据库，再更新缓存。
先删缓存，再更新数据库。
先更新数据库，再删除缓存。

三种方式的优劣来看一下：

先更新数据库，再更新缓存：

这么做的问题是：如果A,B两个线程同时做数据更新，A先更新了数据库，B后更新数据库，则此时数据库里存的是B的数据。而更新缓存的时候，是B先更新了缓存，而A后更新了缓存，则缓存里是A的数据。这样缓存和数据库的数据也不一致。

先删缓存，再更新数据库：

这么做的问题：如果在删除缓存后，有客户端读数据，将可能读到旧数据，并有可能设置到缓存中，导致缓存中的数据一直是老数据。即，如果A,B两个线程同时要更新数据，并且A,B已经都做完了删除缓存这一步，接下来，A先更新了数据库，C线程读取数据，由于缓存没有，则查数据库，并把A更新的数据，写入了缓存，最后B更新数据库。那么缓存和数据库的值就不一致了。

有 2 种解决方案：

使用“双删”，即删更删，最后一步的删除作为异步操作，就是防止有客户端读取的时候设置了旧值。
使用队列，当这个 key 不存在时，将其放入队列，串行执行，必须等到更新数据库完毕才能读取数据。

总的来讲，比较麻烦。

先更新数据库，再删除缓存：

这个实际是常用的方案，这里介绍一下，这个叫 Cache Aside Pattern：
读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。更新的时候，先更新数据库，再删除缓存。

==>使用双删！！！记录更新期间有没有客户端读数据库，如果有，在更新完数据库之后，执行延迟删除。

3，关于持久化：

之前总结了持久化，写的是比较繁琐，在这个链接上：之前总结的关于持久化的，但是在面试时的回答应该怎样简洁又严谨的，所以参考了很多，如下：

面试官：你对redis的持久化机制了解吗？能讲一下吗？

我：redis为了保证效率，数据缓存在了内存中，但是会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件中，以保证数据的持久化。Redis的持久化策略有两种：

RDB：快照形式是直接把内存中的数据保存到一个dump的文件中，定时保存，保存策略。
AOF：把所有的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。Redis默认是快照RDB的持久化方式。

当Redis重启的时候，它会优先使用AOF文件来还原数据集，因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。你甚至可以关闭持久化功能，让数据只在服务器运行时存。

==>面试官：那你再说下RDB是怎么工作的？

我：默认Redis是会以快照"RDB"的形式将数据持久化到磁盘的一个二进制文件dump.rdb。工作原理简单说一下：当Redis需要做持久化时，Redis会fork一个子进程，子进程将数据写到磁盘上一个临时RDB文件中。当子进程完成写临时文件后，将原来的RDB替换掉，这样的好处是可以copy-on-write。

我：RDB的优点是：这种文件非常适合用于备份：比如，你可以在最近的24小时内，每小时备份一次，并且在每个月的每一天也备份一个RDB文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。RDB非常适合灾难恢复。RDB的缺点是：如果你需要尽量避免在服务器故障时丢失数据，那么RDB不合适你。

==>面试官：那你要不再说下AOF？？

我：（说就一起说下吧）使用AOF做持久化，每一个写命令都通过write函数追加到appendonly.aof中，配置方式如下：

appendfsync yes   
appendfsync always     #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略。

AOF可以做到全程持久化，只需要在配置中开启 appendonly yes。这样redis每执行一个修改数据的命令，都会把它添加到AOF文件中，当redis重启时，将会读取AOF文件进行重放，恢复到redis关闭前的最后时刻。

使用AOF的优点是会让redis变得非常耐久。可以设置不同的fsync策略，aof的默认策略是每秒钟fsync一次，在这种配置下，就算发生故障停机，也最多丢失一秒钟的数据。缺点是对于相同的数据集来说，AOF的文件体积通常要大于RDB文件的体积。根据所使用的fsync策略，AOF的速度可能会慢于RDB。

==>面试官又问：你说了这么多，那我该用哪一个呢？

我：如果你非常关心你的数据，但仍然可以承受数分钟内的数据丢失，那么可以额只使用RDB持久。AOF将Redis执行的每一条命令追加到磁盘中，处理巨大的写入会降低Redis的性能，不知道你是否可以接受。数据库备份和灾难恢复：定时生成RDB快照非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度快。当然了，redis支持同时开启RDB和AOF，系统重启后，redis会优先使用AOF来恢复数据，这样丢失的数据会最少。

参考至：java知音

下面附上几个连接：

https://mp.weixin.qq.com/s/jc-RCNSvbOykSsoKmCJLow

https://mp.weixin.qq.com/s/3KU4Bi2RChVAxcq2F-iNZA

https://mp.weixin.qq.com/s/UzYQRhwA4ubDry_Ve59Rpg

https://mp.weixin.qq.com/s/jc-RCNSvbOykSsoKmCJLow

https://mp.weixin.qq.com/s/IRuM4wP3We44JUvX2Ai5uw