Redis基础知识

本文是来自JavaGuide面试突击版Redis部分的整理，只涉及Redis作为缓存时的相应知识点，因为其他的分布式内容我项目里面没有涉及-_-||。

1. redis 简介

简单来说 redis 就是⼀个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以读写速度⾮常快，因此 redis 被⼴泛应⽤于缓存⽅向。redis 提供了多种数据类型来⽀持不同的业务场景。

问：为什么要⽤ redis/为什么要⽤缓存？
主要从“⾼性能”和“⾼并发”这两点来看待这个问题。
⾼性能：
假如⽤户第⼀次访问数据库中的某些数据。这个过程会⽐较慢，因为是从硬盘上读取的。如果能将该⽤户访问的数据存在缓存中，这样下⼀次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。但是，如果数据库中的对应数据改变的之后，需要同步改变缓存中相应的数据（缓存与数据库的一致性）。
⾼并发：
直接操作缓存能够承受的请求是远远⼤于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样⽤户的⼀部分请求会直接到缓存这⾥⽽不⽤经过数据库。

问：为什么要⽤ redis ⽽不⽤ map/guava 做缓存?
缓存分为本地缓存和分布式缓存。以 Java 为例，使⽤⾃带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，⽣命周期随着 jvm 的销毁⽽结束，并且在多实例的情况下，每个实例都需要各⾃保存⼀份缓存，缓存不具有⼀致性。

而使⽤ redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共⽤⼀份缓存数据，缓存具有⼀致性。缺点是需要保持 redis 或 memcached服务的⾼可⽤，整个程序架构上较为复杂。

2. redis 常⻅数据结构

1. String
   常⽤命令: set,get,decr,incr,mget 等。
   String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。

2. Hash
   常⽤命令： hget,hset,hgetall 等。
   hash 是⼀个 string 类型的 field 和 value 的映射表，hash 特别适合⽤于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。 ⽐如我们可以 hash 数据结构来存储⽤户信息，商品信息等等。

3. List
   常⽤命令: lpush,rpush,lpop,rpop,lrange等
   list 的实现为⼀个双向链表，即可以⽀持反向查找和遍历，更⽅便操作，不过带来了部分额外的内存开销。另外可以通过 lrange 命令，就是从某个元素开始读取多少个元素，可以基于 list 实现分⻚查询。

4. Set
   常⽤命令： sadd,spop,smembers,sunion 等
   set 对外提供的功能与list类似是⼀个列表的功能，特殊之处在于 set 是可以⾃动排重的。

5. Sorted Set
   常⽤命令： zadd,zrange,zrem,zcard等
   和set相⽐，sorted set增加了⼀个权重参数score，使得集合中的元素能够按score进⾏有序排列。

3. redis 设置过期时间

对存储在 redis 数据库中的值可以设置⼀个过期时间。作为⼀个缓存数据库，这是⾮常实⽤的。如我们⼀般项⽬中的⼀些登录信息，都是有时间限制的，按照传统的数据库处理⽅式，⼀般都是⾃⼰判断过期，这样⽆疑会严重影响项⽬性能。

我们 set key 的时候，都可以给其⼀个 expire time，就是过期时间，通过过期时间我们可以指定这个key 可以存活的时间。

EXPIRE key seconds         指定键的过期时间
PEXPIRE key milliseconds   设置键以毫秒为单位到期

如果假设你设置了⼀批 key 只能存活1个⼩时，那么接下来1⼩时后，redis是怎么对这批key进⾏删除的？

定期删除+惰性删除。
定期删除：redis默认是每隔 100ms 就随机抽取⼀些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这⾥是随机抽取的。为什么要随机呢？你想⼀想假如 redis 存了⼏⼗万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很⼤的负载！
惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存⾥，除⾮你的系统去查⼀下那个 key，才会被redis给删除掉。这就是所谓的惰性删除。

但是仅仅通过设置过期时间还是有问题的。我们想⼀下：如果定期删除漏掉了很多过期 key，然后你也没及时去查，也就没⾛惰性删除，就会使得⼤量过期key堆积在内存⾥，导致redis内存块耗尽了。怎么解决这个问题呢？
redis 内存淘汰机制。

如何查询当前的过期时间：
TTL key：
获取key的过期时间。如果key存在过期时间，返回剩余生存时间(秒)；如果key是永久的，返回-1；如果key不存在或者已过期，返回-2。
PTTL key：
获取key的过期时间。如果key存在过期时间，返回剩余生存时间(毫秒)；如果key是永久的，返回-1；如果key不存在或者已过期，返回-2。

