消息队列高手课
李玥
美团高级技术专家
52199 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 42 讲
进阶篇 (21讲)
消息队列高手课
15
15
1.0x
00:00/00:00
登录|注册

22 | Kafka和RocketMQ的消息复制实现的差异点在哪?

可用性和数据一致性
动态切换主节点
数据复制到半数以上的节点
可用性和数据一致性
异步复制和同步双写
主从方式
解决主节点宕机的问题
快速选举新的主节点
严格顺序的要求
主-从复制方式确保数据一致性
复制对消费性能影响不大
复制实现方式影响写入性能
RocketMQ和Kafka的复制方式比较
复制方案的取舍
可用性和数据一致性
ZooKeeper选举新的主节点
ISR的数量可配置
分区的复制方式
Dledger复制方式
传统复制方式
高可用
一致性
性能
思考题
总结
Kafka如何实现复制
RocketMQ如何实现复制
消息复制面临的问题
消息复制实现的差异点在哪?

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
之前我在《05 | 如何确保消息不会丢失?》那节课中讲过,消息队列在收发两端,主要是依靠业务代码,配合请求确认的机制,来保证消息不会丢失的。而在服务端,一般采用持久化和复制的方式来保证不丢消息。
把消息复制到多个节点上,不仅可以解决丢消息的问题,还可以保证消息服务的高可用。即使某一个节点宕机了,还可以继续使用其他节点来收发消息。所以大部分生产系统,都会把消息队列配置成集群模式,并开启消息复制,来保证系统的高可用和数据可靠性。
这节课我们来讲一下,消息复制需要解决的一些问题,以及 RocketMQ 和 Kafka 都是如何应对这些问题来实现复制的。

消息复制面临什么问题?

