字符串、Hash、List、Set、ZSet、GEO（地理位置信息）、Stream（用于MQ持久化和主备复制）
| 名称 | 说明 |
|---|---|
| 字符串 | key是字符串，value是字符串 |
| Hash | key是字符串，value是key-value集合 |
| List | 按照列表插入顺序排列（有序），key是字符串，value是字符串集合，可重复 |
| Set | 无序排列，key是字符串，value是字符串集合，不可重复 |
| ZSet | 有序排列，每个value带有分数，根据分数排列，key是字符串，value是字符串集合，不可重复 |
| GEO | 地理位置信息，key是字符串，value是名称+经度+维度，可做距离测算、范围内相邻点计算等 |
| Stream | 用于MQ持久化和主备复制 |
*基于 Stream 类型的实现
| 优点 | 应用 |
|---|---|
| Stream类型redis就是为了实现消息队列的。支持自动生成消息ID，分组消费，ACK，消息转移，队列监控等核心消息队列功能 | redis 流 stream的使用总结 - 基础命令 redis 流 stream的使用总结 - 如何遍历 redis 流 stream的使用总结 - 消费者组 |
*PUB/SUB，订阅/发布模式 【用于即时通讯】
| 方式 | 优点 | 缺点 | 应用 |
|---|---|---|---|
| 1、SUBSCRIBE，用于订阅信道 2、PUBLISH，向信道发送消息 |
1、典型的广播模式，一个消息可以发布到多个消费者 2、多信道订阅，消费者可以同时订阅多个信道，从而接收多类消息 3、消息即时发送，消息不用等待消费者读取，消费者会自动接收到信道发布的消息 |
1、消息一旦发布，不能接收。换句话就是发布时若客户端不在线，则消息丢失，不能寻回 2、不能保证每个消费者接收的时间是一致的 3、若消费者客户端出现消息积压，到一定程度，会被强制断开，导致消息意外丢失。通常发生在消息的生产远大于消费速度时 |
Pub/Sub 模式不适合做消息存储，消息积压类的业务，而是擅长处理广播，即时通讯，即时反馈的业务。 |
*两种轮训：基于List的 LPUSH+BRPOP 的实现 和 基于SortedSet有序集合的实现【用于延时队列】
| 方式 | 优点 | 缺点 | 应用 |
|---|---|---|---|
| 1、LPUSH，将消息队列 2、BRPOP，从队列中取出消息，阻塞模式 |
1、实现简单 2、Reids支持持久化消息，意味着消息不会丢失，可以重复查看（注意不是消费，只看不用，LRANGE类的指令）。 3、可以保证顺序，保证使用LPUSH命令，可以保证消息的顺序性 4、使用RPUSH，可以将消息放在队列的开头，达到优先消息的目的，可以实现简易的消息优先队列。 |
1、做消费确认ACK比较麻烦，就是不能保证消费者在读取之后，未处理后的宕机问题。导致消息意外丢失。通常需要自己维护一个Pending列表，保证消息的处理确认。 2、不能做广播模式，例如典型的Pub/Discribe模式。 3、不能重复消费，一旦消费就会被删除 4、不支持分组消费，需要自己在业务逻辑层解决 |
Redis应用-异步消息队列与延时队列 |
https://xiaomi-info.github.io/2019/12/17/redis-distributed-lock/