使用队列解耦的架构方案

Posted bossma

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了使用队列解耦的架构方案相关的知识,希望对你有一定的参考价值。

搞技术的对“高内聚,低耦合”这几个字应该很熟悉,这是程序设计的一个基本原则,无论对于分布式系统,有几个模块的单体程序,以及程序中具体的类、类中的方法,都可以拿来讲。这个原则本质上是“分治法”,将一个大问题分解为一个个的小问题,然后各个击破,整个问题就解决了。相信大家都很明白了,这里对这个原则就不过多解释了。

为什么要使用队列解耦?

让我们来看看不使用队列的情况下如何解耦的:

原始需求

假设有一个商城系统,业务上划分为用户、订单、财务、消息、仓储几个模块(模块的划分实际上也是解耦设计的重要部分,但非这篇文章的关注点),这几个模块是分布式部署的,用户在下单成功以后要做这么几件事:通知用户下单成功、通知仓库发货、给财务生成销售凭证,那么就要在下单成功的程序逻辑中去调用消息、仓储、财务模块的接口。

技术图片

对于一个不经常变动、吞吐量也不是很大的系统,做到这一步也就可以了。

新增需求

假设商城最近又上线了一个优惠券的功能,需要在下单成功后给用户发优惠券,这时候怎么去做呢?一个很直接的想法就是修改下单成功的程序逻辑,增加一个调用发优惠券接口的处理。

技术图片

也能解决问题,但是这时候就要考虑下了,以后还会不会有别的需求?比如下单成功后给用户增加积分,给推荐的用户做返利等等。每次都修改下单的程序逻辑其实还是有一定技术风险的,能不能以后不改下单的代码也能扩展呢?

更好的扩展性

聪明的你一定想到了办法,用配置。

技术图片

在订单模板中定义一个配置文件,所有需要下单成功后调用的接口地址都写到这里,下单的程序读取这个配置,一个个去调用。如果以后还有新增的下单后处理,在这里增加一行配置就行了,不用改下单的代码。

