1.MessageQueue
MessageQueue,该参数是在创建Topic的时候需要指定的一个很关键的参数。
比如:在创建"TopicOrderPaySuccess" 这个Topic 的时候,该Topic对应了多少个队列,就对应了多少个MessageQueue.
2.Topic、MessageQueue以及Broker之间的关系
分布式存储
每个Topic的数据都是分布式存储在多个Broker中的。
数据分片
一个Topic可以划分为多个MessageQueue分布在不同Broker上,达到数据分片的目的,并且一个MessageQueue只能够被一个消费者消费,所以指定多个MessageQueue也有利于消费者消费。
RocketMQ中通过MessageQueue将一个Topic的数据拆分为了很多个数据分片,然后在每个Broker机器上都存储一些MessageQueue。从而实现Topic数据的分布式存储。
3.消息写入MessageQueue的机制
生产者会跟NameServer进行通信获取Topic的路由数据。从这些数据中,可以知道一个Topic有几个MessageQueue,哪些MessageQueue在哪台Broker机器上,哪些MessageQueue在另一台机器上。
均匀写入策略
基于MessageQueue实现数据分片的Broker集群中,根据Topic的写入策略不同,每个MessageQueue的数据有多有少或一致。
这里暂时认为生产者会均匀的把消息写入各个MessageQueue,比如这个生产者发送出去了20条数据,那么4个MessageQueue就是每个都会写入5条数据。
高可用
通过让一个Topic中的数据分散在多个MessageQueue中,进而分散在多个Broker机器上,就可以实现RocketMQ集群分布式存储海量的消息数据了。
4.Broker自动容错
容错开关: 在Producer中开启 sendLatencyFaultEnable 这个开关。
场景:当某次访问一个Broker发现网络延迟有500ms,然后还无法访问,那么就会自动回避访问该Broker一段时间。
故障转移:在上面的场景中,可以避免一个Broker故障之后,短时间内生产者频繁的发送消息到这个故障的Broker上去,出现较多次数的异常。而是在一个Broker故障之后,自动回避一段时间不要访问这个Broker,过段时间再去访问他。而这段时间该Master Broker可能已经恢复好了,或者是Slave Broker切换为了Master可以重新提供访问服务了。