你可能不知道的Redis用法

0. 引言

基于 Redis 丰富的数据结构，除了充当缓存层来提升查询效率以外，还能应用在很多常见的场景，比如：分布式锁，消息队列，限流等。看到这些场景你可能会有疑问，Redis 在这些领域好像并不出名啊，比如消息队列，出名的有 Rocketmq、rabbitmq 等等，很少听 Redis 来做这个场景，是不是存在什么问题？是的，下面的文字就来总结下 Redis 在这些场景的常规用法以及存在的问题。

1. 分布式锁

1.1 基本使用

分布式应用通常会遇到并发问题，逻辑上我们可以使用 setnx 指令占一个“坑”，然后处理自己的业务逻辑，最后再调用 del 指令释放“坑”。

> setnx lock.test true
OK
... do something ...
> del lock.test
(integer) 1

以上是常规使用，会有个问题，如果逻辑执行过程出现异常，导致没有执行到 del 指令，最后会陷入死锁。

1.2 过期时间

因此，更进一步的做法是拿到锁以后，再给锁设置一个过期时间，这样当过程出现异常，没有执行 del 指令，锁也会在 5s 后自动释放。

> setnx lock.test true
OK
> expire lock.test 5
... do something ...
> del lock.test
(integer) 1

1.3 原子性问题

实现以上逻辑后，仍存在问题，比如在执行 setnx 指令之后，但在 expire 指令时服务器出现异常，没有给锁设置上过期时间，锁依然会陷入死锁的状态，一直不会释放。

如何解决呢？可能你会想到事务，但在这里不行，因为 expire 是依赖于 setnx 的执行结果的，如果没有抢到锁，expire不应该被执行。事务里没有 if-else 的逻辑，要么全部执行，要么一个都不执行。

在 Redis 2.8 版本中，作者加入了 set 指令的扩展参数，使得 setnx 和expire指令可以一起执行。

> set lock.test true ex 5 nx
OK
... do something ...
> del lock.test

上面的指令就是 setnx 和expire组合在一起的原子指令。

1.4 超时问题

Redis 分布式锁并不解决锁超时的问题，所以不建议在获取分布式锁后处理耗时较长的逻辑。因为 逻辑执行得太长，锁到期自动释放，就会出现问题。

有一个稍微安全点的方案：在抢锁时，set指令的 value 参数设置为一个随机数，释放锁时先匹配 value 是否一致，再进行删除 key。这种方式可以确保当前连接的操作，不会被其他连接释放，除非是过期自动释放。

以上的匹配 value 和删除 key 不是原子性的，所以需要使用 lua 脚本，来保证连续多个指令的原子性执行。但是这也不是一个完美的方案，只是相对安全一点。它始终没能解决锁超时，其他线程“乘虚而入”的问题。

2. 消息队列

2.1 基本使用

基于 Redis 的 list 数据结构，利用 lpush 和rpop的指令组合，可以模拟队列。

使用的代码就不贴了，逻辑比较简单。下面讨论两个个问题：

1. 队列空了怎么办？
2. Redis 主动断开空闲连接怎么处理？

队列空了怎么办？
在 rpop 返回空时，sleep(1000)。可以这么做，但是这导致消费的延迟，Redis 提供了更好的方案：阻塞读（blpop/brpop），用这个指令替代逻辑里的 rpop 即可。

Redis 主动断开空闲连接怎么处理？
使用了阻塞读以后，线程会一直阻塞在那里，如果一直没有数据，这个连接就会成了闲置连接，如果时间过久，Redis 会主动断开连接，从而减少闲置资源占用。此时 blpop/brpop 会抛出异常，所以客户端需要捕捉该异常，并重试。

2.2 延迟队列

最近有个业务需求：当某个行为触发了，则在 10s 后执行一段逻辑。

看到「10s 后执行」这种典型的场景，个人的第一反应便是延迟队列。在 Redis 中，可以通过 (zset) 有序集来实现。将消息序列化为value，将执行时间作为score，然后轮询 zset 获取到期的任务进行处理。

多进程同时消费的场景中，Redis 的 zrem 方法是关键，通过 zrem 来决定唯一的属主，它的返回值决定了是否有抢到任务。

进一步优化

使用 lua 脚本，将 zrangebyscore 和zrem操作一同发送到服务端执行，可以减少争抢任务时的浪费。

2.3 消息多播

上面讨论的是 Redis 作为消息队列的基本使用，实际情况 Redis 仍有很多不足，其中一个就是它不支持多播机制。

消息多播是指生产者生产一次消息，由中间件将消息复制到多个消息队列，每个队列都有相应的消费者进行消费。

2.3.1 PubSub

为了支持多播，Redis 引入了新的模块去支持：PubSub，即发布者 / 订阅者模式。如何使用这里就不说了，文档很详细。下面总结下缺点：

1. 如果一个消费者都没有的情况下，消息会直接丢弃；
2. 如果消费者连接断开了，当它重连上以后，断开期间的消息会丢失；
3. 如果 Redis 宕机，PubSub 消息不会持久化，消息直接丢弃；

2.3.2 Stream

Redis 5.0 新增了一个数据 Stream，它是一个抢到的支持多播的可持久化消息队列，作者坦言它极大地借鉴了 Kafka 的设计。

Stream 的消费模型借鉴了 Kafka 的消费分组的概念，弥补了 PubSub 不能持久化消息的缺陷。Stream 又不同于 Kafka，Kafka 可以分 Partition，而 Stream 不行。

