Redis

1. redis 简介

redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来支持不同的业务场景。除此之外，redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

2. 为什么要用 redis、为什么要用缓存

主要从“高性能”和“高并发”这两点来看待这个问题。

1. 高性能

   假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变之后，同步改变缓存中相应的数据即可。

2. 高并发

   直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

3. 为什么要用 redis 而不用 map/guava 做缓存

缓存分为本地缓存和分布式缓存。

以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。

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

4. redis 的单线程模型

redis 内部使用文件事件处理器 file event handler，这个文件事件处理器是单线程的，所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

• 多个 socket
• IO 多路复用程序
• 文件事件分派器
• 事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件处理器进行处理。

Redis客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，所有到达服务端的命令不会立刻执行，而是会进入一个队列，然后逐个被执行，多个客户端发送的命令的执行顺序是不确定的。但是不会有两条命令被同时执行，不会产生并发问题。

为啥redis 单线程模型也能效率这么高？

1. 纯内存操作。Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，这是Redis达到每秒万级别访问的重要基础。
2. 基于非阻塞的 IO 多路复用机制。Redis使用epoll作为I/O多路复用技术的实现，再加上Redis自身的事件处理模型将epoll中的连接、读写、关闭都转换为事件，不在网络I/O上浪费过多的时间。
3. 单线程可以简化数据结构、算法的实现，单线程避免了线程切换和竞态产生（避免了加锁、解锁）的消耗。

5. redis 和 memcached 的区别

1. Redis支持更丰富的数据类型（支持更复杂的应用场景）：Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。memcache支持简单的数据类型，String。
2. Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启时可以再次加载进行使用，而Memecache把数据全部存在内存之中。
3. 集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 redis 目前是原生支持 cluster 模式的.
4. Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型。

6. redis 常见数据结构以及使用场景分析

1. String

   常用命令：set, get, decr, incr, mget 等。

   String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。

   常规key-value缓存应用：常规计数，如微博数，粉丝数等。

2. Hash

   常用命令：hget, hset, hgetall 等。

   hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，可以直接仅仅修改这个对象中的某个字段的值。如我们可以用 hash 数据结构来存储用户信息，商品信息等等。

   key=JavaUser293847
   value={
       “id”: 1,
       “name”: “SnailClimb”,
       “age”: 22,
       “location”: “Wuhan, Hubei”
   }
   

3. List

   常用命令：lpush, rpush, lpop, rpop,lrange等。

   list 就是链表，Redis list 的应用场景非常多，也是Redis最重要的数据结构之一，如微博的关注列表，粉丝列表，消息列表等功能都可以用Redis的 list 结构来实现。

   Redis list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。

   另外可以通过 lrange 命令，就是从某个元素开始读取多少个元素，可以基于 list 实现分页查询，这个很棒的一个功能。基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西（一页一页的往下走），性能高。

4. Set

   常用命令：sadd, spop, smembers, sunion 等。

   set 对外提供的功能与list类似是一个列表的功能，特殊之处在于 set 无重复数据。并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。

   如：在微博应用中，可以将一个用户所有的关注人存在一个集合中，将其所有粉丝存在一个集合。Redis可以非常方便的实现如共同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程，具体命令如下：

   sinterstore key1 key2 key3     将交集存在key1内
   

5. Sorted Set

   常用命令：zadd, zrange, zrem, zcard等。

   和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列。

   如：在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息，适合使用 Redis 中的 Sorted Set 结构进行存储。

7. redis 删除不必要的缓存数据

过期策略 + 内存淘汰机制

7.1 过期策略

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

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

redis 删除过期key的方式：定期删除 + 惰性删除。

1. 定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载。
2. 惰性删除：定期删除可能会导致很多过期 key 到了时间并没有被删除掉，所以就有了惰性删除。惰性删除不再是Redis去主动删除，而是在客户端要获取某个key时，Redis会先去检测一下这个key是否已经过期，如果没有过期则返回给客户端，如果已经过期了，那么Redis会删除这个key，不会返回给客户端。

过期键有3种删除策略：定期删除、惰性删除、定时删除。Redis不使用定时删除策略。

为什么不使用定时删除？所谓定时删除，指的是用一个定时器来负责监视key，当这个key过期就自动删除，虽然内存及时释放，但是十分消耗CPU资源。

所以惰性删除可以解决一些过期了，但没被定期删除随机抽取到的key。但有些过期的key既没有被随机抽取，也没有被客户端访问，就会一直保留在数据库，占用内存，长期下去可能会导致内存耗尽。所以Redis提供了内存淘汰机制来解决这个问题。

7.2 内存淘汰机制

