多看多听多总结

RocketMQ和Kafka到底选哪个

rocketmq中broker的端口

消息拉取采用单线程形式，便于消息的顺序拉取默认批量取32个，出现性能考虑，减少网络请求。不能保证会拉取到32个，因为消息队列中的存放的是topic-queueid对应的索引，会包含多个tag，而消息消费时根据tag来过滤。消息基于tag过滤时，在broker端会根据tagscode（tag的哈希值）作一次过滤 ，而在cosummer端作过滤是为了解决tag哈希冲突。消息拉取完后，将消息放到并发消息消费线程池来处理，消息拉取线程继续下一轮拉取请求。并发消息消费会出现重复消息情况：(1)在新

1、组件结构图

1、类层次图

1、broker启动启动逻辑在BrokerStartup和BrokerController中，其时序图为

1、类层次结构

NameServer接收其它角色报上来的状态，然后根据请求返回相应的状态。首先把执行线程池创建好，默认是8个线程。同时创建一个ScheduledExecutorService，周期性执行两个任务，一个是10s扫描失效的broker,一个是10m打印配置信息。创建负责网络通信的NettyRemotingServer，负责监听broker,producer,consumer发过来的请求，根据请示的命令来调用不同的processor来处理。这些不同的处理逻辑放到上面初始化的线程池中执行。this.remot

NamesrvStartup是模块的启动入口，NamesrvController是协调模板的功能1、解析命令行参数主要 是-c和-p参数。-c指定配置文件，包含NamesrvConfig及NettyServerConfig,这两个类方法的set方法指定的属性，在没有指定NettySeverConfig的监听端口时，默认监听端口是9876。-p来指定是否打印配置项，在指定些选项时，直接退出。public static NamesrvController createNamesrvControl.

1、体系结构（1）名称服务器：主要 是存储broker及topic元数据，并且给producer,consumer提供查询broker信息（2）broker ：主要是存储消息，接收producer消息存储，consumer从这里取消息（3）producer:主要是向broker发送由业务应用生成的消息（4）consumer：主要是从broker拉取消息，将其输入业务应用2、整体流程(1)启动NameServer,起来后监听端口，等待producer,broker,consum