3. 位图

给个场景：记录用户一年的签到情况，签到为 1，没签为 0。

如果用 key/value 的方式存，一年 365 天，当用户量上亿，所需要的存储空间是惊人的。为了解决这一问题，Redis 提供了位图数据结构，上面的场景（可以引申存储 bool 型数据的其他场景），每天的签到记录只占 1 个位，365 个位对应 46 个字节，大大节省存储空间。

3.1 基本使用

位图不是特殊的数据结构，它的内容其实就是普通字符串，也就是 byte 数组。对字符串的指令 get/set，是对整个内容的操作，而对其中的位操作 Redis 提供了getbit/setbit 的指令。

字符“he”的 ASCII 码与位的对应关系：

通过位操作设置“he”字符：

3.2 统计与查找

除了设置和获取位图的值以外，Redis 还提供了 bitcount 和bitpos分别用于统计和查找。比如：

1. 通过 bitcount 统计用户一共签到了多少天，可指定范围[start, end]；
2. 通过 bitpos 查找用户从那一天开始第一次签到，可指定范围[start, end]；

但遗憾的是，start 和 end 参数是字节索引，也就是指定的位范围必须是 8 的倍数，而不能任意指定。因此，我们无法直接计算某个月内用户签到了多少天。
具体操作就不说了，看文档就好。

4. 布隆过滤器

通过位图来节省空间，谈到这种方式，怎么能不谈布隆过滤器。布隆过滤器是什么，以及原理这里就不说了，只说跟 Redis 相关的。

Redis 官方提供的布隆过滤器到了 Redis 4.0 提供了插件功能才正式登出。两个基本指令，bf.add和 bf.exists。如果需要一次添加多个，就需要使用到bf.madd，同样的，一次查询多个元素是否存在，就需要用到bf.mexists 指令。

什么时候用布隆过滤器呢？
判断某个值存在，会出现误判；判断某个值不存在，100% 准确。基于这个特性去思考，就很容易找到使用场景啦，比如：

1. 爬虫系统对 URL 去重，爬过的网页不爬；
2. 邮箱系统的垃圾邮件过滤功能；
3. NoSQL 数据库，常用布隆过滤器过滤掉不存在的 row，减少数据库的 IO 请求数量。

如何控制低误判率？
Redis 中提供了 bf.reserve 指令，可设置 key，error_rate 和 initial_size，设置的 error_rate 越低，需要的空间越大。

5. 附近的店 / 人 / 车

Redis 3.2 版本以后增加了地理位置 Geo 模块，可以实现类似摩拜单车的“附近的车”、美团和饿了么的“附近的餐馆”这样的功能。

位置数据通常使用二维的经纬度表示，经度范围 [-180, 180]，纬度范围[-90, 90]。试想下如果使用关系型数据库存储（元素 id, 经度 x, 纬度 y），该如何计算？
假设 (x0, y0) 是用户，r 是半径，使用一条 SQL 就可以圈出来。

select id from positions where x0-r < x < x0+r and y0-r < y < y0+r;

可以对经纬度坐标加上索引进行优化，但数据库查询性能毕竟有限，可能不是一个很好的方案。

业界比较通用的地理位置距离排序算法是 GeoHash 算法，它是 将二维的经纬度数据映射到一维的整数。映射的算法和用法这里就不具体展开了。下面是两个使用注意事项：

1. 一维映射是有损的

在使用 Redis 的 Geo 查询时，时刻想着它的内部结构实际上是一个 zset(skiplist)。通过 zset 的 score 排序就可以得到坐标附近的其他元素，通过 score 还原成坐标值就可以得到元素的原始坐标。但需要注意，通过映射再还原回来的值会出现较小的差别，原因是二维坐标进行一维映射是有损的。

1. Geo 数据单独 Redis 实例部署更加

Redis 的 Geo 数据结构，数据会全部放到一个 zset 集合中。如果在 Redis 集群环境，集合可能从一个节点迁移到另一个节点，如果单个 key 的数据过大，会对集群迁移工作造成较大影响。因此，Geo 的数据建议使用单独 Redis 实例部署，不适用集群环境。

6. 限流

6.1 简单限流

限流的场景非常常见，控制用户行为，如发帖、回复、点赞等。简单的限流策略：限定用户的某个行为在指定的时间内只允许发生 n 次，这里我们可以使用 zset 数据结构的 score 值，存储毫秒时间戳，就可以很方便的取某个时间窗口内用户的行为次数。

此方案有个缺点，因为它要记录时间窗口内所有的行为记录，如果这个量很大，此方案就不合适了，因为会消耗大量的存储空间。

6.2 漏斗限流

Redis 4.0 提供了一个限流 Redis 模块，叫 Redis-Cell。该模块使用了漏斗算法，并提供了原子的限流指令。指令只有一条：cl.throttle，对着文档来使用即可。

7. 总结

上面的描述没有深入过多的技术细节，重点还是以讨论场景为主，因为据个人的了解，其实很大一个部分开发者对 Redis 的认识还只是作为缓存层，但基于 Redis 的丰富数据结构，Redis 可以在很多场景中发挥作用。结合场景再思考其数据结构设计，也能有所感悟。后面准备再整理一篇关于 Redis 数据结构以及内存优化的总结（希望能完成吧哈哈）。

参考书籍：

1. 《Redis 深度历险 核心原理与应用实践》