redis 系列:总结篇

Redis 总体介绍

Redis 是 key-value 型的 memory 缓存中间件,相信大部分程序员都在项目中使用过它。我们也可以利用 memory 来实现缓存,只是使用 redis 的话,可以将缓存功能统一到一个组件里,方便后续重用拓展。

在底层上, redis 使用了 IO 多路复用技术,像 select、epoll 等。能较好的保障吞吐量。而且 redis 采用了单线程处理请求,避免了线程切换和锁竞争锁带来的额外消耗。

加上 redis 本身也对一些数据结构进行了优化设计,所以 redis 的性能非常好,官方给出的测试报告是单机可以支持约 10w/s 的 QPS。

Redis 通信协议

redis 是基于 tcp 长连接的 C/S 架构,采用的是文本序列化协议,并且和 http 一样,也是一个请求一个响应,客户端接到响应后再继续请求。

当然,也可以将多次请求发送过去,然后一次响应回所有执行结果,这就是所谓的管道 pipeline 技术。

redis 的文本序列化协议比较简单,通过一些规范格式去解析文本,大概如下:

  • \r\n 表示解析结束
  • 简单字符串,以“+”开头
  • 错误 Errors,以“-”开头
  • 整数类型,以“:”开头
  • 大字符串类型,以“$”开头
  • 数组类型,以“*”开头

例如,客户端向服务器发送命令:

SET key value

将被解析为:

*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n

上面的命令可以看成:

*<参数数量> CR LF

$<参数 1 的字节数量> CR LF
<参数 1 的数据> CR LF
...
$<参数 N 的字节数量> CR LF
<参数 N 的数据> CR LF

而服务器的回复则有很多类型,一般由响应数据的第一个字节决定:

状态回复(status reply)的第一个字节是 "+"

错误回复(error reply)的第一个字节是 "-"

整数回复(integer reply)的第一个字节是 ":"

批量回复(bulk reply)的第一个字节是 "$"

多条批量回复(multi bulk reply)的第一个字节是 "*"

例如,响应回来的状态回复如下:

+OK

redis 的数据结构

为了让开发者能更好的使用缓存,redis 支持了 5 种数据类型。底层是由 6 种数据结构组成的。

5 种数据类型

字符串:字符串类型是 redis 里最基础的数据类型,像 set name "hello" 操作后,在 get name 时返回的就是字符串,而且还支持了对位的操作。一般一个键能存储 512MB 的值。

hash:哈希类型主要是用来存储对象的,一般我们如果有一整个对象要存储,里面包含了多个字段,则可以使用 hash 来存储,因为 redis 提供了对这些字段的提取和设置,减少了开发者对它的二次处理,比如序列化反序列化操作。

list:一个简单的字符串列表,它允许我们从两端进行 push,pop 操作,还支持一定范围的列表元素。可以看成是双向列表。

set:集合是一个不重复值的组合,为我们提供了交集、并集、差集等操作,像找出共同好友这种需求就可以使用集合操作了。

sorted set:有序集合,在上面集合的基础上提供了排序功能,通过一个 score 属性来进行排序。

6 种底层数据结构

上面的数据类型实际上在 redis 底层是有对应的数据结构来实现的,都是 redis 经过精心设计的,能很好的提高处理效率。

简单动态字符串:redis 是使用 C 语言写的,而 C 语言里的字符串类型比较原始,比如使用 \0 作为字符结束符。所以 redis 实现了属于自己的字符串类型,比如字符串长度,预先分配内存,动态拓展等特点,也保证了处理安全性。

链表:一个双端链表,有 prev,next 指针去获取前后节点,带有 len 属性,能保存多种类型的值。

字典:通过哈希算法来实现 key-value 的映射操作,采用链地址法解决了 hash 冲突,一般时间复杂度能达到 O(1)。

跳跃表:一个多层有序链表,每一层都是对下面一层的有序提取,能降低搜索次数,有点像有序二叉树的搜索一样。

redis 系列:总结篇

整数集合:一个有序的整数集合,不会有重复元素。

压缩列表(ziplist):经过特殊编码的一块连续内存,能有效的节省内存。

快速列表:将 ziplist 组织为了一个双向链表,由于 ziplist 的内部连续性,能降低链表的内存碎片问题,提高内存利用率。

redis 的淘汰策略