4. redis 内存淘汰机制(MySQL⾥有2000w数据，Redis中只存20w的数据，如何保证Redis中的数据都是热点数据?)

redis一开始提供 6种数据淘汰策略：

1. no-eviction：禁⽌驱逐数据，也就是说当内存不⾜以容纳新写⼊数据时，新写⼊操作会报错。（默认）
2. allkeys-lru：在主键空间中，优先移除最近未使用的key。
3. volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key。
4. allkeys-random：在主键空间中，随机移除某个key。
5. volatile-random：在设置了过期时间的键空间中，随机移除某个key。
6. volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除

4.0版本后增加以下两种：

7. volatile-lfu：在设置了过期时间的键空间中，挑选最不经常使⽤的数据淘汰。
8. allkeys-lfu：在键空间中，移除最不经常使⽤的key。

具体应用：
redis 内存数据集大小上升到一定程度的时候，就会进行数据淘汰。通过配置redis.conf中的maxmemory这个值来开启内存淘汰功能。maxmemory为0的时候表示我们对Redis的内存使用没有限制。

# maxmemory <bytes>

然后，根据根据应用场景，选择淘汰策略maxmemory-policy，默认的策略为noeviction策略：

# maxmemory-policy noeviction

5. redis 持久化机制(怎么保证 redis 挂掉之后再重启数据可以进⾏恢复)

很多时候我们需要持久化数据也就是将内存中的数据写⼊到硬盘⾥⾯，⼤部分原因是为了之后重⽤数据（⽐如重启机器、机器故障之后恢复数据），或者是为了防⽌系统故障⽽将数据备份到⼀个远程位置。

Redis⽀持持久化，⽽且⽀持两种不同的持久化操作：
快照持久化（RDB），只追加⽂件（AOF）。在我们安装了redis之后，所有的配置都是在redis.conf文件中，里面保存了RDB和AOF两种持久化机制的各种配置。

1. 快照持久化（RDB）
快照持久化是Redis默认采⽤的持久化⽅式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。创建快照之后，将内存中的数据快照写入磁盘。

既然RDB机制是通过把某个时刻的所有数据生成一个快照来保存，那么就应该有一种触发机制，来实现这个过程。对于RDB来说，提供了三种机制：save、bgsave、自动化。

1、save触发方式
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。具体流程如下：

执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的数据量可能都是几万或者是几十万，这种方式显然不可取。
2、bgsave触发方式
执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应请求。
具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
具体流程如下：

3、自动触发
自动触发是由redis.conf配置文件来完成的，其中的配置可以进行设置：

save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。

默认如下配置：

save 900 1  
#在900秒(15分钟)之后，如果⾄少有1个key发⽣变化，
Redis就会⾃动触发BGSAVE命令创建快照。

save 300 10          
#在300秒(5分钟)之后，如果⾄少有10个key发⽣变化，
Redis就会⾃动触发BGSAVE命令创建快照。

save 60 10000        
#在60秒(1分钟)之后，如果⾄少有10000个key发⽣变化，
Redis就会⾃动触发BGSAVE命令创建快照。

如果不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。

RDB 的优势和劣势
①、优势
（1）RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复。
（2）生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
（3）RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
②、劣势
在快照持久化期间修改的数据不会被保存，可能丢失数据。

2. AOF（append-only file）持久化
全量备份总是耗时的，与快照持久化（RDB）相⽐，AOF持久化 的实时性更好。redis会将每一个收到的写命令都通过write函数追加到硬盘中的AOF⽂件中。通俗的理解就是日志记录。

默认情况下Redis没有开启AOF持久化，可以通过appendonly参数开启（在redis.conf中修改appendonly 的策略，将no改成yes即可）：

appendonly yes

AOF⽂件的保存位置和RDB⽂件的位置相同，都是通过dir参数设置的，默认的⽂件名是appendonly.aof。

在Redis的配置⽂件中存在三种不同的 AOF 持久化⽅式，它们分别是：

appendfsync always #每次有数据修改发⽣时都会写⼊AOF⽂件,这样会严重降低Redis的速度

appendfsync everysec #每秒钟同步⼀次，显示地将多个写命令同步到硬盘

appendfsync no #让操作系统决定何时进⾏同步

