业务方对消息中间件的需求

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

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

功能

功能需求核心的其实就发送消息和消费消息,细化下去,发送需求会有同步发送、异步发送,会有实时消息、定时消息等;消费需求会有各种模式,比如业务方主动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?》的系列文章,所以会先聚焦在核心的功能上不会展开去讨论像消息轨迹的实现之类的(可能会放到很后面)。

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

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

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

原文发布于微信公众号 - MessageQueue(gh_2c8dc9116c24)

原文发表时间:2017-07-01

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT笔记

从构建分布式秒杀系统聊聊重复购买

秒杀时为了公平起见,往往是单个用户只能购买一件商品,但是又要做到不能少买,那么问题来了,如何保证?

2893
来自专栏网络

网站性能测试指标详解

常用的网站性能测试指标有:吞吐量、并发数、响应时间、性能计数器等。 并发数 并发数是指系统同时能处理的请求数量,这个也是反应了系统的负载能力。 响应时间 响应时...

2485
来自专栏后端技术探索

大规模Nginx平台化实践,京东能提供哪些参考经验?

Nginx是优秀的HTTP和反向代理服务器,京东各部门都在广泛使用,但普遍都面临着一些问题:

2002
来自专栏EAWorld

使用消息系统进行微服务间通讯时,如何保证数据一致性

前言 微服务是当下的热门话题,今天来聊下微服务中的一个敏感话题:如何保证微服务的数据一致性。谈到分布式事务,就避免不了CAP理论。 ? CAP理论是指对于一个分...

3805
来自专栏Android 开发者

后续更新 | 减少使用非 SDK 接口以提升稳定性

2424
来自专栏携程技术中心

开源 | 携程Redis多数据中心解决方案-XPipe

作者简介 孟文超,携程技术中心框架研发部高级经理。2016年加入携程,目前主要负责Redis多数据中心项目XPipe。此前曾在大众点评工作,任基础架构部门通信团...

59310
来自专栏互扯程序

5分钟了解swagger

随着互联网技术的发展,现在的网站架构基本都由原来的后端渲染,变成了:前端渲染、先后端分离的形态,而且前端技术和后端技术在各自的道路上越走越远。

2103
来自专栏Java技术交流群809340374

主流的消息队列MQ比较,详解MQ的4类应用场景

消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。

2.7K3
来自专栏ThoughtWorks

别再加端到端集成测试了,快换契约测试吧 | 洞见

正如大家所知,最初QA都是手动执行测试用例,开发人员每修改一个版本,QA就要手动测试一遍,随着功能的不断增加,手动测试重复的工作量越来越大。为了解脱QA重复性劳...

3925
来自专栏FreeBuf

看我如何综合利用3个安全问题成功劫持Flickr账户获得7千美元漏洞赏金

Flickr( flickr.com)为雅虎Yahoo旗下图片和视频分享平台,提供免费及付费数位照片视频储存、分享和线上社交应用服务。本文中作者通过身份认证参数...

2047

扫码关注云+社区

领取腾讯云代金券