案例

  • 订单确认后，自动寻源，需预先保存寻源的入参到mysql，然后组装消息发送到redis list
  • 库存中心通过rpop方式获取到消息体，消息处理环节，必须采取try catch模式，不管成功与否都需要写入结果到mysql，然后回写结果到redis list，待订单中心消费
  • 只能确保系统不宕机的情况，有完整的入参和出参
  • 如果出现系统宕机问题，或者再一定的时间范围内入参仍未改变寻源状态，此时，需要人工介入。

List类型使用说明

  • list类型是用来存储多个有序的字符串的(没有去重功能，Zset可去重)，支持存储2^32次方-1个元素。
  • redis可以从链表的两端进行插入（pubsh）和弹出（pop）元素,充当队列或者栈
  • 支持读取指定范围的元素集
  • 读取指定下标的元素等

注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，需要对链表进行遍历，性能随着参数index增大而变差，时间复杂度为 O(n)。

另外当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收。

使用场景：链表用来做异步队列

链表常用来做异步队列使用

  • 将需要延后处理的任务结构体序列化（JSON）成字符串塞进 Redis 的列表
  • 另一个线程从这个列表中轮询数据进行处理。
  • lpush + lpop = stack 先进后出的栈
  • lpush + rpop = queue 先进先出的队列
  • lpush + ltrim = capped collection 有限集合
  • lpush + brpop = message queue 消息队列

Redis 队列绕不开的消息丢失问题，一般借助List来实现消息队列：

  • 通过命令LPUSH（BLPUSH）把消息入队
  • 通过命令RPOP（BRPOP）获取消息。

但这种方式实现的队列是不安全的，因为RPOP（BRPOP）命令的特性：

  • 移除list的队尾元素(消息)并返回给客户端。这时该元素只存在于客户端的上下文中，redis服务器中没有这个元素.
  • 如果客户端在处理元素的过程崩溃了，那么这个元素就永远丢失了。这种情况导致：客户端虽然成功收到了消息，但是却没有处理它。

那如何实现一个更安全的队列呢？

可以试试redis的RPOPLPUSH (或者其阻塞版本的 BRPOPLPUSH）命令（类似于补偿机制）。

具体是操作是：

  • 在A队列推出元素(并删除)时，保存元素到 B队列。
  • 如果处理 元素 的客户端奔溃了，还可以在B队列找到

然而，也存在两个问题：

  • 多个消费者同时将消息转存入第二个队列，第二队列会出现( 已执行、未执行 )消息堆积
  • 假设你的消息很特别，不会重复，可以通过lrem a 0 "元素"函数找到并删除消息，另外启动的那个专门处理第二个队列的client面对的队列中的信息数量必须很小，如果很大，client处理不过来又不能使用并发，因为如果使用并发必须将消息pop出队列2，如果pop出队列2，那就回到了最初要绕开的问题。

最后

  • 做消费者确认ACK麻烦
  • 不能重复消费，一旦消费就会被删除
  • 队列不去重

因此，对于一致性要求高的场景，队列建议使用第三方的MQ，或者Kafka+Mongo。