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