我们希望消息队列最好能兼具高性能、高可用并且还能提供数据一致性的保证。虽然很多消息队列产品宣称三个特性全都支持,但你需要知道,这都是有前置条件的。
首先来说性能。任何的复制实现方式,数据的写入性能一定是不如单节点的。这个很好理解,因为无论采用哪种复制实现方式,都需要数据被写入到多个节点之后再返回,性能一定是不如只写入一个节点的。
需要写入的节点数量越多,可用性和数据可靠性就越好,但是写入性能就越低,这是一个天然的矛盾。不过,复制对消费的性能影响不大,不管采用哪种复制方式,消费消息的时候,都只是选择多副本中一个节点去读数据而已,这和单节点消费并没有差别。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Kafka和RocketMQ是两种常见的消息队列系统,它们在消息复制实现上存在一些差异。消息队列的复制实现需要解决高性能、高可用和数据一致性的矛盾,涉及到写入性能、一致性要求和高可用性的问题。一般采用主从复制方式来保证数据一致性,但在高可用方面需要解决主节点宕机后的快速选举问题。不同的消息队列选择了不同的复制实现方式,各有优缺点。 Kafka采用分区副本机制来实现消息复制,通过将消息分区复制到多个节点来提高可用性和数据可靠性。Kafka的复制机制能够提供较高的写入性能和较好的一致性保证,但在主节点宕机后的选举过程可能会导致服务不可用。另一方面,RocketMQ采用主从复制方式,通过主节点写入数据,从节点复制数据来保证一致性。RocketMQ的复制实现能够提供较好的一致性和可用性,但在写入性能方面可能会受到一定影响。 总的来说,Kafka和RocketMQ在消息复制实现上存在差异,各自的复制机制在高性能、高可用和一致性方面提供的能力也有所不同。阅读本文可以帮助读者了解Kafka和RocketMQ的消息复制实现的差异点,以及它们在解决消息队列复制过程中所面临的挑战和取舍。 RocketMQ提供了传统的主从模式和新的基于Dledger的复制方式,而Kafka提供了基于ISR的更加灵活可配置的复制方式。每种方式都有其优缺点,读者可以根据实际需求做出取舍,然后再去配置消息队列的复制方式。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(34)

  • 最新
  • 精选
  • a、
    5副本,10个分区,至少保持isr集合中有三个broker bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 5 --partitions 10 --topic test  min.insync.replicas=3

    作者回复: 👍👍👍

    2019-09-26
    5
    35
  • kiddkidd
    老师,对于文中“由于消息要至少复制到 2 个节点上才会返回写入成功,即使主节点宕机了,也至少有一个节点上的消息是和主节点一样的”我有个疑问: 假如1主2从3副本条件下,主收到msg1,并复制到从1,之后主又收到msg2,并复制到从2. 然后主节点宕机了,此时从1和从2都跟主不一样啊。请问如何理解?

    作者回复: 消息的复制是按照顺序来复制的,因为msg2在msg1后面,如果说,msg2已经复制到从2上,那从2上一定有msg1,所以不存在你说这种情况。

    2020-01-11
    2
    22
  • WL
    请问一下老师,kafka消息复制中,“Broker只是副本分区的容器,Broker不分主从” 这句话具体怎么理解? 是指一个Broker上可能有Topic1的partition2的从副本和Topic2的partition1的主副本,所以在Broker上不分主从,是这样吗?

    作者回复: 没错,就是这样的。

    2019-10-13
    15
  • 郑勺子
    请问老师~可用于消息中间性能测试的工具有哪些~

    作者回复: 你可以参考一下这个:https://github.com/openmessaging/openmessaging-benchmark/

    2019-09-17
    11
  • 丁小明
    看起来好像新的rocktmq复制方式,就是内置了类似zk一样的一致性协调器。

    作者回复: 是的,RocketMQ新的复制方式采用的也是Raft一致性协议。

    2020-05-05
    9
  • 极客雷
    RocketMQ不满足京东的使用场景吗?

    作者回复: RocketMQ是很优秀的开源MQ,京东的JMQ“年纪”和RocketMQ是差不多的。在当年还没有RocketMQ的时候,其它的MQ又满足不了需求,所以就诞生了JMQ。

    2020-03-21
    2
    3
  • 二货
    所有的 ISR 节点都宕机了,分区就无法提供服务了。你也可以选择配置成让分区继续提供服务,这样只要有一个节点还活着,就可以提供服务 老师,这里ISR节点都宕机了,分区为啥还是正常的,ISR不就是分区副本吗

    作者回复: ISR只是分区的一部分副本,不是全部。 比如,一个分区3副本,ISR可以配置为2。

    2020-05-02
    2
    2
  • 夏目
    老师,这种不是同步方式吗?-- Kafka 在写入消息的时候,采用的也是异步复制的方式。消息在写入到主节点之后,并不会马上返回写入成功,而是等待足够多的节点都复制成功后再返回。

    作者回复: 从请求响应角度来说,是同步请求。 实现方式上,采用的是异步方式来实现的。

    2020-01-09
    2
  • 饭粒
    请教下老师,kafka 使用时是一个节点对应一个 broker 吗?然后 broker 作为分区副本容器存放不同主题-分区的主/从副本。

    作者回复: 是这样的。

    2019-11-16
    2
  • 李先生
    玥哥,有两个问题: 1: 比如kafka,1个主节点2个从节点,一个topic有3个分区。为什么3个主分区会均匀的分布在3个节点上,而不是3个主分区都在主节点上,副本分区在从节点上。或者说这两者有什么区别? 2: kafka是主从模式,读写都在主节点,如果是生产者生产一个消息到主分区1,假如主节点上的分区1是副本分区,这时候这个消息是先写入主节点的副本分区1上吗?

    作者回复: Kafka的Broker并没有主从之分,它就是一个分区的容器,它选举和复制的基本单位是分区,每个分区都会有n个副本(比如说3个),那这三个副本分别位于3个节点上,会选出一个作为Leader分区。所以这些分区均匀分布在所有的Broker让,并且最好让Leader也均匀分布,有助于平均利用每个Broker的资源。

    2020-03-26
    1
收起评论
显示
设置
留言
34
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部