用 Redis list 与 stream 实现队列

目标

用Redis列表和流分别创建队列，再模拟列表队列丢失消息的点，并用流的消费者组和PEL阻止。

为什么重要

LPUSH/BRPOP两行就变成了队列。所以很多团队在这里停下来，几个月后发现每次部署时正在处理的工作都会悄悄消失。BRPOP因为在这个返回的瞬间，消息已经在Redis中被删除。这个练习首先用眼睛看到它的损失，然后按顺序粘贴两个解决方法。LMOVE处理中放置列表的手动制作方法，以及从一开始就为这个问题设计的流的消费者组。了解这两个差异，即使在第一次看到SQS的可见性超时或Kafka的偏移提交时，也能立即看到是解决什么问题的设备。

阶段

redis-cli PING结果/root/q/ping.txt保存到。PONG这个必须放进去。
/root/q/produce.py罗q:jobs在job-1从开始job-5最多放入5件。LLEN q:jobs是5。
/root/q/consume.py把5件都拿出来/root/q/order.out逐行写一行。第一行是job-1，最后一行是job-5应该这样做。
/root/q/safe_consume.py是LMOVE罗q:jobs从q:jobs:processing以原子方式转移后处理，成功后在处理过程中从列表中删除。模仿处理过程中死亡的情况q:jobs:processing留下1件。
/root/q/stream_add.py罗斯特林q:orders5件XADD做。MAXLEN ~ 1000提出上限。XLEN q:orders是5。
消费者集团g1制作并/root/q/stream_consume.py读了5个，其中只有4个XACK做。
XPENDING q:orders g1结果/root/q/pending.txt保存到。未确认信息必须准确为1条。
/root/q/compare.md用下划线写表格。第一行的行标题是소비 후 보존，다중 소비자 그룹，실패 회수，메모리有四个，必须有列表和流列。

参考

LMOVE q:jobs q:jobs:processing RIGHT LEFT一次性取出和移动。
创建组：XGROUP CREATE q:orders g1 0
未确认查询：XPENDING q:orders g1
常见的错误1：LPUSH放入LPOP取出后——那么就变成了LIFO。
常见的错误2：在流媒体上MAXLEN不加载的话，内存会无限增长。

确认Redis连接

redis-cli PING结果/root/q/ping.txt保存到。PONG这个必须放进去。

用redis-cli确认响应，并将结果保存为文件。已经在127.0.0.1:6379上运行。

将列表放入队列中

/root/q/produce.py罗q:jobs在job-1从开始job-5最多放入5件。LLEN q:jobs是5。

要放在一边的末端，然后从另一边的末端取出，才能实现FIFO。要放在哪一边很重要。

证明消费顺序是FIFO

/root/q/consume.py把5件都拿出来/root/q/order.out逐行写一行。第一行是job-1，最后一行是job-5应该这样做。

分别用文件保存放入和取出的顺序，比较一下。如果顺序颠倒了，放入的方向和取出的方向是同一侧。

引入防止损失的处理中列表

/root/q/safe_consume.py是LMOVE罗q:jobs从q:jobs:processing以原子方式转移后处理，成功后在处理过程中从列表中删除。模仿处理过程中死亡的情况q:jobs:processing留下1件。

用取出和移动的命令来做就很原子化了。如果用两个命令分开，中间可能会死掉。

在直播中添加消息

/root/q/stream_add.py罗斯特林q:orders5件XADD做。MAXLEN ~ 1000提出上限。XLEN q:orders是5。

以字段-值对存储。为了不无限增长，请同时指定上限。

作为消费者集团消费并发送确认回复

消费者集团g1制作并/root/q/stream_consume.py读了5个，其中只有4个XACK做。

必须先创建群组才能阅读。只阅读的话就会留在PEL中，只有发送确认回复才能删除。

确认没有确认回复的消息

XPENDING q:orders g1结果/root/q/pending.txt保存到。未确认信息必须准确为1条。

故意只发送一个确认回复就可以了。有查询未确认消息数量的命令。

写列表和流比较表

/root/q/compare.md用下划线写表格。第一行的行标题是소비 후 보존，다중 소비자 그룹，실패 회수，메모리有四个，必须有列表和流列。

按消费后保存、多组、失败回收、内存四轴进行整理。表格格式和行标题是评分标准。