不过需要注意,每个接口接收的参数应该都是一样的,或者支持通过参数模板赋值(比如url:http://blog.bossma.cn/notice?orderId=OrderId&Status=Status,其中XXX的内容会被实际值替换,不同的业务可以定义不同的url参数),否则还是要改代码。

还有没有问题

有一天你可能发现下单成功后,也通知用户了, 也发货了,但是没有生成财务凭证,然后到服务器上翻日志发现下单处理超时了,调用生成凭证接口没有成功,至于原因可能是网络抖动了,也可能是开发人员在升级程序…你想到了分布式事务,不过这个似乎不太好搞。你可能觉得也就是偶尔出现一次,手工处理下就好了。

然后双十一到了,超过平常10倍的用户来下单,用户可能发现提交订单一直在等待,等待,等…。至于原因也许就是上次发现的超时问题更严重了,本来处理很快的接口调用突然都慢了下来。

这时候你可能需要一个队列了。

使用队列

先来看看使用队列后是什么样的?

技术图片

很明显只是在下单操作和下单后的操作中间增加了一个队列,下单成功后订单数据发送到队列,通知、发货、凭证等等操作从队列接收订单数据,然后按照自身的业务需求进行处理。

仔细想一下,其实是把上边提到的配置方式换成了队列方式,而且它们做的事以及做事方法本质是差不多的,接收数据,然后把数据分发给预先配置好的程序。形式上最大不同是队列从进程内独立了出来。

那么使用队列带来了什么好处呢?

1、更低的耦合,下单操作和后续的通知、发货、凭证操作完全分开了,下单完毕后发送订单数据到队列就像发送一个事件,需要的地方订阅这个事件就可以了。

2、更好的性能,没有使用队列时,下单操作要一次执行下单、通知、发货、凭证等多个处理,耗时较长;同时可能因为某个调用服务不稳定,导致整个下单操作不稳定,甚至完全不可用;要对下单操作进行性能优化时,需要考虑的方面过多,不容易达成。

3、容错,对于瞬时的异常,比如网络抖动、磁盘IO打满,导致后续操作无法执行时,队列可以缓存这部分数据,直到程序恢复处理能力后继续处理。没有使用队列的时候,只能记个日志,人工处理。

可能的坑

说几句废话,有些坑是使用队列新引入的,有些坑本来一直就存在,有的坑可以解决,有的坑只能把危害尽量降低。

最终一致性

如果没有使用队列,可以通过本地事务,甚至分布式事务来保证数据的严格一致性。

这不能算一个坑,但是需要理解使用了队列后就是选择了最终一致性,尽管有些队列支持RPC调用,但本质上仍是最终一致性。

通知可能延迟了2秒,发货可能推迟了1分钟,凭证可能晚生成了10秒,这些应该都是可以接受的,因为对于用户最重要的下单成功了,至于后边相对不那么紧急的事慢慢搞就好了,当然也不能慢的超出人的正常认知,响应速度取决于这些操作的处理能力。

消息仍可能会丢

为了防止数据在发送队列时丢失而生产者却不知情的情况,很多的队列都提供了发送确认,只有发送者收到了发送确认,消息才算投递成功。

但丢失消息的情况不止这一种,假设队列服务正常,在下单完成,发送订单数据到队列之前,服务器断电了,消息就永远不可能发到队列了。

技术图片

为了处理此类极端情况,可以采用的方案也有几个,比如:

  • 将消息和下单放到一个数据库事务中,即使当时没能发送到队列,也能在检查未发送消息的时候补上这一条。
  • 在所有事务执行前记录日志,在每个事务完成后记录日志,从故障恢复后检查未完成的事务,执行这些事务。

不过除非逼不得已,波斯码仍然不建议在系统开发之初就搞这个方案,复杂了。

重复消息

由于网络问题或者因程序内部异常中断,发送者不能确定消息是否发送成功时,可能就会再次发送。

如果业务严格限制数据只能处理一次,消费者应该有能力来处理这种重复,可能的解决方案:在数据表中增加一个已处理消息的标识,或者缓存最近处理过的消息进行判重。

不当消息

在不使用队列,多个操作在同一个进程内执行的情况下,不同的接口可能设计了不同的参数,程序编写者需要在调用接口时传递不同的数据,以满足接口的业务需求。这种惯性思维可能被带入使用队列的情况下,为不同的业务发送不同的数据到队列,消费者消费各自定制的数据。这种做法完全忽视了使用队列进行解耦的好处。

应该把发送到队列的数据看作一个消息、或者一个事件,而不是某个具体业务方需要的某几个数据,这个消息可能是和业务方需求的数据完全吻合,也可能少或者多,对于业务方需要的缺少的数据应该可以根据消息中某个标识去查询,这样才算比较合适的解耦。

比如例子中发送下单成功的通知,需要订单金额和用户手机号,从队列接收到的是订单数据,其中有订单金额,没有手机号,但是有用户Id,程序需要根据用户Id去查询用户的手机号。

不当分发

在这篇文章举的例子中可以使用广播或者主题的分发方式,一条消息分发到多个消费者队列,每个消费者消费的消息互相之间没有影响。

在使用队列时需要特别关注分发方式,避免消息发送到了不需要的消费者队列,导致消费者因无法处理而崩溃;或者不同的业务消费同一个消费者队列,导致消息丢失业务处理。

不当高可用

每种队列产品都提供了高可用的解决方案,我们一般都会在生产环境采用高可用部署。

在实施高可用方案时应该清醒的认识到,可用性越高,就要在性能或一致性上有些损失,需要按照业务需求平衡这些指标。

选择队列产品

市面上常见的队列也不少,RabbitMQ、RocketMQ、Kafka、ActiveMQ、MetaMQ,甚至Redis也可以干这件事。网上有大量的文章介绍他们的原理和使用,这里也不过多的进行说明了。

说一下波斯码认为的主要三个:RabittMQ、RocketMQ、Kafka。

RabittMQ 社区活跃、管理界面易用、各种开发语言支持的比较好,单机万级别并发,适合中小型公司。

Kafka 为处理日志而生,吞吐量单机十万级,社区也很活跃。

RocketMQ 基于Kafka衍生而来,既保持了原有的高并发支持,又在可靠性、稳定性上得到了加持。阿里开源,社区活跃度一般,适合大公司。

以上是关于使用队列解耦的架构方案的主要内容,如果未能解决你的问题,请参考以下文章

削峰填谷-系统解耦-日志架构-秒杀系统的实现方式(消息队列之 RabbitMQ)

如何解耦实时游戏架构

分布式消息队列应用场景之异步处理应用解耦流量削锋和消息通讯理解分析

在我的 C# 解决方案中,解耦架构中的接口存储在哪里?

使用队列解耦程序

消息队列的使用