共计 1009 个字符,预计需要花费 3 分钟才能阅读完成。
比照 kafka — 分区是怎么指定的
kafka 是有 Partition 的概率,发送音讯的时候,跟进分区规定进行抉择哪个 Partition,每个 Partition 都有本人对应的 broker。
RocketMQ 有 MessageQueue,相似于 Partition,发送音讯的时候,也是先抉择 MessageQueue,而后依据 MessageQueue 对应的 broker 信息发送给对应的 broker。
MessageQueue 抉择有两种,启用 Broker 故障提早机制不启用 Broker 故障提早机制,默认不启用。
不启用 Broker 故障提早机制
刚开始的时候,会有一个随机值,比方 5,而后对 MessageQueue 的个数进行取模,为 1,而后就对第二个 MessageQueue 的 broker 进行发送数据。
下一个音讯,这个随机值就会加 1,取模后为 2,对第三个 MessageQueue 的 broker 进行发送数据。
简略的说,就是轮询。
因为 broker 可能会呈现问题,比方 MessageQueue- 0 对应的 broker 为 broker-a,MessageQueue- 1 也是 broker-a。
那发送给 MessageQueue- 0 的 broker- a 失败的时候,会把 broker- a 记录下来,重试的时候,会持续迭代,此时是 MessageQueue-1,broker 也是 broker-a,那就会往下轮询,去找 MessageQueue-2,通过 MessageQueue- 2 进行发送音讯。
这样的机制,就会防止重试到同一个 broker,减低失败的可能性。
启用 Broker 故障提早机制
MQ 发送音讯的时候,会记录这个音讯发送的工夫,如果 broker- a 是 50 毫秒,那下次发送就能够间接发,如果是 550 毫秒,那须要等 30 秒后才能够发给 broker-a,规定同下表。
那比方是 800 毫秒呢,因为是介于 550 到 1000 间接,所以算 550 这个档,也就是提早 30 秒。
如果是 broker 故障等导致失败,则会间接当作 3 万毫秒,相当于 600 秒内不能发送这个 broker。
在这种机制下,每次发送音讯的时候,也是通过轮询的,然而轮询拿出一个 MessageQueue,就会去判断这个 broker- a 是否在延迟时间内,如果还须要期待,那就持续轮询下一个 MessageQueue。
如果都在延迟时间内,那就找一个绝对可用的,如果也没有绝对可用的,那就持续轮询,间接返回对应的 MessageQueue。