业务系统对消息中间件的要求(接上一篇《分布式消息中间件中的一些概念》)

本文涉及的产品
任务调度 XXL-JOB 版免费试用,400 元额度,开发版规格
注册配置 MSE Nacos/ZooKeeper,182元/月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介:   在大型互联网中,主要采用消息中间件来进行业务的解耦和操作的异步化,这也是消息中间件最基础的特点,也是业务系统对消息中间件的最基本需求。   在这个基础之上,本篇来谈一下业务系统从功能、性能等各个方面对消息中间件的需求。

 

在大型互联网中,主要采用消息中间件来进行业务的解耦和操作的异步化,这也是消息中间件最基础的特点,也是业务系统对消息中间件的最基本需求。

 

在这个基础之上,本篇来谈一下业务系统从功能、性能等各个方面对消息中间件的需求。

 

功能

功能需求核心的其实就发送消息和消费消息,细化下去,发送需求会有同步发送、异步发送,会有实时消息、定时消息等;消费需求会有各种模式,比如业务方主动Pull、或者消息中间件Push的模式等等。

 

消息发送

消息发送功能从编程接口的角度出发就只有两个需求:同步发送接口和异步发送接口。

 

从消息类型的角度出发,会有以下几点需求:

  1. 实时消息

  2. 定时消息

  3. 事务消息

实时消息最简单了,Producer发送一条消息,这条消息对Consumer是立即可见的,会尽快被消费掉的。

定时消息则是Producer发出一条消息后,这条消息不是立即可见,可以被消费的,它需要等待一个固定时间之后才能被Consumer进行消息。

事务消息的含义是说它是和业务操作绑定在一起的,要么业务操作成功且消息发送成功,如果业务操作失败,消息是需要回滚的。这里的事务其实就是表明了业务操作是消息是在一个事务内的,要么都成功,要么都失败。

 

对事务消息多说一点。事务消息是个非常有趣的东西,因为业务操作和发送消息是两个完全独立的事情,是一个分布式事务,保证他们的一致性就变得非常困难。操作中如果先发消息再做业务,那么可能出现消息发送成功而业务做失败了,此时就需要撤销消息(这样理解其实事务消息称为可撤销的消息,即如果业务执行失败了,将发送的消息撤销);如果是先做业务再发消息,那么可能出现业务做成功了消息发送失败了,此时就需要撤销业务(先做业务有明显的问题是消息发送的结果除了成功和失败,还会有超时的状态,是无法确认是否发送成功的)。

这里会引申出两阶段提交,第一阶段发送消息,之后等业务完成后执行第二阶段对消息进行提交。对事务消息,之后会专门出一篇文章描述场景和实现方案的。

 

另外消息发送还会有顺序性的要求,消息的消费顺序需要和发送顺序保持一致。

 

消息消费

消费方式上需要提供集群消费和广播消费(这两个概念再上一篇都讲过了)。另外对消息获取的方式也会有特定的需求,比如一些业务方是期望由他们自己主动去获取消息的,另一些会要求以监听的模式,即提供Listener当有新消息时触发Listener(对使用Pull还是Push模式也是非常有意思的一点,在之后会写一篇专门的文章讨论我们我们是怎么选择Pull和Push的)。

 

和发送一样,消费端也需要保证消息顺序(废话,如果只保证发送的顺序,打这个顺序在消费的时候错乱了,那顺序又有什么意义)。

 

除了这些基础需求,消费时还会有位点重置的需求,即可以主动去修改消费位点来重新消费消息。

 

另外从功能上还会有消息跟踪、消息堆积之类的需求。业务方需要知道一条消息的运行轨迹,定位一条消息从产生到经过MQ,再到被消费的完整轨迹。在高峰期,消息需要先堆积在MQ中之后进行消费(就是削峰的作用)。

 

性能

性能就两点:延迟和吞吐。

对业务系统而言,它本身不会容忍在执行消息发送时消耗过多的时间,因为过长的耗时将直接影响它系统的吞吐,所以一般对消息的发送延迟要求都是毫秒级的,平均需要在2ms左右吧。对消费也是一样,对实时性要求比较高的系统响应的会期望消息从发送出来到被消费到的这个时间尽可能的短。

吞吐也是一样,因为直接影响到使用MQ的业务系统的性能,所以也是需要一个超过业务系统吞吐上限的能力。RocketMQ给出的性能指标是10字节的消息单机TPS在7w左右,但是没有给机器指标给出消息延迟之类的指标,笔者也没有测试验证过。

 

可用性

互联网产品我们会经常听到高可用的概念,会要求7*24小时运行,可用性达到99.99%之类的描述。可用性是指系统可以提供服务的正常运行时间和总运行时间的比值。

对业务系统而言,中间件是他们依赖的服务,当然是希望可用性越高越好,但是现实中网络是会故障的,机器是会宕机的,磁盘是会损坏的。所以对消息中间件而言,一般会要求99.99%的可用性之类的,即365天内不可用的时间不允许超过1个小时。

为了满足可用性的要求,系统需要做备份等等,这些在之后的文章中也会展开去讨论。

 

可靠性

在消息中间件中,业务方对可靠性的要求主要集中在消息会不会丢失。消息不丢失也是对消息中间件最最基础的要求。

 

以上内容参考了部分RocketMQ的文档和阿里云上MQ的文档。

 

结语

这篇文章简单的概述了一下消息中间件的一些需求,部分需求并非核心需求,比如消息轨迹这样的需求可能是在你的消息中间件已经完成的基础下再去谈的。

 

公众号在计划写文章时的出发点是去写一个类似《从入门到XXX》的系列文章,所以会先聚焦在核心的功能上不会展开去讨论像消息轨迹的实现之类的(可能会放到很后面)。

 

