RocketMQ架构分析
最新回答
指尖花凉忆成殇
2021-08-24 21:06:01
kafka是依靠Zookeeper进行集群选举的，在rocketMQ的同样位置上是NameServer，这个Nameserver仅仅是注册服务，没有选举能力。每个broker都和NameServer进行连接，通过心跳维持状态。
producer和consumer定时到Nameserver拉取broker信息，并且和自己所消费的broker建立连接。这就和微服务的体系一模一样了。
那么rocketMQ的集群选举怎么实现的呢，通过集成了Dledge实现，Dledge是个jar包，实现了raft算法。
如图，topic可在多个broker上形成分片，producer可写数据到不通的分片，分片信息也可以由不同的group进行消费。
如下介绍存储，rocketMQ可配置主备，形成主备复制。
http://rocketmq.apache.org/rocketmq/how-to-support-more-queues-in-rocketmq/
介绍了rocketMQ存储设计初衷，和kafka存储不同，kafka在每个partition中存储了数据，而RocketMQ将实际消息集中存储，在messageQueue中存储的是元数据信息，通过元数据信息可以索引到CommitLog。对于保存的数据，每天会删除数据；如果磁盘满，超过设置阈值，则不允许写入数据。
RocketMQ的设计确保了消息的并发处理能力，但是有时候，消息是有状态的，即有顺序，RocketMQ怎么实现呢？
发送到临时缓存，到达延迟时间后由delay service路由给topic。
如果消费返回了consumer_later，则如上述延迟消息一样，会延迟一段时间，进入死信队列，消费死信队列，重新处理。
如果业务规模小，不会改源码，就选用RabbitMQ；如果业务规模大，不允许丢消息，追求效率高，用RocketMQ；如果业务规模大，运行少量丢消息，吞吐量大，用Kafka；如果用于大数据，毫无疑问选kafka。
热门标签
