Redis简单介绍

详解 Redis

功能

• Bitmap 位图是支持按 bit 位来存储信息，可以用来实现 BloomFilter；HyperLogLog 提供不精确的去重计数功能，比较适合用来做大规模数据的去重统计，例如统计 UV；Geospatial 可以用来保存地理位置，并作位置距离计算或者根据半径计算位置等。这三个其实也可以算作一种数据结构。
• pub/sub 功能是订阅发布功能，可以用作简单的消息队列。
• Pipeline可以批量执行一组指令，一次性返回全部结果，可以减少频繁的请求应答。
• Redis 支持提交 Lua 脚本来执行一系列的功能。
• 最后一个功能是事务，但 Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。

持久化

Redis 提供了 RDB 和 AOF 两种持久化方式，RDB 是把内存中的数据集以快照形式写入磁盘，实际操作是通过 fork 子进程执行，采用二进制压缩存储；AOF 是以文本日志的形式记录 Redis 处理的每一个写入或删除操作。

RDB 把整个 Redis 的数据保存在单一文件中，比较适合用来做灾备，但缺点是快照保存完成之前如果宕机，这段时间的数据将会丢失，另外保存快照时可能导致服务短时间不可用。

AOF 对日志文件的写入操作使用的追加模式，有灵活的同步策略，支持每秒同步、每次修改同步和不同步，缺点就是相同规模的数据集，AOF 要大于 RDB，AOF 在运行效率上往往会慢于 RDB。

高可用

来看 Redis 的高可用。Redis 支持主从同步，提供 Cluster 集群部署模式，通过 Sentine l哨兵来监控 Redis 主服务器的状态。当主挂掉时，在从节点中根据一定策略选出新主，并调整其他从 slaveof 到新主。

选主的策略简单来说有三个：

• slave 的 priority 设置的越低，优先级越高；
• 同等情况下，slave 复制的数据越多优先级越高；
• 相同的条件下 runid 越小越容易被选中。

在 Redis 集群中，sentinel 也会进行多实例部署，sentinel 之间通过 Raft 协议来保证自身的高可用。

Redis Cluster 使用分片机制，在内部分为 16384 个 slot 插槽，分布在所有 master 节点上，每个 master 节点负责一部分 slot。数据操作时按 key 做 CRC16 来计算在哪个 slot，由哪个 master 进行处理。数据的冗余是通过 slave 节点来保障。

key 失效机制

Redis 的 key 可以设置过期时间，过期后 Redis 采用主动和被动结合的失效机制，一个是和 MC 一样在访问时触发被动删除，另一种是定期的主动删除。

淘汰策略

Redis 提供了6种淘汰策略，一类是只针对设置了失效期的 key 做 LRU、最小生存时间和随机剔除；另一类是针对所有 key 做 LRU、随机剔除。当然，也可以设置不剔除，容量满时再存储对象会返回异常，但是已存在的 key 还可以继续读取。

数据结构

Redis 内部使用字典来存储不同类型的数据，如下图中的 dictht，字典由一组 dictEntry 组成，其中包括了指向 key 和 value 的指针以及指向下一个 dictEntry 的指针。

在 Redis 中，所有的对象都被封装成了 redisObject，如图中浅绿的模块。redisObject 包括了对象的类型，就是 Redis 支持的 string、hash、list、set 和 sorted set 5种类型。另外 redisObject 还包括了具体对象的存储方式，如图最右边的虚线标出的模块内的几种类型。

下面结合类型来介绍具体的数据存储方式。

• string 类型是 Redis 中最常使用的类型，内部的实现是通过 SDS（Simple Dynamic String ）来存储的。SDS 类似于 Java 中的 ArrayList，可以通过预分配冗余空间的方式来减少内存的频繁分配。
• list 类型，有 ziplist 压缩列表和 linkedlist 双链表实现。ziplist 是存储在一段连续的内存上，存储效率高，但是它不利于修改操作，适用于数据较少的情况；linkedlist 在插入节点上复杂度很低，但它的内存开销很大，每个节点的地址不连续，容易产生内存碎片。此外在 3.2 版本后增加了 quicklist，结合了两者的优点，quicklist 本身是一个双向无环链表，它的每一个节点都是一个 ziplist。
• hash 类型在 Redis 中有 ziplist 和 hashtable 两种实现。当 Hash 表中所有的 key 和 value 字符串长度都小于 64 字节且键值对数量小于 512 个时，使用压缩表来节省空间；超过时，转为使用 hashtable。
• set 类型的内部实现可以是 intset 或者 hashtable，当集合中元素小于 512 且所有的数据都是数值类型时，才会使用 intset，否则会使用 hashtable。 
• sorted set 是有序集合，有序集合的实现可以是 ziplist 或者是 skiplist 跳表。有序集合的编码转换条件与 hash 和 list 有些不同，当有序集合中元素数量小于 128 个并且所有元素长度都小于 64 字节时会使用 ziplist，否则会转换成 skiplist。

