时长:大小12.81M
作者回复: 👍👍👍
作者回复: 👍👍👍
作者回复:
第一个问题,一般来说分库分表也不会有问题,为什么?因为,使用我们的方法,对于一条具体的消息,总是会落到确定的某个库表上,它的重复消息也会落地同样的库表上,所以分库分表不是问题。
第五个问题,有的消息队列会有一个特殊的队列来保存这些总是消费失败的“坏消息”,然后继续消费之后的消息,避免坏消息卡死队列。这种坏消息一般不会是因为网络原因或者消费者死掉导致的,大多都是消息数据本身有问题,消费者的业务逻辑处理不了导致的。
作者回复: 感谢支持!
作者回复: 确实这个例子解决不了ABA问题,如果要解决这个问题,只能使用版本号的方式。
作者回复: 👍👍👍
作者回复: A1:主要是出于性能考虑。
A2:大部分消息队列在实现的时候,都是批量收发的,但是,采用基于位置的确认机制,是可以保证顺序的。
作者回复: 架构设计就是在取舍之间选择最合适的实现方式。
作者回复: 这个情况不需要配置多个消费组,只要主题中配置了多个分区,同一个消费组内也会出现这种情况。
作者回复: 👍👍👍
作者回复: 关于ABA的问题,我在另外一个课程《后端存储实战课》的[第一节课](https://time.geekbang.org/column/article/204673)中有详细的讲解,你可以看一下。(如果只看其中的一节课,应该是免费的)
作者回复: 实际上,MQ只有在异常情况下(比如Broker宕机,网络中断),才会产生重复消息,一般情况下是不会有重复消息的,所以代价和开销问题不用太考虑。
作者回复: 你说的这个情况确实是这样,但10s(或者更长时间)之后再出现一个重复ID的情况是非常罕见的,所以也就无所谓的。
其实,很多工程上解决问题的方法,理论上都存在缺陷。比如几乎所有一致性算法都解决不了拜占庭将军问题,很多分布式事务理论也不能保证所有情况下的数据一致性。
但这些方法确实能解决实际问题,这才是我们需要关注的。
作者回复: 不用要求生产者和消费者连同一个数据库。
生产者只要保证,发出去的每条转账消息都有一个唯一的转账单ID,这个“转账单 ID”可以存在生产者的数据库中,也可以不存,看业务需求。只要这个转账单ID不重复就可以了,这个很容易做到,比如我们用MySQL的Sequence就可以生成。
消费者用这个转账单ID结合数据库(消费者的数据库,可以和生产者数据库不同)的唯一约束,就可以来实现消费幂等了。
作者回复: 是的
作者回复: 正常情况下不会出现,如果有故障,比如broker故障、consumer故障或者网络连接抖动,都可能会出现重复消费,也就是一个消息被不同的consumer都消费到的情况,kafka和rocketmq都有可能会出现这种情况。
作者回复: 一般来说,如果不做特殊的设置(比如按照key哈希到特定分区上),是保证不了“重复消息投递应该投到相同队列”的。
作者回复: 是的,第一种方法没那么通用,但更容易实现。