另外一点也在考虑要不要同时去写一个讨论幂等、一致性之类的分支,毕竟好像这几篇都太基础了,没啥干货。

 

最后,下一篇可能会写如何满足可用性、可靠性的需求,即在可用性和可靠性的基础上去讨论系统架构的选型,暂时叫《消息中间件架构讨论》吧(题目取得有点大了)。

 

欢迎关注此公众号交流消息中间件相关的技术、经验等。

如果本文对您有帮助,点一下右下角的“推荐”
相关实践学习
快速体验阿里云云消息队列RocketMQ版
本实验将带您快速体验使用云消息队列RocketMQ版Serverless系列实例进行获取接入点、创建Topic、创建订阅组、收发消息、查看消息轨迹和仪表盘。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
4月前
|
Kubernetes 大数据 调度
Airflow vs Argo Workflows:分布式任务调度系统的“华山论剑”
本文对比了Apache Airflow与Argo Workflows两大分布式任务调度系统。两者均支持复杂的DAG任务编排、社区支持及任务调度功能,且具备优秀的用户界面。Airflow以Python为核心语言,适合数据科学家使用,拥有丰富的Operator库和云服务集成能力;而Argo Workflows基于Kubernetes设计,支持YAML和Python双语定义工作流,具备轻量化、高性能并发调度的优势,并通过Kubernetes的RBAC机制实现多用户隔离。在大数据和AI场景中,Airflow擅长结合云厂商服务,Argo则更适配Kubernetes生态下的深度集成。
580 34
|
4月前
|
消息中间件 存储 Kafka
分布式消息中间件设计与实现
本文深入探讨了消息中间件的核心功能实现与高并发、高可用设计。在生产者设计中,涵盖消息构造、序列化、路由策略及可靠性保障(如ACK机制)。消费者部分分析了拉取/推送模式、分区分配与消息确认机制。同时,Broker作为核心组件,负责消息路由、存储和投递,并通过索引技术实现快速检索。 高并发设计方面,重点讨论了文件存储(顺序写入、分段存储)、日志结构存储及负载均衡策略(如哈希分区、轮询分区)。为确保高可用性,文章详细解析了主从复制、故障转移机制以及同城/异地多活容灾方案。
|
3天前
|
存储 算法 安全
“卧槽,系统又崩了!”——别慌,这也许是你看过最通俗易懂的分布式入门
本文深入解析分布式系统核心机制:数据分片与冗余副本实现扩展与高可用,租约、多数派及Gossip协议保障一致性与容错。探讨节点故障、网络延迟等挑战,揭示CFT/BFT容错原理,剖析规模与性能关系,为构建可靠分布式系统提供理论支撑。
35 2
|
9天前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的"神经网络",强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
38 1
|
18天前
|
机器学习/深度学习 算法 安全
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
新型电力系统下多分布式电源接入配电网承载力评估方法研究(Matlab代码实现)
|
2月前
|
数据采集 缓存 NoSQL
分布式新闻数据采集系统的同步效率优化实战
本文介绍了一个针对高频新闻站点的分布式爬虫系统优化方案。通过引入异步任务机制、本地缓存池、Redis pipeline 批量写入及身份池策略,系统采集效率提升近两倍,数据同步延迟显著降低,实现了分钟级热点追踪能力,为实时舆情监控与分析提供了高效、稳定的数据支持。
分布式新闻数据采集系统的同步效率优化实战
|
4月前
|
消息中间件 存储 中间件
分布式消息中间件基础
消息中间件是一种基于异步消息传递的分布式系统通信工具,核心功能包括消息传输、存储、路由与投递,能够实现系统解耦、异步处理和流量削峰。其主要组件包括生产者、消费者、Broker、主题/队列等,支持点对点和发布-订阅两种消息模型。主流中间件如Kafka(高吞吐)、RabbitMQ(灵活路由)、RocketMQ(事务支持)各有特色,适用于不同场景。此外,中间件还涉及多种协议(AMQP、MQTT等)、可靠性传输机制(持久化、确认机制)、顺序性与重复性问题解决以及事务支持(两阶段提交、本地消息表等)。选择中间件需根据业务需求权衡性能、功能和运维成本。
|
8月前
|
存储 运维 安全
盘古分布式存储系统的稳定性实践
本文介绍了阿里云飞天盘古分布式存储系统的稳定性实践。盘古作为阿里云的核心组件,支撑了阿里巴巴集团的众多业务,确保数据高可靠性、系统高可用性和安全生产运维是其关键目标。文章详细探讨了数据不丢不错、系统高可用性的实现方法,以及通过故障演练、自动化发布和健康检查等手段保障生产安全。总结指出,稳定性是一项系统工程,需要持续迭代演进,盘古经过十年以上的线上锤炼,积累了丰富的实践经验。
621 7
|
8月前
|
存储 分布式计算 Hadoop
基于Java的Hadoop文件处理系统:高效分布式数据解析与存储
本文介绍了如何借鉴Hadoop的设计思想,使用Java实现其核心功能MapReduce,解决海量数据处理问题。通过类比图书馆管理系统,详细解释了Hadoop的两大组件:HDFS(分布式文件系统)和MapReduce(分布式计算模型)。具体实现了单词统计任务,并扩展支持CSV和JSON格式的数据解析。为了提升性能,引入了Combiner减少中间数据传输,以及自定义Partitioner解决数据倾斜问题。最后总结了Hadoop在大数据处理中的重要性,鼓励Java开发者学习Hadoop以拓展技术边界。
267 7
|
9月前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
531 4

热门文章

最新文章