打算在生产环境中用这个扩展 但是不知道可靠性如何

建议延迟队列增加消息重发机制，比如增加一个参数，消息id 多次发送时如果ID相同可以覆盖之前发送的消息。

文档里说“QueueBuilder类使用定时器进行消费，每一次消费之后会根据消息的属性 _header['_delete'] 来进行消息释放”，
但是现在https://github.com/workbunny/webman-rqueue/blob/master/src/Builders/GroupBuilder.php#L60，消费时传入$del参数是false，

 $this->consume($worker, false);

https://github.com/workbunny/webman-rqueue/blob/master/src/Builders/Traits/MessageQueueMethod.php#L320这里的删除

 if($del) { $client->xDel($queueName, $ids); }

xDel永远不会执行。

Your requirements could not be resolved to an installable set of packages.

Problem 1
- Root composer.json requires workbunny/webman-rqueue * -> satisfiable by workbunny/webman-rqueue[0.0.1, 0.0.2, 1.0.0, 1.0.1].
- workbunny/webman-rqueue[0.0.1, ..., 0.0.2, 1.0.0, ..., 1.0.1] require psr/container ^1.1.1 -> found psr/container[1.1.1, 1.1.2] but it conflicts with your root composer.json require (^2.0).

You can also try re-running composer require with an explicit version constraint, e.g. "composer require workbunny/webman-rqueue:*" to figure out if any version is installable, or "composer require workbunny/webman-rqueue:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

好像不支持php8.0 我用了psr/container(^2.0)

目前只做了

1. command的基础使用的测试
2. publish的基础测试

现状

1. republish在极端情况下（ack成功后redis服务宕机）消息可能无法正常republish，从而消息存在丢失可能性

目标

1. 保障数据

方案

1. 借助其他方式储存该数据，如sqlite或者file
2. 使用timer进行republish

现状

1. 极端情况下可能存在数据消费成功但未ack
2. 未ack数据虽然不会被当前消费组消费但存在数据冗余

目标

1. 将pending数据ack

方案

1. 在消费者主定时器中增加xClaim逻辑，读取config中的消息最大等待时间
2. 单独启动一个独立定时器，使用与消费者相同的消费组进行xClaim处理，读取config中的消息最大等待时间

启动两个消费QueueBuilder，一个延迟的一个非延迟的。在都没有进行消费的时候延迟QueueBuilder的CPU占用相比非延迟QueueBuilder差距很大，请问是因为延迟QueueBuilder内定时器的原因吗

硬件配置
2vCPU 2.0GHz

非延迟队列修改$timerInterval后重启，运行php start.php status显示如下