RocketMQ/Kafka等消息队列复制的最佳实践

简介: RocketMQ/Kafka等消息队列复制的最佳实践

MQ

  • 在Pro、Con端,依靠业务代码,配合请求确认机制保证
  • 在服务端,采用持久化和复制

保证不会丢消息。

把消息复制到多节点,可

  • 解决丢消息问题
  • 保证消息服务的HA

所以都会把MQ配置成集群模式,并开启消息复制。

那么消息复制需要解决哪些问题呢?

1 消息复制的指标

期望MQ具备高性能、高可用和数据一致性。很多MQ都声明这些特性全部支持,但都有前置条件。

1.1 性能

无论采用哪种复制,都需数据被写到多节点后再返回,性能一定不如只写入一个节点。

需要写入节点越多,可用性和数据可靠性越好,但写性能就越低。

不过,复制对消费的性能影响不大,不管采用哪种复制方式,消费消息时,都只选择多副本中一个的节点去读,和单节点消费无异。

1.2 一致性

MQ对数据一致性要求包括:


不丢消息

严格顺序

若要确保数据一致性,必须采用主从复制。


主从模式下,数据先写到主节点,从节点只从主节点上复制,若出现主从数据不一致,须以主节点数据为准。


这里的主节点并非不可变,在很多复制实现中,当主节点出现问题,其他节点可通过选举,变成主节点。只要保证,在任一时刻,集群的主节点数不能超过1个,即可确保数据一致性。

1.3 高可用

须采用主从复制,高可用需解决的就是,当某个主节点宕机,尽快再选个主节点来继位。

下面看通用的分布式系统设计实现方案:

1.3.1 实现方式

1.3.1.1 管理服务

使用三方服务管理这些节点,发现某主节点宕机,由管理服务指定一个新的主节点。

但引入服务会带来一系列问题,比如管理服务本身的高可用、数据一致性如何保证?就如 redis 哨兵。

1.3.1.2 自选举

有的MQ选择自选举,由存活节点投票选举新的主节点。

  • 优点
    无外部依赖,自我管理
  • 缺点
    投票的实现算法都复杂,且选举过程较慢,几s至几十s,在选出新主节点前,服务一直不可用。
  • 大部分复制实践,都不会选择把消息写入全部副本再返回确认,因为这样虽可保证数据一致性,但一旦这些副本中有任一宕机,写入就会卡死。

若只把消息写入部分副本就认为写入成功并返回确认,即可避免卡死且性能好些。

那写入多少个副本算写入成功?假设集群采用1主2从3副本:


若要求消息写入2副本算就成功,则3副本最多允许宕机1个,否则无法提供服务

若要求写1副本,只要消息写入到主节点就算成功,那3副本可允许宕机2个,系统依然可服务,可用性更好

但可能主节点有部分消息还没及时复制到任一从节点,主节点宕机了,这时就会丢消息,数据一致性失去保证。

不同MQ选择不同复制实现,有各自优缺点。

2 RocketMQ复制

2.1 传统复制

RocketMQ复制的基本单位是Broker,服务端进程。采用主从复制,通常配置成一主一从,也支持一主多从。

2.1.2 复制方式

异步复制

消息先发送到主节点,就返回“写入成功”,然后再把消息异步复制到从节点。

同步双写

消息同步双写到主从节点,主从都写成功,才返回“写入成功”。


这两种方式区别是 写入多少副本再返回写入成功 :


异步复制需副本数1

同步双写需副本数2

若在返回“写入成功”前,需要写入的副本数不够多,就会丢消息。


那RocketMQ采用异步复制会不会丢消息?不会。


为何不会丢消息?

RocketMQ的Broker主从关系通过配置固定,不支持动态切换。


若主节点宕机,生产者就不能再生产消息,消费者可自动切换到从节点继续消费。

这时,即使有一些消息没来得及复制到从节点,这些消息依然躺在主节点磁盘,除非主节点磁盘坏了,否则等主节点重新恢复服务,这些消息依然可继续复制到从节点,也可继续消费,不会丢消息,消息顺序也没问题。


这种主从复制方式,通过牺牲可用性,得到较好的性能和数据一致性。

可用性

一对主从节点可用性不行,那就多对。

  • 功能
    RocketMQ支持把一个主题分布到多对主从节点,每对主从节点中承担主题中的一部分队列。
  • 表现
    若某主节点宕机,自动切换到其他主节点继续发消息。
  • 解决如下问题:
  • 可用性
  • 还可通过水平扩容提升Topic性能

旧复制缺陷

由于topic层无法保证严格顺序,必须指定队列发消息,对任一队列,一定是落在一组特定主从节点,若该主节点宕机,其他主节点无法替代这主节点,否则就无法保证严格顺序

因此这种复制模式的严格顺序和高可用只能选其一

2.2 新复制

2018年底引入Deldger,一种全新复制方式。

Dledger在写入消息时,要求至少消息复制到半数以上节点后,才给客户端返回写成功,且支持选举动态切换主节点。

执行原理

3节点为例。

  • 当主节点宕机,2从节点会通过投票选出1新主节点,相比主从复制,解决了可用性
  • 由于消息要至少复制到2节点才返回写成功,即使主节点宕机,也至少有一节点消息是和主节点一致。选举时,总会把数据和主节点一样的从节点选为新主,保证了数据一致性,既不会丢消息,还可保证严格顺序。

