关于广播是否丢消息? 成熟的mq是不会的.

1. redis会丢. 因为是fireAngForget 发后即忘. 什么也保证不了, 最多一次. 毕竟专物专用, 人家不是干mq的

2. rocketmq广播不会丢消息. 因为广播不是消费者集群消费, 而是消费者单实例自己持久化存储消费位点.
   也就是, mq服务器持久化了所有消息(如果没达到3天过期的话), 消费者自己本地有记录消费位点, 也没有别的消费者来干扰你的消费位点. 所以不会丢消息
   这里说的不会丢消息是, mq服务和设计支持. 但是没说支持重试. 消费失败或者说如果有必要持久化消费位点的话, 需要消费者自己处理.

而且消息是基于拉模式的, 自己去拉, 拉没拉成功到位是消费者的事.消费者自己有能力和义务不错过消费. rocketmq只有拉模式
(他所谓的推也是基于拉封装的, 底层还是拉)
(比如redis非专业mq选手是推模式. 并且 服务器不负责保证推送成功, 比如发送失败, 消费失败, 这就是丢消息的原因)

3. 顺便说一下, 广播几乎不用. 为什么?
   业务场景举例, 订单侧消费者组和物流侧消费者组等多个消费组需要消费同一个topic.
   这压根不是广播好吗, 这就是发布订阅, 只不过是多个消费者订阅了同一个消息队列, 仅此而已.
   还是集群消费 (这当然更不会丢消息, 持久化和重试.提交消费位点都是封装好了的 只要别异常当做成功, 别业务侧再次并发消费就行)

4. 重平衡也不会丢消息. 成熟 (凡是已提交的, 一定是已消费的, 凡是没提交的, 总会被消费, 你总不能跳着消费)
   rokcetmq每20秒重平衡 更像是一个 兜底操作吧, 如果用默认的AllocateMessageQueueAveragelyByCircle (averagely-范围平均算法)
   1.如果集群状态没变, 结果还是固定的, 重分配的结果和上次一样
   2.如果变了, 就变了