提示：Redis 的内存分配是使用 jemalloc 进行分配。jemalloc 将内存空间划分为小、大、巨大三个范围，并在范围中划分了小的内存块，当存储数据时，选择大小最合适的内存块进行分配，有利于减小内存碎片。

缓存常见问题

对使用缓存时常遇到几个问题，整理出一个表格，如下图所示。

缓存更新方式

第一个问题是缓存更新方式，这是决定在使用缓存时就该考虑的问题。 

• 缓存的数据在数据源发生变更时需要对缓存进行更新，数据源可能是 DB，也可能是远程服务。更新的方式可以是主动更新。数据源是 DB 时，可以在更新完 DB 后就直接更新缓存。
• 当数据源不是 DB 而是其他远程服务，可能无法及时主动感知数据变更，这种情况下一般会选择对缓存数据设置失效期，也就是数据不一致的最大容忍时间。
• 这种场景下，可以选择失效更新，key 不存在或失效时先请求数据源获取最新数据，然后再次缓存，并更新失效期。
• 但这样做有个问题，如果依赖的远程服务在更新时出现异常，则会导致数据不可用。改进的办法是异步更新，就是当失效时先不清除数据，继续使用旧的数据，然后由异步线程去执行更新任务。这样就避免了失效瞬间的空窗期。另外还有一种纯异步更新方式，定时对数据进行分批更新。实际使用时可以根据业务场景选择更新方式。

数据不一致

第二个问题是数据不一致的问题，可以说只要使用缓存，就要考虑如何面对这个问题。缓存不一致产生的原因一般是主动更新失败，例如更新 DB 后，更新 Redis 因为网络原因请求超时；或者是异步更新失败导致。

解决的办法是，如果服务对耗时不是特别敏感可以增加重试；如果服务对耗时敏感可以通过异步补偿任务来处理失败的更新，或者短期的数据不一致不会影响业务，那么只要下次更新时可以成功，能保证最终一致性就可以。

缓存穿透

第三个问题是缓存穿透。产生这个问题的原因可能是外部的恶意攻击，例如，对用户信息进行了缓存，但恶意攻击者使用不存在的用户id频繁请求接口，导致查询缓存不命中，然后穿透 DB 查询依然不命中。这时会有大量请求穿透缓存访问到 DB。

解决的办法如下。

• 对不存在的用户，在缓存中保存一个空对象进行标记，防止相同 ID 再次访问 DB。不过有时这个方法并不能很好解决问题，可能导致缓存中存储大量无用数据。
• 使用 BloomFilter 过滤器，BloomFilter 的特点是存在性检测，如果 BloomFilter 中不存在，那么数据一定不存在；如果 BloomFilter 中存在，实际数据也有可能会不存在。非常适合解决这类的问题。

缓存击穿

第四个问题是缓存击穿，就是某个热点数据失效时，大量针对这个数据的请求会穿透到数据源。 

解决这个问题有如下办法。

• 可以使用互斥锁更新，保证同一个进程中针对同一个数据不会并发请求到 DB，减小 DB 压力。
• 使用随机退避方式，失效时随机 sleep 一个很短的时间，再次查询，如果失败再执行更新。
• 针对多个热点 key 同时失效的问题，可以在缓存时使用固定时间加上一个小的随机数，避免大量热点 key 同一时刻失效。

缓存雪崩

第五个问题是缓存雪崩。产生的原因是缓存挂掉，这时所有的请求都会穿透到 DB。

解决方法：

• 使用快速失败的熔断策略，减少 DB 瞬间压力；
• 使用主从模式和集群模式来尽量保证缓存服务的高可用。

实际场景中，这两种方法会结合使用。