缺点

  • 选举过程中不能提供服务
  • 至少需3节点才能保证数据一致性
  • 3节点时,只能保证1节点宕机时可用,若2个节点同时宕机,即使还有1个节点存活也无法提供服务,资源利用率较低
  • 由于至少要复制到半数以上的节点才返回写入成功,不如主从异步复制快

3 Kafka 复制

复制的基本单位是分区。每个分区的几个副本间构成一个小复制集群。

Broker只是这些分区副本的容器,所以Kafka的Broker不分主从。

分区的多个副本中采用一主多从。

写入消息时,异步复制。消息在写到主节点后,并不会马上返回写入成功,而是等待足够多节点都复制成功后再返回。

“足够多”由用户定。对应:ISR(In Sync Replicas),“保持数据同步的副本”。ISR的数量可配,ISR中包含主节点。


Kafka使用ZooKeeper监控每个分区的多节点,发现某分区主节点宕机:


Kafka会利用ZooKeeper选个新主节点,这解决可用性

选举时,会从所有ISR节点选新主节点,这保证数据一致性

默认如果所有ISR宕机,分区就无法提供服务。也可以选择配置成让分区继续提供服务,这样只要有一个节点活,就可提供服务,代价是无法保证数据一致性,会丢消息。


Kafka的这种高度可配置的复制方式


优点

非常灵活,可自定义配置这些复制参数,在可用性、性能和一致性这几方面做业务取舍

缺点

学习成本较高

4 总结

没有完美复制方案,要根据业务需求,评估高性能、高可用和一致性。

目录
相关文章
|
26天前
|
消息中间件 监控 大数据
优化Apache Kafka性能:最佳实践与调优策略
【10月更文挑战第24天】作为一名已经对Apache Kafka有所了解并有实际使用经验的开发者,我深知在大数据处理和实时数据流传输中,Kafka的重要性不言而喻。然而,在面对日益增长的数据量和业务需求时,如何保证系统的高性能和稳定性成为了摆在我们面前的一个挑战。本文将从我的个人视角出发,分享一些关于如何通过合理的配置和调优来提高Kafka性能的经验和建议。
63 4
|
10天前
|
消息中间件 大数据 Kafka
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
本文深入探讨了消息队列的核心概念、应用场景及Kafka、RocketMQ、RabbitMQ的优劣势比较,大厂面试高频,必知必会,建议收藏。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:Kafka、RocketMQ、RabbitMQ 的优劣势比较
|
26天前
|
消息中间件 Java Kafka
初识Apache Kafka:搭建你的第一个消息队列系统
【10月更文挑战第24天】在数字化转型的浪潮中,数据成为了企业决策的关键因素之一。而高效的数据处理能力,则成为了企业在竞争中脱颖而出的重要武器。在这个背景下,消息队列作为连接不同系统和服务的桥梁,其重要性日益凸显。Apache Kafka 是一款开源的消息队列系统,以其高吞吐量、可扩展性和持久性等特点受到了广泛欢迎。作为一名技术爱好者,我对 Apache Kafka 产生了浓厚的兴趣,并决定亲手搭建一套属于自己的消息队列系统。
45 2
初识Apache Kafka:搭建你的第一个消息队列系统
|
30天前
|
消息中间件 JSON Java
开发者如何使用轻量消息队列MNS
【10月更文挑战第19天】开发者如何使用轻量消息队列MNS
73 4
|
25天前
|
消息中间件 存储 Kafka
MQ 消息队列核心原理,12 条最全面总结!
本文总结了消息队列的12个核心原理,涵盖消息顺序性、ACK机制、持久化及高可用性等内容。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
|
25天前
|
消息中间件 存储 监控
ActiveMQ、RocketMQ、RabbitMQ、Kafka 的区别
【10月更文挑战第24天】ActiveMQ、RocketMQ、RabbitMQ 和 Kafka 都有各自的特点和优势,在不同的应用场景中发挥着重要作用。在选择消息队列时,需要根据具体的需求、性能要求、扩展性要求等因素进行综合考虑,选择最适合的消息队列技术。同时,随着技术的不断发展和演进,这些消息队列也在不断地更新和完善,以适应不断变化的应用需求。
70 1
|
1月前
|
消息中间件 安全 Java
云消息队列RabbitMQ实践解决方案评测
一文带你详细了解云消息队列RabbitMQ实践的解决方案优与劣
72 9
|
29天前
|
消息中间件
解决方案 | 云消息队列RabbitMQ实践获奖名单公布!
云消息队列RabbitMQ实践获奖名单公布!
|
1月前
|
消息中间件 存储 弹性计算
云消息队列RabbitMQ实践
云消息队列RabbitMQ实践
|
1月前
|
消息中间件 存储 监控
解决方案 | 云消息队列RabbitMQ实践
在实际业务中,网站因消息堆积和高流量脉冲导致系统故障。为解决这些问题,云消息队列 RabbitMQ 版提供高性能的消息处理和海量消息堆积能力,确保系统在流量高峰时仍能稳定运行。迁移前需进行技术能力和成本效益评估,包括功能、性能、限制值及费用等方面。迁移步骤包括元数据迁移、创建用户、网络打通和数据迁移。
66 4

相关产品

  • 云消息队列 Kafka 版
  • 云消息队列 MQ
  • 下一篇
    无影云桌面