波斯马BOSSMA Information Technology

使用队列解耦的架构方案

发布时间:2019年8月19日 / 分类:Architecture / 4,046 次浏览 / 评论

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

为什么要使用队列解耦?

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

原始需求

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

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

新增需求

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

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

更好的扩展性

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

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

不过需要注意,每个接口接收的参数应该都是一样的,或者支持通过参数模板赋值(比如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衍生而来,既保持了原有的高并发支持,又在可靠性、稳定性上得到了加持。阿里开源,社区活跃度一般,适合大公司。

本博客所有文章如无特别注明均为原创。
复制或转载请以超链接形式注明转自波斯马,原文地址《使用队列解耦的架构方案

关键字:

建议订阅本站,及时阅读最新文章!
【上一篇】 【下一篇】

发表评论