redis 提供 8 种数据淘汰策略：（7，8是4.0版本后新增加的）

1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！
7. volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰
8. allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

8. redis 持久化机制

redis 持久化机制保证 redis 挂掉之后再重启数据库可以进行恢复。

很多时候，我们需要持久化数据也就是将内存中的数据写入到硬盘里面，大部分原因是为了之后重用数据（比如重启机器、机器故障之后恢复数据），或者是为了防止系统故障而将数据备份到一个远程位置。

Redis不同于Memcached的很重一点就是，Redis支持持久化，而且支持两种不同的持久化操作。

1. Redis的一种持久化方式叫快照（snapshotting，RDB）
2. 另一种方式是只追加文件（append-only file，AOF）

8.1 RDB

快照（snapshotting）持久化

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：

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命令创建快照。

8.2 AOF（append-only file）持久化

与快照持久化相比，AOF持久化的实时性更好，因此已成为主流的持久化方案。

默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：

appendonly yes

开启AOF持久化后每执行一条会更改Redis中数据的命令，Redis就会将该命令写入硬盘中的AOF文件。

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

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

appendfsync always    # 每次有数据修改发生时都会写入AOF文件，这样会严重降低Redis的速度
appendfsync everysec  # 每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no        # 让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项 ，让Redis每秒同步一次AOF文件，Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

8.3 AOF 重写

AOF重写可以产生一个新的AOF文件，这个新的AOF文件和原有的AOF文件所保存的数据库状态一样，但体积更小。

AOF重写是一个有歧义的名字，该功能是通过读取数据库中的键值对来实现的，程序无须对现有AOF文件进行任何读入、分析或者写入操作。

在执行 BGREWRITEAOF 命令时，Redis 服务器会维护一个 AOF 重写缓冲区，该缓冲区会在子进程创建新AOF文件期间，记录服务器执行的所有写命令。当子进程完成创建新AOF文件的工作之后，服务器会将重写缓冲区中的所有内容追加到新AOF文件的末尾，使得新旧两个AOF文件所保存的数据库状态一致。最后，服务器用新的AOF文件替换旧的AOF文件，以此来完成AOF文件重写操作。

8.4 Redis 4.0 对于持久化机制的优化

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

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

9. redis 事务

Redis 通过 MULTI、EXEC、WATCH 等命令来实现事务(transaction)功能。

事务提供了一种将多个命令请求打包，然后一次性、按顺序地执行多个命令的机制，并且在事务执行期间，服务器不会中断事务而改去执行其他客户端的命令请求，它会将事务中的所有命令都执行完毕，然后才去处理其他客户端的命令请求。

在传统的关系式数据库中，常常用 ACID 性质来检验事务功能的可靠性和安全性。在 Redis 中，事务总是具有原子性（Atomicity）、一致性（Consistency）和隔离性（Isolation），并且当 Redis 运行在某种特定的持久化模式下时，事务也具有持久性（Durability）。

10. 缓存雪崩和缓存穿透问题解决方案

10.1 缓存雪崩

缓存雪崩：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决办法：

1. 事前：尽量保证整个 redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
2. 事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉（因为这时是从数据库请求数据）。
3. 事后：利用 redis 持久化机制保存的数据尽快恢复缓存。

解决方法

10.2 缓存穿透

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。

举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

一般 MySQL 默认的最大连接数在 150 左右，这个可以通过 show variables like '%max_connections%';命令来查看。

最大连接数一个还只是一个指标，cpu，内存，磁盘，网络等物理条件都是其运行指标，这些指标都会限制其并发能力。所以，一般 3000 个并发请求就能打死大部分数据库了。

解决办法：

1. 最基本的就是首先做好参数校验。

   一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0，传入的邮箱格式不对的时候直接返回错误消息给客户端等等。

2. 缓存无效 key。

   如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：SET key value EX 10086。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建的不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点，比如 1 分钟。

   用代码表示如下：

   public Object getObjectInclNullById(Integer id) {
       // 从缓存中获取数据
       Object cacheValue = cache.get(id);
       // 缓存为空
       if (cacheValue == null) {
           // 从数据库中获取
           Object storageValue = storage.get(key);
           // 缓存空对象
           cache.set(key, storageValue);
           // 如果存储数据为空，需要设置一个过期时间(300秒)
           if (storageValue == null) {
               // 必须设置过期时间，否则有被攻击的风险
               cache.expire(key, 60 * 5);
           }
           return storageValue;
       }
       return cacheValue;
   }
   

3. 布隆过滤器。

   布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。

   把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。如下图所示。

   布隆过滤器过滤请求

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

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

推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。