性能文章>【全网首发】MQ系列9:高可用架构分析>

【全网首发】MQ系列9:高可用架构分析原创

1年前
344125

MQ系列1:消息中间件执行原理
MQ系列2:消息中间件的技术选型
MQ系列3:RocketMQ 架构分析
MQ系列4:NameServer 原理解析
MQ系列5:RocketMQ消息的发送模式
MQ系列6:消息的消费
MQ系列7:消息通信,追求极致性能
MQ系列8:数据存储,消息队列的高可用保障

1 介绍

消息中间件是指在分布式系统中完成消息的发送和接收的基础软件。
消息中间件也可以称消息队列(Message Queue / MQ),互联网场景中经常使用消息中间件进行消息路由、订阅发布、异步处理等操作,来缓解系统的压力。
引入消息队列主要是为了解决如下问题的:
1、解耦 :如订单系统,可以通过消息队列把削减库存的工作交给库存系统去处理,而不用等实时响应。
2、执行有序性:先进先出原理,按照进入消息队列的顺序处理业务事件。
3、消息路由 :按照不同的规则,将队列中消息发送到不同的业务服务中。
4、异步处理 :将一些无需实时响应结果的计算放到异步中,提升系统的吞吐率。
5、削峰 :将峰值期间的操作削减,比如整个操作流程包含12个步骤,后11个步骤非强关注结果的数据,可以放在消息队列中。
既然本身就是为了解决大流量场面而设计的,那他自身的稳定性、健壮性就显的无比重要,下面我们来看看消息队列怎么去保证可用性的。

2 消息队列的基本构成

分析高可用特性前先复习下消息队列的基本组件,无论是哪一种类型的消息队列,基本都包含以下构成:

  • Broker:消息服务器,以服务的形式运行在server端,给各个业务系统提供核心消息数据的中转服务。
  • Producer:消息生产者,业务的发起方,负责生产消息传输给broker。
  • Consumer:消息消费者,业务的处理方,负责从broker获取消息并进行业务逻辑处理
  • Topic:主题模块,发布/订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅者,实现消息的广播
  • Queue:队列,PTP模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收。
  • Message:消息体,根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输。

image.png

上图中以kafka为例子,这是典型的集群模式,<font color="#ff0000">Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker,Consumer使用pull模式从broker订阅并消费消息</font>。

  • producer 负责生产消息
  • consumer 负责消费消息
  • broker 消息服务器,提供消息核心的处理工作
  • zookeeper 用于生产者和消费者的注册与发现

3 高可用性架构保证

了解了一个消息队列的构成之后,我们来看看这种结构是怎么保障高可用性的。
首先,高可用是指系统的出错概率和无故障运行时长,从消息队列角度出发,至少要保证一下几点:

  • 低消息丢失率:消息可靠性也是衡量消息中间件好坏的一个关键因素,尤其是在金融支付领域,消息可靠性尤为重要。

  • 低故障率:消息中间件的可用性是指无故障运行的时间百分比,通常用几个 9 来衡量,如 99.99% 就是一个不错的指标。

  • 多副本容错能力:一般会要求多副本及强一致性,多副本可以保证在 master 节点宕机异常之后可以提升 slave 作为新的 master 而继续提供服务来保障可用性。

3.1 RocketMQ

以为RocketMQ为例,集群模式如下:

  • 多master 模式
  • 多master多slave异步复制模式-
  • 多 master多slave同步双写模式。
  • Name Service 集群: RocketMQ 的 "中央大脑 " , RocketMQ 的服务注册中心,集群模式确保它的可用性。
  • Produer 集群
  • Consumer 集群:避免单例的消费服务故障导致消息堆积。
    多master 多slave模式部署架构图:
    image.png

Producer 与 NameServer集群中的其中一个节点(随机或者RR选择)建立长连接,定期从 NameServer 获取 Topic 路由信息,既可以从 Broker Master 订阅消息,也可以从 Broker Slave 订阅消息。

3.2 Kafka

Kafka集群中包含如下组成部分:

  • 几个消息生产者Producer(可以是业务的Web程序、定时任务服务,其他下游服务的请求等)
  • 一个broker组(Kafka支持横向扩展,一般来说broker数量越多,集群吞吐率越高)
  • 一个消费组 Consumer Group,在资源充足的情况下,消费者越多,消费效率越高,性能也就越好
  • 一个Zookeeper集群:保证消费者和生产者的注册和订阅,避免业务之间的耦合,也提高了可用性。
    image.png
    两个关键点:
  1. Kafka通过Zookeeper管理集群配置,选举leader,以及在Consumer Group发生变化时进行rebalance。
  2. Producer使用push模式将消息发布到broker,Consumer使用pull模式从broker订阅并消费消息。

4 总结

上面介绍了简历高可用消息队列架构的条件,以及RocketMQ和Kafka实现方案。具体高可用性特性方面(如 消息顺序性保障、消息幂等性保障、消息安全性保障、消息事务性保障),我们会在后面的章节中详细的介绍。

欢迎关注公众号,bat一线资深研发、架构师技术分享!
image.png

点赞收藏
Pinocao
请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

Redis stream 用做消息队列完美吗?

Redis stream 用做消息队列完美吗?

Netty源码解析:writeAndFlush

Netty源码解析:writeAndFlush

5
2