基于redis stream实现一个可靠的消息队列

这篇具有很好参考价值的文章主要介绍了基于redis stream实现一个可靠的消息队列。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

我们使用的库为redisson。
添加元素到队列很简单，用RStream.add方法即可。

如何从队列获取元素？由于我们打算实现kafka那样的consumer group机制，所以，读操作要用RStream.readGroup函数（XREADGROUP命令），该命令有阻塞和非阻塞版本，简单起见，我们使用非阻塞版本（不带BLOCK参数），由应用层来定时轮询。Id参数我们设置为StreamReadGroupArgs.neverDelivered()，相当于redis命令里的>，每次只取最新的消息。相关的代码样例如下：

public List<Record> poll(String groupName, String consumerName) {
    return toConsumerRecords(redisMsgQueue.readGroup(groupName, consumerName, StreamReadGroupArgs.neverDelivered()));
}

追求可靠性，则须封装XACK命令。引入ACK之后，自然要考虑对那些ACK超时的消息如何补救。为此，我们要结合XPENDING和XCLAIM两条命令，利用前者查出目前尚未ACK的消息集M（术语叫PEL，pending entry list），利用后者将M中已超时的那部分（通过min-idle-time参数过滤）分配给其它存活的consumer去做补救处理。为何XPENDING出来之后要做XCLAIM呢？主要是我们希望做补救处理的consumer只能有一位，XCLAIM命令在多consumer竞争时能保证独占性，从而避免消息的多次处理。XPENDING遍历PEL也是有技巧的，一是要分批获取，二是由于XPENDING的startId和endId是闭区间，需将用于遍历的cursor Id转成开区间（参考redis的streamId说明，具体做法是将streamId的sequence部分加1）。参考实现如下：

public List<Record> fetchNotAck(String groupName, String consumerName, long ackTimeout) {
    PendingResult pr = redisMsgQueue.getPendingInfo(groupName);
    if (pr.getTotal() == 0) {
        return Collections.emptyList();	
    }
    StreamMessageId curId = pr.getLowestId();
    StreamMessageId maxId = pr.getHighestId();
    List<Record> totalRecs = new ArrayList<>();
    while (true) {
        List<PendingEntry> entries = redisMsgQueue.listPending(groupName, curId, maxId, 100);
        if (entries.isEmpty()) {
            break;
        }
        curId = makeExclusive(entries.get(entries.size() - 1).getId());
        Map<StreamMessageId, Map<String, T> > rawRes = redisMsgQueue.claim(groupName, consumerName, ackTimeout, TimeUnit.SECONDS, entries.stream.map(PendingEntry::getId).toArray(StreamMessageId[]::new));
        totalRecs.addAll(toConsumerRecords(rawRes));
    }
    return totalRecs;
}

private StreamMessageId makeExclusive(StreamMessageId id) {
    return new StreamMessageId(id.getId0(), id.getId1() + 1);
}

最后，stream的定时清理动作，解决内存占用过大的问题，使用lua脚本包装XTRIM命令，根据上一次清理时的stream size，计算本次要保留的元素个数。这里还有一个特殊点，如果一条未ACK消息被XTRIM或XDEL从stream里删除，其并不会从PEL里同步删除，用XCLAIM也获取不了它，这就成了一条PEL垃圾数据，据说redis7.0会解决该问题。stream清理算法如下：

private static final String SHRINK_SCRIPT = "local nowSz = redis.call('XLEN', KEYS[1]);redis.call('XTRIM', KEYS[1], 'MAXLEN', nowSz - ARGV[1]); local leftSz = redis.call('XLEN', KEYS[1]); redis.call('HSET', KEYS[2], KEYS[1], leftSz);return leftSz;";

public long shrinkByLastSize(long lastSize, String queueSizeMapName) {
    RScript  rScript = getRedissonClient().getScript(LongCodec.INSTANCE);
    return rScript.eval(RScript.Mode.READ_WRITE, SHRINK_SCRIPT, RScript.ReturnType.INTEGER, 
        Arrays.asList(this.streamName, queueSizeMapName), lastSize);
}

其中，queueSizeMap是一个redis hash，用于存储每个stream上次清理后的size。size的设置和stream的XTRIM操作必须是原子操作，所以放一个lua脚本里。另外，stream 和queueSizeMap有可能不在一个slot里（redis cluster下），要考虑在名字里加{}确保这俩在一起，否则lua脚本会报错。文章来源地址https://www.toymoban.com/news/detail-525840.html

到了这里，关于基于redis stream实现一个可靠的消息队列的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！