RocketMQ VS Kafka(一):nameserver & zk

Kafka 和 RocketMQ 作为2款知名度较高的高性能的消息中间件,究竟有何相同或异同之处?项目中该如何选型? 最近一段时间一直在学习 RocketMQ 的源代码,过程中记录了一些两者的差异,列举一二仅供大家参考。

架构的差异

Kafka的架构

盗图一张

RocketMQ的架构

继续盗图一张

架构中的第一眼差异:RocketMQ 使用 Nameserver,而 Kafka 使用 ZK 作为各自的服务注册中心,两者正是体现了AP和CP之间的区别。阿里血缘的中间件,从来都认为服务发现相关数据应该是可用性大于一致性,比如 nacos 就是秉承了这种理念针对服务发现和配置设计了2套不同一致性实现(Distro 和 JRaft)。理由有几点:

1. 服务注册中心的服务发现相关数据如果不一致,比如一部分节点数据已经过期,会怎么样呢?无非就是客户端调用流量不均衡或者调用失败。如果发生了调用失败,客户端一定要有适合 failover 或者退避策略。除非所有的服务节点数据均无效,否则总有一个节点可以提供服务。 因此,相较于服务中心不可用而言,宁愿选择客户端多做一些工作来弥补服务数据的不一致性。

2. 一致性意味着持久化,而服务发现数据不需要持久化。通常服务提供方会与服务注册中心保持心跳连接,会一直更新注册中心的地址数据。因此如果注册中心重启,销毁了内存中所有服务数据。 不一会就会有心跳过来恢复之前的数据。

所以,Nameserver 没有一致性协议,没有持久化,没有 quorum,不需要线性一致性!  每个 Nameserver 实例均是独立个体,彼此不知道对方存在。Broker,生产者,消费者拥有全量 nameserver 实例列表,比如 broker 发送心跳,需要向全量 nameserver 发送。注意,这里 nameserver 保存 broker 的路由信息和地址信息,不会保存生产者或消费者的任何信息

总结

使用 NameServer 的优势:简单,高性能,高可用(最少只需一个节点存活即可),维护简单。定制的专用 broker 注册中心,日后可以做定制化,比如类似于 nacos 的阈值保护之类的功能

劣势:客户端(消费者和生产者)会看到过期的 broker 数据,需要有应对策略,增加了复杂性

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值