内容简介：分布式锁需要解决的问题如下
一、从海量数据里查询某一固定前缀的key
-
KEYS pattern
- 例如：
KEYS k1*
查找所有符合给定模式pattern的key。
- KEYS指令一次性返回所有匹配的key
- 键的数量过大服务容易卡顿，太消耗内存。
- 例如：
-
SCAN cursor [MATCH pattern] [COUNT count]
scan 0 match k1* count 10
二、如何通过 Redis 实现分布式锁
分布式锁需要解决的问题如下
- 互斥性：任意时刻只能有一个客户端获取锁，不能同时有两客户端获取锁。
- 安全性：所只能由被持有的客户端删除。
- 死锁：避免死锁。
- 容错：比如Redis节点宕机的时候，客户端仍然能够获取锁，释放锁。
SETNX key value ：如果key不存在，则创建并赋值
- 时间复杂度：O（1）
- 返回值：设置成功返回1，设置失败，返回0.
EXPIRE key seconds ：设置key的生存时间，当key过期时（生存时间为0），会被自动删除，释放锁。
- 原子性得不到满足。
SET key value [EX seconds] [PX milliseconds] [NX|XX]
- set locktarget 12345 ex 10 nx
- EX seconds：设置键的过期时间为seconds秒
- PX milliseconds：设置键的过期时间为millionseconds毫秒
- NX：只在键不存在时，才对键进行设置操作
- XX：只在键已经存在时，才对键进行设置操作
- SET操作成功完成时，返回OK，否则返回nil
大量key同时过期注意事项
集中过期，由于清除大量key很耗时，会出现短暂的卡顿现象
- 解决方案：在设置key的过期时间的时候，在每个key加上随机值
如何使用Redis做异步队列
- 使用List作为队列，RPUSH生产消息，LPOP消费消息
缺点：没有等待队列里有值直接消费
弥补：可以通过在应用层引入Sleep机制去调用LPOP重试 - BLPOP key [key ...] timeout：阻塞直到队列有消息或者超时，
例如：blpop testlist 30：表示在30秒之内一直等待testlist消息，如果30秒之内没有消息则返回nil，如果在30内执行rpush testlist aaa，则能够获取到消息aaa并返回。
缺点：只能供一个消费者消费
一对多的消费队列
pub/sub：主题订阅模式
- 发送者（pub）发送消息，订阅之（sub）接收消息
- 订阅者可以订阅任意数量的频道
- 例如：多个消费者监听同一个频道：subscribe myTopic。发布消息：Publish myTopic "hello"这样多个消费者就可以收到消息。
- 缺点：消息的发布是无状态的，也就是即发即失，无法保证消息可达。而rabbitmq等专门的消息队列有ack应答机制更实用于消息队列。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
HTML 编码/解码
HTML 编码/解码
RGB CMYK 转换工具
RGB CMYK 互转工具