为了兼顾数据和写⼊性能，⽤户可以考虑 appendfsync everysec选项 ，让Redis每秒同步⼀次AOF⽂件，Redis性能⼏乎没受到任何影响。⽽且这样即使出现系统崩溃，⽤户最多只会丢失⼀秒之内产⽣的数据。

AOF重写
AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令，fork出一条新进程来将文件重写。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

优点
（1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。
（2）AOF日志文件没有任何磁盘寻址的开销，写入性能非常高，文件不容易破损。
（3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
（4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

缺点
（1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
（2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能消耗也还是很高的
（3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。

Redis 4.0 对于持久化机制的优化
Redis 4.0 开始⽀持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF ⽂件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF ⾥⾯的RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

6. redis 事务

Redis 事务可以一次执行多个命令， 先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令。
事务中任意命令执行失败，其余的命令依然被执行。
在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

注意：
单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。

7.缓存雪崩和缓存穿透问题解决⽅案

缓存处理流程
前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。

缓存雪崩
缓存雪崩就是指缓存由于某些原因（比如 宕机、cache服务挂了或者缓存中数据大批量到过期时间）整体crash掉了，导致大量请求到达后端数据库，从而导致数据库崩溃。

举个例子：对于系统 A，假设每天高峰期每秒 5000 个请求，本来缓存在高峰期可以扛住每秒 4000 个请求，但是缓存机器意外发生了全盘宕机。缓存挂了，此时 1 秒 5000 个请求全部落数据库，数据库必然扛不住，它会报一下警，然后就挂了。此时，如果没用什么特别的方案来处理这个故障，DBA 很着急，重启数据库，但是数据库立马又被新的流量给打死了。

缓存雪崩的事前事中事后的解决方案如下。
事前：

1. 尽量保证整个 redis 集群的⾼可⽤性。既然redis有可能挂掉，那就多增设几台redis，比如Redis Cluster，这样一台挂掉之后其他的还可以继续工作。
2. 选择合适的内存淘汰策略，而且缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。

事中：本地ehcache缓存（纯Java的进程内缓存框架），并利用hystrix进行限流并按预设进行降级操作，避免MySQL崩掉

事后：利⽤ redis 持久化机制保存的数据尽快恢复缓存，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。

用户发送一个请求，系统 A 收到请求后，先查本地 ehcache 缓存，如果没查到再查 redis。如果 ehcache 和 redis 都没有，再查数据库，将数据库中的结果，写入 ehcache 和 redis 中。

限流组件，可以设置每秒的请求，有多少能通过组件，剩余的未通过的请求，怎么办？走降级！可以返回一些默认的值，或者友情提示，或者空白的值。

好处：
数据库绝对不会死，限流组件确保了每秒只有多少个请求能通过。
只要数据库不死，就是说，对用户来说，部分请求是可以被处理的。只要有部分请求可以被处理，就意味着你的系统没死，对用户来说，可能就是点击几次刷不出来页面，但是多点几次，就可以刷出来一次。

缓存穿透
缓存穿透说简单点就是⼤量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这⼀层。
举个例⼦：某个⿊客故意制造我们缓存中不存在的 key 发起⼤量请求，导致⼤量请求落到数据库。每次你去数据库里查，也查不到。比如，数据库 id 是从 1 开始的，结果黑客发过来的请求 id 全部都是负数。这样的话，缓存中不会有，请求每次都会越过缓存，直接查询数据库。这种恶意攻击场景的缓存穿透就会直接把数据库给打死。

缓存穿透情况处理流程：

⼀般 3000 个并发请求就能打死⼤部分数据库了。有哪些解决办法？

最基本的就是⾸先做好参数校验，⼀些不合法的参数请求直接抛出异常信息返回给客户端。⽐如查询的数据库 id 不能⼩于 0等等。

1）缓存⽆效 key : 如果缓存和数据库都查不到某个 key 的数据就写⼀个对应的空值到 redis 中去并设置过期时间。这种⽅式可以解决请求的 key 变化不频繁的情况，如果⿊客恶意攻击，每次构建不同的请求key，会导致 redis 中缓存⼤量⽆效的 key 。而且即使对空值设置了过期时间，还是会存在缓存层和数据库的数据会有一段时间不一致的情况，这对于需要保持一致性的业务会有影响。
很明显，这种⽅案并不能从根本上解决此问题。如果⾮要⽤这种⽅式来解决穿透问题的话，尽量将⽆效的 key的过期时间设置短⼀点⽐如 1 分钟。

