老板要求写一个公用的 rabbitmq 客户端给其他人用, 要求至少一次投递, 而且只能依赖 rabbitmq 自身, 想来想去这根本不可能实现啊

[bthulu]

除非一次 basicPublish 一次 waitForConfirmsOrDie, 这样性能又不行.

异步 confirm 呢, 每个 channel 都要保存自身发出去的数据, 然后在 ack 的时候清除掉, 在 nack 的时候咋办呢? 无限重发吗? 还有, 对于长时间既不 nack 又不 ack 的数据怎么处理, 还是重发么? 重发么, 发过去如果还是又不 ack 也不 nack 呢, 最后越积越多就 OOM 了. 而且这样必须有一个线程检测既不 nack 又不 ack 的数据进行处理, 否则这个保存数据的容器迟早把内存撑爆.

批量 confirm 这个看起来似乎可行, 但 waitForConfirmsOrDie 怎么处理呢, 一个连接一个定时线程处理所有 channel 的 waitForConfirmsOrDie, 还是一个 channel 一个定时线程处理 waitForConfirmsOrDie?

好烦躁, 感觉 rabbitmq 对于消息队列来说就是个半成品, 要求低延迟, 非可靠的应用还能用用, 可靠性要求高一点简直难用到爆

[petercui]

spring cloud stream 如何？

[CodeCodeStudy]

我看成了 “老公要求写一个 rabbitmq 客户端”