redis 的淘汰策略主要是 LRU 淘汰、TTL 淘汰和随机淘汰这三种机制。

  • LRU 淘汰:最近最少使用的淘汰掉
  • TTL 淘汰:越早过期的越先淘汰掉。
  • 随机淘汰:采用随机算法淘汰掉。

由于 redis 可以对键设置过期时间,也可以不设置,所以淘汰策略还得再细分:

  • volatile-lru:针对设置了过期时间的 key 执行 LRU 淘汰策略,没有设置过期时间的不会被淘汰。
  • volatile-ttl:只针对设置了过期时间的 key 执行 TTL 淘汰。
  • volatile-random:只针对设置了过期时间的 key 执行随机淘汰。
  • allkeys-lru:针对所有键进行 LRU 淘汰策略
  • allkeys-random:针对所有键进行随机淘汰策略
  • no-enviction:不执行淘汰策略,如果有写入操作,则报错;读请求可以继续进行。

在 Redis 的配置文件 redis.conf 里我们可以进行淘汰策略的设置:

# 数据达到多大后执行淘汰策略
maxmemory 300mb

# 淘汰策略的设置
maxmemory-policy volatile-lru

Redis 使用场景

Redis 的使用场景有很多,最常用的莫过于数据缓存了。但由于它提供了多种数据类型,因此我们还可以进行其他场景的开发,比如:

  • 排行榜:前面提到过有序集合(sorted set),由于每次写入都会进行排序,而且不含重复值,所以我们可以将用户的唯一标识,比如 userId 作为 key,分数作为 score,然后就可以进行 ZADD 操作,以得到排行榜。
  • 签到:签到往往只有 2 种状态,已签到和未签到。这就跟 0 和 1 一样,所以 redis 的 setbitgetbit 这种对位的操作就适合签到场景。
  • 计数:redis 是单线程操作,这种计数功能,比如点赞数、粉丝数的操作可以交给 redis 以避免并发竞争问题。当然,也得考虑持久化问题。

关于分布式锁

有的时候我们可能会使用 redis 作为分布式锁的辅助使用,通过对 redis 操作响应以判断当前是否可以获取到锁。

不过这样的解决方案会有单节点的瓶颈,如果 redis 宕机了,就会导致锁的不可用。

有的朋友可能会说 redis 也有它的高可用方案。但实际上 redis 的高可用方案还是不适合分布式锁的应用,会有多节点同时获取到锁的风险。

如果真的需要比较严谨的分布式锁,还是得使用 zookeeperetcd等分布式协调方案,能保证强一致性。

Redis 使用注意点

缓存雪崩和穿透

Redis 通过缓存冗余的数据,为我们的程序提供了高性能的保障。但需要注意的是一旦缓存失效,那么就会有大量的请求过来,压垮系统,这就是缓存雪崩。

除了缓存雪崩,还有缓存穿透的可能。比如每次访问不一样的数据,则请求还是会落到后方。

为了防止缓存雪崩,我们可以对请求做控制,比如加入到消息队列,慢慢消化它;又或者直接开启限流功能,将流量控制在合理的范围内。

而针对缓存穿透,我们可以建立黑白名单,将一些恶意请求拎出来,然后直接拒绝掉。如果是正常的请求,那可以将筛选出来的结果也暂时缓存起来,即使得到的值是 NULL 值。

数据并发问题

由于 Redis 是以组件形式存在,所以实际上我们的程序通信可以认为是分布式的了,也就是会有缓存和后端数据一致性的问题。

常见的做法是在有新数据到来时,将缓存 key 删除掉,等待下次的查询重新填补上缓存。

之所以在更新数据时不让 Redis 也做更新动作,是为了防止多个更新动作一起发生,可能由于网络原因,导致后更新的比前面更新的先一步达到 Redis, 这样就会跟原来的流程不一样了。所以只采取了删除动作,不做其他。

不过,就算是删除 key 这种方案也有一定概率跟上面的情况一样,真的要严谨的话,一般会设置定时过期时间,让数据最多在这段时间不一致。

总结

Redis 的使用很简单,但实际上涉及的知识挺多的,特别需要注意它的并发数据一致问题。只有了解 Redis 越多,我们才能更好的掌握它,更多细节大伙可以自行深入了解,希望本文能帮到大家,谢谢!

上一篇:mysql 系列:日志


下一篇:mysql 系列:锁和它的运用