2）布隆过滤器：布隆过滤器是⼀个⾮常神奇的数据结构，通过它我们可以⾮常⽅便地判断⼀个给定数据是否存在于海量数据集合中，这种数据结构是高效且性能很好的，但缺点是具有一定的错误识别率和删除难度。并且，理论情况下，添加到集合中的元素越多，误报的可能性就越大。

布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

Redis利用布隆过滤器：把所有可能存在的请求的值都存放在布隆过滤器中，当⽤户请求过来，会先判断⽤户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会⾛下⾯的缓存+数据库流程

8.布隆过滤器原理

布隆过滤器可以用来判断一个元素是否在一个海量数据集合中，其优势是只需要占用很小的内存空间以及有着高效的查询效率。

原理：
对于布隆过滤器而言，它的本质是一个位数组：位数组就是数组的每个元素都只占用 1 bit ，并且每个元素只能是 0 或者 1。此外，还有 K 个哈希函数。

1. 一开始，布隆过滤器的位数组的所有位都初始化为 0。
2. 之后将需要的元素加入布隆过滤器中，每次加入元素时，都会进行如下操作：使用 K 个哈希函数对当前的元素值进行 K 次计算，得到 K 个哈希值。然后根据得到的哈希值，在位数组中把对应下标的值置为 1。
3. 当要判断一个元素是否在布隆过滤器中时，首先对该元素进行K次哈希计算，得到K个哈希值，然后根据得到的哈希值，依次判断位数组中对应下标的值是否为1，如果值都为 1，那么说明这个元素在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。

布隆过滤器的缺陷：
数组的容量即使再大，也是有限的。那么随着布隆过滤器内插入元素的增加，位数组中被置为 1 的位置越来越多，这就会造成一种情况：当一个不在布隆过滤器中的元素，经过K次哈希计算，并根据得到的K个哈希值，依次判断位数组中对应下标的值均为1，但这些位置是因为之前其它元素的插入操作而被置为 1 的。这就是布隆过滤器的一个缺陷：存在误判，即布隆过滤器说某个元素存在，可能会被误判。
但是，布隆过滤器说某个元素不在，那么一定不在。

解决方法：
布隆过滤器存在一定的误识别率。常见的补救办法是建立白名单，存储那些可能被误判的元素。

使用场景：
布隆过滤器的最大的用处就是，能够迅速判断一个元素是否在一个海量数据集合中。因此它有如下三个使用场景:
1.网页爬虫对 URL 的去重，避免爬取相同的 URL 地址。
2.进行垃圾邮件过滤：反垃圾邮件，从数十亿个垃圾邮件列表中判断某邮箱是否垃圾邮箱（同理，垃圾短信）。
3.有的黑客为了让服务宕机，他们会构建大量不存在于缓存中的 key 向服务器发起请求，在数据量足够大的情况下，频繁的数据库查询可能导致 DB 挂掉。布隆过滤器很好的解决了缓存击穿的问题。

具体实现：

1. 利用Google开源的 Guava中自带的布隆过滤器
使用时需要在项目中引入 Guava的依赖。通过使用BloomFilter.create()命令即可创建一个布隆过滤器，并可以指定其容量和误判概率等参数。如果误判概率设为0.01，则当mightContain() 方法返回true时，我们可以99％确定该元素在过滤器中，当过滤器返回false时，我们可以100％确定该元素不存在于过滤器中。

// 创建布隆过滤器对象
BloomFilter<Integer> filter = BloomFilter.create(
        Funnels.integerFunnel(),
        1500,
        0.01);
// 将元素添加进布隆过滤器
filter.put(1);
filter.put(2);
// 判断指定元素是否存在
System.out.println(filter.mightContain(1));
System.out.println(filter.mightContain(2));

Guava 提供的布隆过滤器的实现很方便，其缺点就是只能单机使用（另外，容量扩展也不容易），而现在互联网一般都是分布式的场景。为了解决这个问题，我们就需要用到 Redis 中的布隆过滤器了。

2.给Redis安装Bloom Filter
Redis 4.0 之后有了 Module 功能，可以让 Redis 使用外部模块扩展其功能 。布隆过滤器就是其中的 Module。我使用的是官网推荐的RedisBloom 作为 Redis 布隆过滤器的 Module。
下载并编译模块之后，修改redis.conf文件，增加redisbloom相关的配置，即可实现RedisBloom每次启动自加载：

loadmodule /soft/redisbloom/redisbloom.so

在Redis里使用Bloom Filter常用指令有：bf.reserve，bf.add，bf.exists等

