一、从海量数据里查询某一固定前缀的key

  1. KEYS pattern

    • 例如：KEYS k1*

    查找所有符合给定模式pattern的key。

    • KEYS指令一次性返回所有匹配的key
    • 键的数量过大服务容易卡顿，太消耗内存。

  2. SCAN cursor [MATCH pattern] [COUNT count]

    • 例如：scan 0 match k1* count 10 - 0为刚开始迭代，每次查10条。
    • 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
    • 以0作为游标开始一次新的迭代，知道命令返回游标0完成一次遍历
    • 不保证每次执行都返回某个给定数量的元素，支持模糊查询
    • 一次返回的数量不可控，只能是大概率符合count参数

二、如何通过Redis实现分布式锁

分布式锁需要解决的问题如下

  1. 互斥性：任意时刻只能有一个客户端获取锁，不能同时有两客户端获取锁。
  2. 安全性：所只能由被持有的客户端删除。
  3. 死锁：避免死锁。
  4. 容错：比如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应答机制更实用于消息队列。