redis消息队列
redis可以直接实现消息队列，无需学习别的技术
list——本质是链表，数据存储
启动同一个IP和端口的2台客户端，一边阻塞弹出，一边添加元素
在20s内，如果有元素就弹出，没有元素就等待，超过20s就结束等待
优点：先进先出，消息有序
没有内存上限
有持久化机制，保证数据安全
缺点：
因为pop是remove and get，可能导致消息丢失，刚取出消息没来得及处理就宕机了
只能被一个消费者处理
pubsub——不可靠
-- 订阅一个或多个频道
subscribe
-- 发送消息给一个频道
publish
-- 订阅格式匹配的频道
psubscribe通配符
？一个字符
*0个或多个
[]指定字符
再启动一个客户端
确保都操作数据库0——select 0
我是先发送再订阅，所以msg1没有收到，但是订阅之后再发的msg2、msg3都被收到了，而且消费者会一直处于订阅就是接收消息状态，天生就是阻塞式的
pmessage order.* order.queue msg2表示订阅的order.*频道接收到了order.queue频道发布的msg2消息
pmessage order.queue order.queue msg2表示订阅的order.queue频道接收到了order.queue频道发布的msg2消息
发布消息的返回值就是订阅该频道的消费者数量！！
所以一开始发布消息时没消费者订阅该频道，返回值是0，后面的是2，最后一个发布到one，只有一个消费者订阅
优点：
支持多个生产者，多个消费者
缺点：
不支持数据持久化：本身就是消息发送，不是数据存储，不支持持久化
无法避免消息丢失：如果发布的消息没有消费者订阅，则直接丢失
消息堆积有上限：发布消息时有消费者订阅，则会存储到消费者缓冲区，缓存空间有上限
不太可靠！！
stream
-- 添加消息
xadd 队列名称 默认自动创建 消息上限 消息id 字段 值
-- 消息长度
xlen 队列名称
-- 读取消息，阻塞时长为0表示一直阻塞
xread 读取数量 是否阻塞 阻塞时长 streams 队列名称 读取起始id
循环读取最新消息时可能有漏读，在处理消息时，收到了很多条，但是下次只会处理最新的，造成漏读
同一个消息可以被不同消费者反复读取，数据持久化
可以阻塞读取
stream消费者组——解决漏读
只要在消费者组就是竞争关系，处理消息速度加快，避免消息堆积
记录最后一个被处理的消息，有点像PC程序计数器，解决漏读
消费者接受到消息后存入pending-list，当处理完后，移除，解决消息丢失
如何让消费者拿到我想发送给他的消息？
订阅多个频道，比如我想拿到order.queue，又想拿到order.one，为了确保该消费者一定能竞争到queue，就订阅order.queue和order.*
pending-list和消费者缓冲区有什么区别？
xgroup create 队列名称 消费者组名称 起始id 是否自动创建(默认false)
xreadgroup group 消费者组名称 消费者名称 读取数量 是否阻塞 阻塞时长 自动确认 streams 队列名称 起始id
一个消息只能被读取一次
以下是正常情况，获取消息并返回ack
如果收到消息就宕机了，没来及ack则会存储在pending-list中，如何查看pending-list勒？
-和+表示从最小到最大的id
读取消息时先用>，读取未消费的消息。如果ack过程中出现异常，则查看pending-list中的消息，然后用0，读取已经消费但是没有Ack的消息
伪代码
redis队列
