消息中间件应用的常见问题及优化方案

消息中间件应用的常见问题及优化方案_第1张图片

前言

消息队列(MQ)中间件已经普及很多年了,在互联网应用中,通常稍大一些的应用,我们都可以见到MQ的身影。当前市面上有很多中消息中间件,包括但不限于RabbitMQ、RocketMQ、ActiveMQ、Kafka(流处理中间件) 等。很多开发人员已经熟练地掌握了一个或者多个消息中间件的使用。但是仍然有一些小伙伴们对消息中间件不是特别熟悉,因为各种原因不能深入的去学习了解个中原理和细节,导致使用的时候可能出现这样那样的问题。在这里,我们就针对消息队列中间件使用中的典型问题作一番分析(包括顺序消息、可靠性保证、消息幂等、延时消息等),并提供一些解决方案。

消息中间件应用背景

消息中间件基本思想

我们在单个系统中,一些业务处理可以顺序依次的进行。而涉及到跨系统(有时候系统内部亦然)的时候,会产生比较复杂数据交互(也可以理解为消息传递)的需求,这些数据的交互传递方式,可以是同步也可以是异步的。在异步传递数据的情况下,往往需要一个载体,来临时存储与分发消息。在此基础上,专门针对消息接收、存储、转发而设计与开发出来的专业应用程序,都可以理解为消息队列中间件。

引申一下:如果我们自己简单的使用一张数据库表,来记录数据,然后接受数据存储在数据表,通过定时任务再将数据表的数据分发出去,那么我们已经实现了一个最简单的消息系统(这就是本地消息表)。

我们可以认为消息中间件的基本思想就是 利用高效可靠的消息传递机制进行异步的数据传输。在这个基本思想的指导下,不同的消息中间,因为其侧重场景目的不同,在功能、性能、整体设计理念上又各有差别。

消息队列(MQ)本身是实现了生产者到消费者的单向通信模型,RabbitMQ、RocketMQ、Kafka这些常用的MQ都是指实现了这个模型的消息中间件。目前最常用的几个消息中间件主要有,RabbitMQ、RocketMQ、Kafka(分布式流处理平台)、Pulsar(分布式消息流平台)。这里我将两个流处理平台纳入其中了, 更早的一些其他消息中间件已经慢慢淡出视野。业务选型的时候我们遵循两个主要的原则:最大熟悉程度原则(便于运维、使用可靠)、业务契合原则(中间件性能可以支撑业务体量、满足业务功能需求)。

这几个常用的消息中间件选型对比,很容易找到,这里就不详细描述了。大概说一下:Pulsar目前用的不如 RabbitMQ、RocketMQ、Kafka多。RabbitMQ主要偏重是高可靠消息,RocketMQ性能和功能并重,Kafka主要是在大数据处理中应用比较多(Pulsar比较类似)。

引入消息中间件的意义

我们先简单举例介绍一下异步、解耦、削峰的意义与价值(参考下面这张流程图):
对于一个用户注册接口,假设有2个业务点,分别是注册、发放新人福利,各需要50ms去处理逻辑。如果我们将这两个业务流程耦合在一个接口,那么总计需要100ms处理完成。但是该流程中,用户注册时候,可以不用关心自己的福利是否立即发放,只要尽快注册成功返回数据即可,后续新人福利这一部分业务可以在主流程之外处理。我们如果将其剥离出来,接口主流程中只处理登陆逻辑,并通过MQ推送一条消息,通过异步方式处理后续的发放新人福利逻辑,这样即可保证注册接口50ms左右即能获取结果。

而发放新人福利的业务,则通过异步任务慢慢处理。通过拆分业务点,我们已经做到解耦,注册的附属业务中增加或减少功能点都不会影响主流程。另外如果一个业务主流程在某个点请求并发比较高,正好通过异步方式,可以将压力分散到更长的时间段中去,达到减轻固定时间段处理压力的目的,这就是流量削峰。

另外,单线程模型的语言,通常对消息中间件的需求更强烈。多线程模型的语言,或者协程型语言,虽然可以通过自身的多线程(或协程)机制,来实现业务内部的异步处理,但是考虑到持久化问题以及管理难度,还是成熟的中间件更适合用来做异步数据通信,中间件还能实现分布式系统之间的数据异步通信。

 

消息中间件的应用场景

消息中间件的应用场景主要有:

  • 异步通信:可以用于业务系统内部的异步通信,也可以用于分布式系统信息交互。
  • 系统解耦:将不同性质的业务进行隔离切分,提升性能,主附流程分层,按照重要性进行隔离,减少异常影响。
  • 流量削峰:间歇性突刺流量分散处理,减少系统压力,提升

你可能感兴趣的:(中间件,kafka,java,rabbitmq,性能优化)