Redis

一、从海量数据里查询某一固定前缀的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应答机制更实用于消息队列。

五、Redis如何做持久化

• RDB（快照）持久化：保存某个时间点的全量数据快照
• SAVE：阻塞Redis的服务进程，直到RDB文件被创建完毕。
• BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程
  在redis.conf文件中设置：
  save 900 1 : 表示900秒内如果有一条写入指令就产生一次快照
  save 300 10 : 在300秒内有10条写入就产生一次快照
  stop-writes-on-bgsave-error yes
  rdbcompression yes : 在备份的时候将rdb文件压缩再保存
• AOF持久化：保存写状态
  记录下除了查询以外的所有变更数据库状态的指令
  以append的形式追加保存到AOF文件中（增量）
  在redis.conf文件中设置appendonly yes开启AOF
  appendsync 'always'（一旦缓存区内容发生变化就写入AOF） | 'everysec'（将缓存区内容每隔一秒写入AOF） | 'no'（交给操作系统处理）
• RDB和AOF的优缺点
  RDB优点：全量数据快照，文件小，恢复快
  RDB缺点：无法保存最近一次快照后的数据
  AOF优点：可读性高，适合保存增量数据，数据不容易丢失
  AOF缺点：文件体积大，恢复时间长

六、Redis集群