你可能不知道的Redis用法

除了缓存,Redis的用法你知道多少?

基于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还原成坐标值就可以得到元素的原始坐标。但需要注意,通过映射再还原回来的值会出现较小的差别,原因是二维坐标进行一维映射是有损的。

2. 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深度历险 核心原理与应用实践》

近期回顾

1、玩转HBase百亿级数据扫描

2、Spark 设置指定 JDK 的正确姿势

3、详解Kafka:大数据开发最火的核心技术

4、关于NoSQL,看这篇就够了

5、一份超详细的 Spark 入门介绍

6、入门教程 | 从安装部署开始学习 Elasticsearch

原文发布于微信公众号 - 大数据手稿笔记(gh_fe6a620edd40)

原文发表时间:2019-07-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券