Skip to content

Latest commit

 

History

History
227 lines (131 loc) · 8.71 KB

redis_overview.md

File metadata and controls

227 lines (131 loc) · 8.71 KB
Raw

Redis 简介

Redis 是一个使用 ANSI C编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。Redis 是目前最流行的键值对存储数据库。

Redis 优势

  • 支持的数据类型丰富
    • String
    • List
    • Hash
    • Set
    • ZSet
    • ...
  • 极其快速（10w+ QPS）
    • 基于内存
    • 数据结构简单（键值对），实现高效
    • 单进程单线程
    • I/O 多路复用，非阻塞 I/O
    • 使用 React 响应式设计模式监听 I/O 事件

Redis 常用数据类型

String 字符串

最基本的数据类型，二进制安全，底层sds。

Hash 哈希表

字符串 -> 字符串 哈希字典表。

List 列表

简单字符串列表。按字符串元素的插入顺序排序，可从两端插入元素，可存储元素上限：32 位无符号整数最大上限。

Set 集合

字符串元素构成的无序不重复集合。底层实现为哈希表，插入、查询、删除的时间复杂度均为O(1)，支持交集、并集、差集等操作。

Sorted Set 有序集合

字符串元素构成的有序不重复集合。每个元素关联一个double类型的分数，根据分数对元素进行排序（从小到大）。

Redis 数据类型底层实现

  • 简单动态字符串
  • 双向链表
  • 哈希字典
  • 跳跃表
  • 整数集合
  • 压缩列表
  • 对象

Keys 查询指令的隐患

Redis KEYS pattern指令用于查找所有符合给定模式的 key ，返回符合给定模式的 key 列表。

Keys 查询指令的隐患：

  • 一次性返回所有匹配的 key 。

  • 单线程阻塞。

  • keys 数量过多会造成 CPU、内存开销巨大，影响 Redis 服务。

解决方案：使用游标增量式迭代

SCAN cursor MATCH pattern COUNT count 初始游标为0，结束游标为0。迭代未结束时，以返回的游标作为下一次迭代的起始游标。注意，SCAN 有可能返回重复元素，需要依赖外部去重。

Redis 分布式锁

分布式锁解决的问题：

  • 互斥性
  • 安全性
  • 死锁

加锁指令（Redis 2.8 版本）：SET key value [EX seconds | PX milliseconds] [NX | XX] [KEEPTTL]

解锁指令：使用 Lua 脚本保证事务原子性。

if redis.call('get', KEYS[1]) == ARGV[1]
then
    return redis.call('del', KEYS[1])
else
    return 0
end

Redis 集群部署情况下，Redis 主从节点数据同步是异步的，如果 Redis 的 Master 节点在锁未同步到 Slave 节点的时候宕机，就会出现如下情况。

  1. 进程 A 在 master 节点获得了锁。
  2. 在锁同步到 slave 之前，master 宕机，数据还没有同步到 slave 。
  3. slave 变成了新的 master 节点。
  4. 进程 B 也得到了和进程 A 相同的锁。

在这种情况下，Redis 官方为我们提供了另一种解决方案：RedLock 红锁算法。

...

Redis 持久化

RDB 快照全量持久化

保存 Redis 某个时间点的全量数据快照。

  • SAVE指令：阻塞 Redis 服务进程，直至 RDB 快照文件创建完毕。

  • BGSAVE指令：Fork 出一个子进程创建 RDB 快照文件，不阻塞 Redis 服务进程。

缺点：

  • 内存数据的全量备份，数据量过大时会因为内存磁盘 I/O 严重影响性能。

  • 会因为 Redis 服务挂掉而丢失从当前时间至最近快照同步期间的增量数据。

AOF（Append-Only-File） 增量日志持久化

记录下除查询指令外所有变更 Redis 数据状态的指令，以指令日志的形式增量追加到 AOF 日志文件中。

RDB 与 AOF 对比

备份方式 优点 缺点
RDB 全量数据快照备份，文件体积小，恢复速度快。 无法保存最近一次快照至当前时间点的增量数据。
AOF 文件可读，增量保存指令，数据不易丢失。 文件体积大，恢复时间长。

表：RDB 与 AOF 对比表

RDB-AOF 混合持久化方式结合了 RDB 与 AOF 的优势，是目前较为推荐的 Redis 持久化方式。

Redis 数据恢复

...

Redis 过期键的删除策略

