Ethan_199402的博客

RocketMQ 概念特性，架构设计解读

导语 | Pulsar作为下一代消息中间件的典型代表，在设计和实现上面都具备很好的前瞻性，综合考量了业界现存的一些比较常用的、优秀的消息中间的架构设计、适用场景、运营中的问题等，如目前用的比较多的Kafka、Rocketmq、Inlong-TubeMQ等。本文仅从设计角度出发，说明下Pulsar与Kafka、Rocketmq及腾讯开源的Inlong-TubeMQ在实现上的几点区别和可能遇到的问题，供大家参考。一、云原生多租户设计（一）分级命名Pulsar原生支持多租户设计，非常适合作为云产品进行管理。

我们直接Consumer启动的源码开始看起，先看Consumer的启动方法start() public synchronized void start() throws MQClientException { switch (this.serviceState) { //省略代码 //srart方法 mQClientFactory.start();

说到消息的持久化，笔者因为对kafka了解在先，于是首先的疑问是：消息是放在内存吗？这一点是不可能的，任何一个成熟的mq，消息都是持久化的，放内存不可能存贮那么多的消息消息是放在队列里面吗？答案是不是的，kafka的消息持久化在分区，而rocketMq的消息持久化在commitLog中那么rocketMq是不是也像kafka那样分块存储消息呢？如果所有消息全都存放到一个文件中，消息检索会很耗时，过期消息的清理也会很麻烦，所以消息肯定要进行多文件存储。到底如何实现呢？每个Broker都对应有一

为什么kafka性能非常高1.使用到零拷贝技术 属于linux操作系统内核自带；参考文章2.顺序读写kafka 属于日志存储系统实际将消息直接追加在segment 后面，将一个大的日志文件拆分成n多个小不同segment 文件，在访问的时候就可以提高效率设计原理：segment 分段设计+稀疏索引算法（查找）不会对每个msg建立索引。3.分区模型架构提高吞吐量动态的消费者扩容与缩容消息顺序一致性的问题 消息落地到同一个分区中，最终被一个消费者消费。在kafka中建议：相同分组中，

由于之前线上发生了很严重的消息堆积问题，所以研究了一下rocket的发送源码，这里主要研究消息发送：生产者在发送消息的时候，会根据消息的Topic，选出对应路由信息，再挑选出某个Queue，将消息发送至Queue对应的Broker。消息对应的Topic信息以及具体内容被封装在了Message中，并交由DefaultMQProducer，调用send（）进行发送。DefaultMQProducer 只是一个面向调用方的代理，真正的生产者是DefaultMQProducerImpl，而消息发送的具体实现，便在

RocketMQ由哪些角色组成，每个角色作用和特点是什么？Nameserver 无状态，动态列表；这也是和zookeeper的重要区别之一。zookeeper是有状态的。前者保证AP,后者保证CP，NameServer 每个节点相互之间没有数据过程、都是独立的 （ap模式）保证可用性、不保证每个NameServer 数据的一致性问题。存储Broker 的IP和端口号 主题信息、集群信息 过滤器等Producer 消息生产者，负责发消息到Broker。采用轮询算法连接nameserver 如果能够获取到