![ad4136a9e4da2f5b1c5bc70a9a26d02f.png](https://i-blog.csdnimg.cn/blog_migrate/4ccf883f93976572fb34515d94f44bff.jpeg)
前言
之前咱们简单介绍了一下Redis的简单结构,相信很多读者看着比较入门。的确,笔者在介绍任何技术时,都是由浅及深的路数,为的是刚入门不久的新人,毕竟相对于久经沙场的老将,新人更需要这方便的普及。
好的,话不多少,今天咱们就进行Redis的实战应用,深入剖析Redis从今天开始。
![83fcad3b6e9f9e1cfc80bfb64908f7fd.png](https://i-blog.csdnimg.cn/blog_migrate/26958280a90e7b26f3e5f69b5013ac26.png)
Redis应用一:分布式锁
分布式应用进行逻辑处理时经常会遇到并发问题。
比如一个操作要修改用户的状态,修改状态需要先读出用户的状态,在内存里进行修改,改完了再存回去。如果这样的操作同时进行了,就会出现并发问题,因为读取和保存状态这两个操作不是原子的。(所谓原子操作是指不会被线程调度机制打断的操作;这种操作一旦开始,就一直运行到结束,中间不会有任何context switch线程切换。)
![3374b88172c9b76a11aed3375fa9d168.png](https://i-blog.csdnimg.cn/blog_migrate/2bf36fac436f21732135bcc78da5ae29.png)
这个时候就要使用到分布式锁来限制程序的并发执行。Redis分布式锁使用非常广泛,它是面试的重要考点之一,很多同学都知道这个知识,也大致知道分布式锁的原理,但是具体到细节的使用上往往并不完全正确。
分布式锁
分布式锁本质.上要实现的目标就是在Redis 里面占一个“座位”,当别的进程也要来占时,发现已经有人坐在那里了,就只好放弃或者稍后再试。
占座一般是使用setnx(set if not exists)指令,只允许被一个客户端占坑。先来先占,用完了,再调用del指令释放座位。
> setnx lock:codehole true
OK
... do something critical ...
> del lock:codehole
(integer) 1
但是有个问题,如果逻辑执行到中间出现异常了,可能会导致del指令没有被调用,这样就会陷入死锁,锁永远得不到释放。
于是我们在拿到锁之后,再给锁加上一一个过期时间,比如5s, 这样即使中间出现异常也可以保证5秒之后锁会自动释放。
> setnx lock:codehole true
OK
> expire lock:codehole 5
... do something critical ...
> del lock:codehole
(integer) 1
但是以上逻辑还有问题。如果在setnx 和expire 之间服务器进程突然挂掉了,可能是因为机器掉电或者是被人为杀掉的,就会导致expire得不到执行,也会造成死锁。
这种问题的根源就在于setnx 和expire是两条指令而不是原子指令。如果这两条指令可以一起执行就不会出现问题。也许你会想到用Redis 事务来解决。但是这里不行,因为expire是依赖于setnx 的执行结果的,如果setnx 没抢到锁,expire是不应该执行的。事务里没有if-else分支逻辑,事务的特点是一口气执行,要么全部执行要么一个都不执行。
为了解决这个疑难,Redis 开源社区涌现了- -堆分布式锁的library, 专门用来解决这个问题。实现方法极为复杂,小白用户一般要费很大的精力才可以搞懂。如果你需要使用分布式锁,意味着你不能仅仅使用Jedis 或者redis-py 就行了,还得引入分布式锁的library。
![9681340ddce11f4a22735c1fb5e50445.png](https://i-blog.csdnimg.cn/blog_migrate/0c28522353631c64630aeb79b0980234.png)
为了治理这个乱象,Redis 2.8版本中作者加入了set 指令的扩展参数,使得setnx和expire指令可以一-起执行,彻底解决了分布式锁的乱象。从此以后所有的第三方分布式锁library可以休息了。> set lock:codehole true ex 5 nx OK … do something critical … > del lock:codehole.上面这个指令就是setnx 和expire 组合在一起的原子指令,它就是分布式锁的奥义所在。
超时问题
Redis的分布式锁不能解决超时问题,如果在加锁和释放锁之间的逻辑执行的太长,以至于超出了锁的超时限制,就会出现问题。因为这时候锁过期了,第二个线程重新持有了这把锁,但是紧接着第一个线程执行完了业务逻辑,就把锁给释放了,第三个线程就会在第二个线程逻辑执行完之间拿到了锁。
为了避免这个问题,Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了,数据出现的小波错乱可能需要人工介入解决。
tag = random.nextint()
if redis.set(key, tag, nx=True, ex=5):
do_something()
redis.delifequals(key, tag)
有一个更加安全的方案是为 set 指令的 value 参数设置为一个随机数,释放锁时先匹配 随机数是否一致,然后再删除 key。但是匹配 value 和删除 key 不是一个原子操作,Redis 也 没有提供类似于 delifequals 这样的指令,这就需要使用 Lua 脚本来处理了,因为 Lua 脚本可 以保证连续多个指令的原子性执行。
# delifequals
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
Redis应用二:延时队列
我们平时习惯于使用 Rabbitmq和Kafka 作为消息队列中间件,来给应用程序之间增加 异步消息传递功能。这两个中间件都是专业的消息队列中间件,特性之多超出了大多数人的理 解能力。
使用过 Rabbitmq 的同学知道它使用起来有多复杂,发消息之前要创建 Exchange,再创 建 Queue,还要将 Queue 和 Exchange 通过某种规则绑定起来,发消息的时候要指定 routingkey,还要控制头部信息。消费者在消费消息之前也要进行上面一系列的繁琐过程。但是绝大多数情况下,虽然我们的消息队列只有一组消费者,但还是需要经历上面这些繁琐的过程。
有了Redis,它就可以让我们解脱出来,对于那些只有一组消费者的消息队列,使用 Redis 就可以非常轻松的搞定。Redis 的消息队列不是专业的消息队列,它没有非常多的高级特性, 没有 ack 保证,如果对消息的可靠性有着极致的追求,那么它就不适合使用。
异步消息队列
Redis 的 list(列表) 数据结构常用来作为异步消息队列使用,使用rpush/lpush操作入队列, 使用 lpop 和 rpop 来出队列。
![879fbdc2cf41972e91b523af113e58b8.png](https://i-blog.csdnimg.cn/blog_migrate/4e40756b79f8f3cc207e64682355115f.png)
> rpush notify-queue apple banana pear
(integer) 3
> llen notify-queue
(integer) 3
> lpop notify-queue
"apple"
> llen notify-queue
(integer) 2
> lpop notify-queue
"banana"
> llen notify-queue
(integer) 1
> lpop notify-queue
"pear"
> llen notify-queue
(integer) 0
> lpop notify-queue
(nil)
上面是 rpush 和 lpop 结合使用的例子。还可以使用 lpush 和 rpop 结合使用,效果是一 样的。这里不再赘述。
队列空了怎么办?
客户端是通过队列的 pop 操作来获取消息,然后进行处理。处理完了再接着获取消息, 再进行处理。如此循环往复,这便是作为队列消费者的客户端的生命周期。
可是如果队列空了,客户端就会陷入 pop 的死循环,不停地 pop,没有数据,接着再 pop, 又没有数据。这就是浪费生命的空轮询。空轮询不但拉高了客户端的CPU,redis 的 QPS 也会被拉高,如果这样空轮询的客户端有几十来个,Redis 的慢查询可能会显著增多。
通常我们使用 sleep 来解决这个问题,让线程睡一会,睡个 1s 钟就可以了。不但客户端的 CPU 能降下来,Redis 的 QPS 也降下来了。
![e074dd17cf9365a02abeb39063bc37fd.png](https://i-blog.csdnimg.cn/blog_migrate/66b929d4b4fe6e115dbaca361057f65b.png)
队列延迟
用上面睡眠的办法可以解决问题。但是有个小问题,那就是睡眠会导致消息的延迟增大。 如果只有 1 个消费者,那么这个延迟就是 1s。如果有多个消费者,这个延迟会有所下降,因 为每个消费者的睡觉时间是岔开来的。
有没有什么办法能显著降低延迟呢?你当然可以很快想到:那就把睡觉的时间缩短点。这 种方式当然可以,不过有没有更好的解决方案呢?当然也有,那就是 blpop/brpop。
这两个指令的前缀字符 b 代表的是 blocking,也就是阻塞读。
阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。消息的延迟几乎为零。用 blpop/brpop 替代前面的 lpop/rpop,就完美解决了上面的问题。
空闲连接自动断开
你以为上面的方案真的很完美么?先别急着开心,其实他还有个问题需要解决。
什么问题?—— 空闲连接的问题。
如果线程一直阻塞在那里,Redis 的客户端连接就成了闲置连接,闲置过久,服务器一般 会主动断开连接,减少闲置资源占用。这个时候 blpop/brpop 会抛出异常来。
所以编写客户端消费者的时候要小心,注意捕获异常,还要重试。
锁冲突处理
上文我们讲了分布式锁的问题,但是没有提到客户端在处理请求时加锁没加成功怎么办。 一般有 3 种策略来处理加锁失败:
直接抛出异常,通知用户稍后重试;sleep 一会再重试;将请求转移至延时队列,过一会再试;直接抛出特定类型的异常
这种方式比较适合由用户直接发起的请求,用户看到错误对话框后,会先阅读对话框的内 容,再点击重试,这样就可以起到人工延时的效果。如果考虑到用户体验,可以由前端的代码 替代用户自己来进行延时重试控制。它本质上是对当前请求的放弃,由用户决定是否重新发起 新的请求。
sleep
sleep 会阻塞当前的消息处理线程,会导致队列的后续消息处理出现延迟。如果碰撞的比 较频繁或者队列里消息比较多,sleep 可能并不合适。如果因为个别死锁的 key 导致加锁不成 功,线程会彻底堵死,导致后续消息永远得不到及时处理。
延时队列
这种方式比较适合异步消息处理,将当前冲突的请求扔到另一个队列延后处理以避开冲突。
以上就是小编整理的Redis应用实战的两个小节,希望能对大家有所帮助。
喜欢小编请多多点赞评论转发,关注小编,后续小编会再带来更多学习内容,咱们每天都共同进步!!!
![a7f2248d37343e9a1f5496eb3effc585.png](https://i-blog.csdnimg.cn/blog_migrate/84b1b149e2ab56e0b3b453d21ad08e78.png)