如果 Redis 的一个键是过期的，那它到了过期时间之后并不是马上就从内存中被删除，而是采用了三种不同的删除策略：

  • 立即删除

  • 惰性删除

  • 定时删除

其中第二种为被动删除，第一种和第三种为主动删除，而且第一种实时性更高。

立即删除

立即删除是指，在设置键的过期时间时，创建一个回调事件，当过期时间达到时，由时间处理器自动执行键的删除操作。

立即删除能保证内存中数据的最大新鲜度，因为它保证过期键值会在过期后马上被删除，其所占用的内存也会随之释放。 但是立即删除对 CPU 是最不友好的。

目前 Redis 事件处理器对时间事件的处理方式：无序链表，查找一个 key 的时间复杂度为O(n)，所以并不适合用来处理大量的时间事件。

惰性删除

惰性删除是指：某个键值过期后，此键值不会马上被删除，而是等到下次被使用的时候，才会被检查到过期，此时才能得到删除。 所以惰性删除的缺点很明显：浪费内存。

定期删除

从上面分析来看，立即删除会短时间内占用大量cpu，惰性删除会在一段时间内浪费内存，所以定时删除是一个折中的办法。

定期删除是指： 每隔一段时间执行一次删除操作，并通过限制删除操作执行的时长和频率，来减少删除操作对cpu的影响。 另一方面定时删除也有效的减少了因惰性删除带来的内存浪费。

Redis 会周期性的随机测试一批设置了过期时间的 key 并进行处理。测试到的已过期的 key 将被删除。 具体的算法如下:

  1. Redis 配置项hz定义了 serverCron 任务的执行周期，默认为10，即：CPU 空闲时每秒执行10次;

  2. 每次过期 key 清理的时间不超过 CPU 时间的 25%，即若 hz=1，则一次清理时间最大为 250ms，若 hz=10，则一次清理时间最大为 25ms;

  3. 清理时依次遍历所有的db;

  4. 从db中随机取20个key，判断是否过期，若过期，则逐出;

  5. 若有5个以上key过期，则重复步骤4，否则遍历下一个db;

  6. 在清理过程中，若达到了25%CPU时间，退出清理过程;

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。

由于算法采用的随机取key判断是否过期的方式，故几乎不可能清理完所有的过期Key。

调高hz参数可以提升清理的频率，过期key可以更及时的被删除，但hz太高会增加CPU时间的消耗。

数据逐出策略

在redis中，允许用户设置最大使用内存大小maxmemory（需要配合maxmemory-policy使用），设置为0表示不限制(默认配置)。 生产环境中需要设置此值，最好不超过内存60%-70%。 当redis内存数据集快到达maxmemory时，redis会实行数据淘汰策略。

Redis提供6种数据淘汰策略。 在逐出算法中，根据用户设置的逐出策略，选出待逐出的key，直到当前内存小于最大内存值为止。

可选逐出策略如下：

  • volatile-lru：从已设置过期时间的数据集中挑选最近最少使用的数据淘汰

  • volatile-ttl：从已设置过期时间的数据集中挑选将要过期的数据淘汰

  • volatile-random：从已设置过期时间的数据集中任意选择数据 淘汰

  • allkeys-lru：从数据集中挑选最近最少使用的数据淘汰

  • allkeys-random：从数据集中任意选择数据淘汰

  • no-enviction（驱逐）：禁止驱逐数据

在redis2.8中默认策略是volatile-lru

在redis3.2和redis4.0中默认策略是no-eviction

如果使用no-eviction时，当内存不足，Redis会返回OOM的错误信息

(error) OOM command not allowed when used memory > 'maxmemory'.

当cache中没有符合清除条件的key时，回收策略 volatile-lru, volatile-random 和volatile-ttl 将会和策略 no-eviction 一样直接返回错误。

选择正确的回收策略是很重要的，取决于你的应用程序的访问模式。 使用INFO命令输出来监控缓存命中和错过的次数，以调优Redis的配置。

通用规则如下：

如果期望用户请求呈现幂律分布(power-law distribution)，也就是，期望一部分子集元素被访问得远比其他元素多时，可以使用allkeys-lru策略。

如果期望是循环周期的访问，所有的键被连续扫描，或者期望请求符合平均分布(每个元素以相同的概率被访问)，可以使用allkeys-random策略。

如果期望是让redis使用缓存对象设置的TTL值，确定哪些对象应该是较好的清除候选项，可以使用volatile-ttl策略。