后端常用消息中间件RocketMq与kafka，11个不同点总结，只看这一篇文章就够了（吐血整理）

RocketMq与kafka不同点总结！

1.RocketMQ批量发送做的不好,无提供压缩机制

Kafka：

1.批量发送
buffer.memory
RecordAccumulator 缓冲区总大小，默认 32m。
batch.size 缓冲区每一批数据最大值，默认 16k。适当增加该值，可以提高吞吐量，但是如果该值设置太大，会导致数据 传输延迟增加。
Kafka比如设置延时5ms（默认为0ms）或者满了就发，更灵活
而如果批量里那个出现问题就去在应答区单独重试，而不是整批重试
2.支持压缩机制，
生产端压缩，消费者解压缩
消息压缩（默认不压缩）
在对大数据处理上，瓶颈往往体现在网络上而不是CPU（压缩和解压会耗掉部分CPU资源）。
RocketMq没有封装好的方法去压缩消息
3.消费者批量发

RocketMq（kafka快）

没有默认批量机制
可以批量发送大小
默认情况下，一批发送的消息总大小不能超过4MB字节。如果想超出该值，有两种解决方案：拆分成小个4MB，不可以设置4MB大小，没有kafka灵活
问题：若出现了问题，那么本批次所有消息都需要全部重新拉取。
2.RocketMq没有封装好的API去压缩消息

2.nameServer注册中心与zookeeper区别

nameServer（全局无序）

优点： NameServer 集群搭建简单，扩容简单。
缺点：对于 Broker ，必须明确指出所有 NameServer 地址。否则未指出的将不会去注册。也正因为如此， NameServer 并不能随便扩容。因为，若 Broker 不重新配置，新增的 NameServer 对于 Broker 来说是不可见的，其不会向这个 NameServer 进行注册。
Broker 节点为了证明自己是活着的，为了维护与 NameServer 间的长连接，会将最新的信息以 心跳包 的 方式上报给 NameServer ，每 30 秒发送一次心跳。
如何保证nameServer节点同步？
在Broker节点启动时，轮询 NameServer 列表，与每个 NameServer 节点建立长连接，发起注册 请求。在 NameServer 内部维护着⼀个 Broker 列表，用来动态存储 Broker 的信息。
NameServer路由信息有四个Map，
topic信息，brokerIp等信息，集群信息，心跳具体信息

Zookeeper（有序）

注意，这是与其它像 zk 、 Eureka 、 Nacos 等注册中心不同的地方。
这种 NameServer 的无状态方式，有什么优缺点：
无状态：即 NameServer 集群中的各 个节点间是无差异的，各节点间相互不进行信息通讯。
Zookeeper各个节点之前都有监控，宕机就通知所有节点。可以动态增加brok