RocketMQ生产者组topic和消费组的关系

各个之间的关系其实很松散,并不是说不能操作

最佳实践

订阅关系一致

多个 Group ID 订阅了多个 Topic，并且每个 Group ID 里的多个消费者实例的订阅关系保持了一致。
消费幂等
最终一致性保证数据一致性,如果不幂等,将导致数据错乱

topic和tag的关系
topic可以是一级过滤关系 tag是二级过滤关系

使用:
业务消息往往推荐做topic 的 一级区分
tag往往用于过滤后续的消息

例如: 飞跃交易消息 和 飞跃物流消息 topic
飞跃化妆品下单消息 和 飞跃电器下单消息 tag

消费模式

集群消费和广播消费

推荐集群消费
可以用集群消费模拟广播消费,例如创建多个GroupID模拟广播消费

问题解释:
订阅关系不一致
同一消费组下不同消费者订阅关系
导致消息丢失
关键的代码： ConsumerGroupInfo.updateSubscription(final Set subList) 关键代码： if (sub.getTopic().equals(oldTopic)) { exist = true; break; } … it.remove(); updated = true; 这里其实是做了一个检查，做这个检查的默认前提是一个consumerGroup下面的订阅消息是一样的，就是每个consumer注册的subscription应该是一样的，如果不一样就把之前注册的删除

未做幂等或者没做好
1.在TCC中,发送一条订单过期取消的消息,由于未做幂等导致,导致复活该订单失败(其实本身不推荐这样,推荐的操作是,用户去查询失效的订单时,选择再来一单即可,而不是复活订单)
2.仅仅通过redis的分布式锁来做幂等:原有业务是查询缓存,然后修改缓存,再落库
但是在查询缓存时由于缓存失效,导致去数据库查询缓存,结果超过了红锁的查询时间(10分钟),导致该消息的幂等操作失效,由其他消息修改了原有数据,导致错乱

参考:
https://www.jianshu.com/p/2838890f3284
https://help.aliyun.com/document_detail/95837.html