1. bf.reserve {key} {error_rate} {size}
   bf.reserve userid 0.01 100000：创建一个空的布隆过滤器，并设置一个期望的错误率和初始大小。{error_rate}过滤器的错误率在0-1之间，如果要设置0.1%，则应该是0.001。该数值越接近0，内存消耗越大，对cpu利用率越高。
2. bf.add ：将元素添加到布隆过滤器中，如果该过滤器尚不存在，则创建该过滤器。bf.madd: 允许多个输入。
   bf.add userid ‘181920’：往过滤器中添加元素。如果key不存在，过滤器会自动创建。
3. bf.exists {key} {item} 确定元素是否在布隆过滤器中存在，bf.mexists ： 确定一个或者多个元素是否在布隆过滤器中存在
   bf.exists userid ‘101310299’：判断指定key的value是否在bloomfilter里存在。存在：返回1，不存在：返回0。

Redis布隆过滤器与springboot的整合
仿照github上的教程，编写两个lua脚本：
a脚本实现添加数据到指定名称的布隆过滤器，b脚本实现从指定名称的布隆过滤器获取key是否存在。
从而实现springboot和布隆过滤器的整合。

9. 如何解决 Redis 的并发竞争 Key 问题

所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对⼀个 key 进⾏操作，但是最后执⾏的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

推荐⼀种⽅案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使⽤分布式锁，这样会影响性能）

10. 如何保证缓存与数据库双写时的数据⼀致性?

最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。
读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。
更新的时候，先更新数据库，成功后，再让删除相应缓存。

问：为什么是删除缓存，而不是更新缓存？
（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用缓存更新方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。

问：如果先删除缓存，再更新数据库，会有什么问题？
如果先删缓存，再更新数据库，首先会出现下面的问题：
有一个请求A进行更新操作，同时，另一个请求B进行查询操作。那么会出现如下情形:
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
那么，如何解决呢？采用延时双删策略：
伪代码如下
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(1000);
redis.delKey(key);
}
转化为中文描述就是：
（1）先删除缓存；
（2）再更新数据库（写操作）（这两步和原来一样）；
（3）休眠1秒，再次删除缓存；
这么做，可以将1秒内所造成的缓存脏数据，再次删除。

那么，这个1秒怎么确定的，具体该休眠多久呢？
针对上面的情形，读者应该自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

如果你用了mysql的读写分离架构怎么办？
在这种情况下，造成数据不一致的原因如下，还是两个请求，一个请求A进行更新操作，另一个请求B进行查询操作。
（1）请求A进行写操作，删除缓存
（2）请求A将数据写入数据库了，
（3）请求B查询缓存发现，缓存没有值
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
（5）请求B将旧值写入缓存
（6）数据库完成主从同步，从库变为新值

上述情形，就是数据不一致的原因。还是使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。

采用这种同步淘汰策略，吞吐量降低怎么办？
那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后再返回了，加大了吞吐量。

第二次删除,如果删除失败怎么办？
这是个非常好的问题，因为第二次删除失败，就会出现如下情形。还是有两个请求，一个请求A进行更新操作，另一个请求B进行查询操作，为了方便，假设是单库：
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
（6）请求A试图去删除请求B写入对缓存值，结果失败了。
这也就是说。如果第二次删除缓存失败，会再次出现缓存和数据库不一致的问题。

上述问题也是先进行更新数据库然后删除缓存时会出现的问题，下面介绍一下解决方案。

首先来介绍一下先更新数据库再删除缓存的优点，由于数据库的读操作的速度远快于写操作的，因此不像上面的先删除缓存再更新数据库那样容易出现并发问题。

但是先更新数据库再删除缓存还是会有其他问题的，如果缓存删除失败了怎么办？如果先更新数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。这也是上面延迟双删策略中第二次删除失败会导致的问题。

如何解决？提供一个保障的重试机制即可，继续重试删除操作，直到成功。
这里给出两套方案作为参考。
方案一：
（1）更新数据库数据；
（2）缓存因为种种问题删除失败
（3）将需要删除的key发送至消息队列
（4）自己消费消息，获得需要删除的key
（5）继续重试删除操作，直到成功

然而，该方案有一个缺点，对业务线代码造成大量的侵入。于是有了方案二，在方案二中，启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
方案二：

