作者回复: 👍👍👍
作者回复: 👍👍👍
作者回复:
第一个问题,一般来说分库分表也不会有问题,为什么?因为,使用我们的方法,对于一条具体的消息,总是会落到确定的某个库表上,它的重复消息也会落地同样的库表上,所以分库分表不是问题。
第五个问题,有的消息队列会有一个特殊的队列来保存这些总是消费失败的“坏消息”,然后继续消费之后的消息,避免坏消息卡死队列。这种坏消息一般不会是因为网络原因或者消费者死掉导致的,大多都是消息数据本身有问题,消费者的业务逻辑处理不了导致的。
作者回复: A1:主要是出于性能考虑。
A2:大部分消息队列在实现的时候,都是批量收发的,但是,采用基于位置的确认机制,是可以保证顺序的。
作者回复: 感谢支持!
作者回复: 架构设计就是在取舍之间选择最合适的实现方式。
作者回复: 确实这个例子解决不了ABA问题,如果要解决这个问题,只能使用版本号的方式。
作者回复: 👍👍👍
作者回复: 👍👍👍
作者回复: 这个情况不需要配置多个消费组,只要主题中配置了多个分区,同一个消费组内也会出现这种情况。
作者回复: 这个还是需要使用消息队列的用户来考虑。
作者回复: 正确!
作者回复: 正常情况下不会出现,如果有故障,比如broker故障、consumer故障或者网络连接抖动,都可能会出现重复消费,也就是一个消息被不同的consumer都消费到的情况,kafka和rocketmq都有可能会出现这种情况。
作者回复: 1.这个问题已经不是消息队列的问题了,而是二个不同的系统同时更新一份数据的问题,一般都不会这么来设计。
2. 这种方式是可行的。