流程如下图所示：
（1）更新数据库数据
（2）数据库会将操作信息写入binlog日志当中
（3）订阅程序提取出所需要的数据以及key
（4）另起一段非业务代码，获得该信息
（5）尝试删除缓存操作，发现删除失败
（6）将这些信息发送至消息队列
（7）重新从消息队列中获得该数据，重试操作。
备注说明：上述的订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。另外，重试机制，可以采用消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路。

此外，如果高并发下需要保证绝对的一致时，可以使用内存队列做异步串行化（即读请求和写请求串行化，串到一个内存队列里去）。串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低。

11.Redis在SpringBoot中的使用

1.修改 Application, 做如下几个改动：

1. 增加注解： @EnableCaching 用于启动缓存
2. 检查端口6379是否启动。 6379 就是 Redis 服务器使用的端口。如果未启动，那么就会退出 springboot。

@SpringBootApplication
@EnableCaching
public class Application {
    static {
        PortUtil.checkPort(6379,"Redis 服务端",true);
    }
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

3. 在配置文件application.properties里追加 redis的配置
   当前保持默认也行。
4. Service层 缓存配置
   Redis的缓存，一般都会在 Service 这一层上面做，拿CategoryService 来讲解。

首先给CategoryService加上注解@CacheConfig，写明cahceNames属性，表示当前类文件中缓存里的keys，都存储在 “categories” 中

@CacheConfig(cacheNames="categories")

对于查询get方法，使用@Cacheable注解，
第一次访问的时候， redis 是不会有数据的，所以就会通过 jpa 到数据库里去取出来，一旦取出来之后，就会放在 redis里。第二次访问的时候，redis 就有数据了，就不会从数据库里获取了。

@Cacheable(key="'categories-one-'+ #p0")
public Category get(int id) {
	Category c= categoryDAO.findOne(id);
	return c;
}

增加，删除和修改方法使用注解@CacheEvict。

	@CacheEvict(allEntries=true)
//	@CachePut(key="'category-one-'+ #p0")
	public void add(Category bean) {
		categoryDAO.save(bean);
	}
	@CacheEvict(allEntries=true)
//	@CacheEvict(key="'category-one-'+ #p0")
	public void delete(int id) {
		categoryDAO.delete(id);
	}
	@CacheEvict(allEntries=true)
//	@CachePut(key="'category-one-'+ #p0")
	public void update(Category bean) {
		categoryDAO.save(bean);
	}

全部的Service层代码如下：

@Service
@CacheConfig(cacheNames="categories")
public class CategoryService {
    @Autowired CategoryDAO categoryDAO;
 
    @CacheEvict(allEntries=true)
//  @CachePut(key="'category-one-'+ #p0")
    public void add(Category bean) {
        categoryDAO.save(bean);
    }
 
    @CacheEvict(allEntries=true)
//  @CacheEvict(key="'category-one-'+ #p0")
    public void delete(int id) {
        categoryDAO.delete(id);
    }
 
    @Cacheable(key="'categories-one-'+ #p0")
    public Category get(int id) {
        Category c= categoryDAO.findOne(id);
        return c;
    }
 
    @CacheEvict(allEntries=true)
//  @CachePut(key="'category-one-'+ #p0")
    public void update(Category bean) {
        categoryDAO.save(bean);
    }
 
    @Cacheable(key="'categories-all'")
    public List<Category> list() {
        Sort sort = new Sort(Sort.Direction.DESC, "id");
        return categoryDAO.findAll(sort);
    }
}

补充：@CacheEvict的用法
@CacheEvict是用来标注在需要清除缓存元素的方法或类上的。当标记在一个类上时表示其中所有的方法的执行都会触发缓存的清除操作，使用该注解标志的方法，会清空指定的缓存。一般用在更新或者删除方法上，如果方法因为抛出异常而未能成功返回时也不会触发清除操作。
常用属性：

12.Redis如何生成全局 id

使用redis的RedisAtomicLong生成自增的ID值。

13 MyBatis #{}和${}的区别

${} 是 Properties ⽂件中的变量占位符，它可以⽤于标签属性值和 sql 内部，属于静态⽂本替换，⽐如${driver}会被静态替换为 com.mysql.jdbc.Driver 。
#{} 是 sql 的参数占位符，Mybatis 会将 sql 中的 #{} 替换为?号，在 sql 执⾏前会使⽤PreparedStatement 的参数设置⽅法，按序给 sql 的?号占位符设置参数值，⽐如ps.setInt(0, parameterValue)， #{item.name} 的取值⽅式为使⽤反射从参数对象中获取item 对象的 name 属性值，相当于 param.getItem().getName() 。