削峰填谷与应用间解耦:分布式消息中间件在分布式环境下并发流量控制的应用

这是《百图解码支付系统设计与实现》专栏系列文章中的第(18)篇,也是流量控制系列的第(4)篇。点击上方关注,深入了解支付系统的方方面面。

本篇重点讲清楚分布式消息中间件的特点,常见消息中间件的简单对比,在支付系统的应用场景,比如削峰填谷,系统应用间的解耦,事务消息等。

内容偏入门介绍,已经使用过消息中间件的同学可以不用往下看了。

1. 前言

在流量控制系列文章中的前四篇,分别介绍了固定时间窗口算法、滑动时间窗口算法、漏桶原理、令牌桶原理,应用场景和java版本的核心代码。

我们做个简单回顾:

**固定窗口:**算法简单,对突然流量响应不够灵活。超过流量的会直接拒绝,通常用于限流。

滑动窗口: 算法简单,对突然流量响应比固定窗口灵活。超过流量的会直接拒绝,通常用于限流。

**漏桶算法:**在固定窗口的基础之上,使用队列缓冲流量。提供了稳定的流量输出,适用于对流量平滑性有严格要求的场景。

**令牌桶算法:**在滑动窗口的基础之上,使用队列缓冲流量。提供了稳定的流量输出,且能应对突发流量。

今天讲的分布式消息中间件在支付场景的削峰填谷用得比较多,且对精度没有那么苛刻的场景,比如集群低到1TPS,就无法做到。

2. 削峰填谷原理

**削峰:**在流量高峰期,通过消息中间件暂存大量的请求,减少对后端系统的直接压力。

**填谷:**在低峰期,逐渐处理这些积累的请求。

这种方法能有效平衡系统负载,防止在高峰时段系统崩溃。

我们一般使用消息中间件实现削峰填谷。下面是一个支付引擎自产生消的示例图。收到支付请求后,先扔到消息中间件,然后启用新的监听线程去消费。通过控制消费线程数来控制流量。

比如一下来了1000个请求,一共10台机器,每台机器消费线程只开5个,每个请求处理500ms,那么每秒就处理100个请求,共耗时10秒处理完。

消息中间件还有一个作用,就是应用间的解耦。比如支付成功后,渠道网关通过消息中间件返回给支付引擎。

3. 常见的分布式消息中间件介绍

消息中间件有很多,这里简单对比 RocketMQ、RabbitMQ 和 Kafka在性能、可靠性、易用性、功能特性、适用场景等方面的不同。如下:

性能

  • RocketMQ: 提供非常高的性能和吞吐量,特别适合大规模的消息传输和处理场景。
  • RabbitMQ: 性能优秀,尤其在小型消息的传递上非常高效。但在处理非常大量的消息时,性能可能不如 Kafka 和 RocketMQ。
  • Kafka: 专为高吞吐量设计,特别适合需要处理大数据流的场景。它在持久化和分布式处理方面的性能表现尤其出色。

可靠性

  • RocketMQ: 提供高可靠性保证,支持分布式事务。
  • RabbitMQ: 通过消息持久化、交付确认等机制提供可靠的消息服务。
  • Kafka: 数据持久化和高容错能力,确保了高可靠性。

易用性和管理

  • RocketMQ: 相对复杂,需要一定的学习曲线,但提供丰富的特性和灵活性。
  • RabbitMQ: 用户友好,易于安装和配置,拥有直观的管理界面。
  • Kafka: 配置和管理相对复杂,但社区支持强大,提供了丰富的文档资源。

功能特性

  • RocketMQ: 支持广泛的消息模式,包括顺序消息、定时/延时消息和事务消息。
  • RabbitMQ: 提供多种消息路由模式,支持灵活的消息模型和多种协议。
  • Kafka: 专注于高吞吐量的消息队列和流处理,支持实时数据处理。

适用场景

  • RocketMQ: 适用于大规模分布式系统中的消息处理,如电商平台和金融系统。
  • RabbitMQ: 适合需要复杂路由、多种消息协议和高效小消息处理的场景,如企业应用集成。
  • Kafka: 非常适合于需要高吞吐量、大数据处理和实时流处理的应用,如日志聚合和实时监控系统。

结论

  • 在支付系统,我个人更推荐RocketMQ,原因有两个:第一,经过阿里电商+支付各种非常高并发的大促洗礼,RocketMQ 在大型分布式系统中表现出色。第二,支持事务消息,这个在支付领域还是很有用的。

另外,我也只是简单介绍,大家实际应用的时候,根据实际情况去选型,建议是做多方了解后,部署验证后才规模使用。不过话说回来,这几款分布式消息中间件的技术非常成熟了,除了几个顶流的互联网公司外,基本可以随便用,哪个手熟就使用哪个。

4. 使用注意事项

脑裂问题

曾经在生产环境碰到过RabbitMQ脑裂问题,交易全部中断。在分布式环境中完全避免也不现实,建议加强监控。

消费线程数问题

消费线程要合理设置,太多,可能达不到削峰填谷的效果,太少,消息有可能会积累,影响处理时效。

比如支付是有时效,积压太久就会导致用户放弃支付。

消息积压应对

提前做好预估,以及监控。一旦把中间件压爆,可能整个交易系统。

持久化与恢复

防止系统崩溃导致的数据丢失。

事务消息

在需要保证数据一致性的场景中,合理使用事务消息。

消息确认与重试

合理设置消息确认机制和重试策略。如果本次无法处理,一定再抛回去。建议不要先确认再处理,万一确认后,本机又无法处理,消息就丢失了。

5. 支付系统应用案例

消息中间件在支付系统中核心有几个核心应用场景:

  1. 流量的削峰填谷。尤其是支付交易。
  2. 系统应用间的解耦。比如支付成功后,渠道网关发出支付成功消息,由支付引擎和账务分别监听。
  3. 事务消息。
  4. 离线数据同步。有些公司使用离线库来做,有些公司直接抛消息。比如实时库根据用户来分库分表,离线库要根据商户来聚合等。

基本上,消息中间件在支付系统中无所不在。

6. JAVA版的示例代码

先声明,以下代码纯演示,生产环境需要考虑更多因素。

比如支付场景下,接收请求后,先放到队列,然后使用单独的消费线程去消费。以下是简单示例。

1. 添加依赖

首先,你需要在项目的 pom.xml 文件中添加 RocketMQ 的依赖:

XML 复制代码
<dependencies>
  <dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>5.1.4</version>
  </dependency>
</dependencies>

确保使用最新版本的依赖。

2. 创建生产者 (Producer)

创建一个生产者以发送消息到 RocketMQ 服务器:

java 复制代码
public class PayServiceImpl implements PayService {
	@Autowired
    private MQProducer mqProducer;
    
    public PayOrder pay(PayRequest request) {
        PayOrder payOrder = buildPayOrder(request);
        // 前置处理,比如校验、保存DB等
        ... ...

        // 发送到队列
        Message msg = buildMessage(payOrder);
        mqProducer.send(msg);

        // 前置处理
    	... ...

        return payOrder;
    }

    public boolean processPay(PayOrder payOrder) {
    	// 外发处理
        ... ...
    }
}

3. 创建消费者 (Consumer)

创建一个消费者来接收从 RocketMQ 发送的消息:

java 复制代码
public class PayConsumerServiceImpl implements PayConsumerService {
	@Autowired
    private MQConsumer mqConsumer;
    @Autowired
    private PayService payService;

    @Postconstruct
    public void init() {
		mqConsumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) -> {
            payService.processPay(buildPayOrder(msg);
            return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
        });
    }
}

再次声明,上述代码纯演示,在生产环境中,需要考虑更复杂的场景和错误处理机制。

7. 结束语

通过使用分布式消息中间件进行并发流量控制,支付系统可以更有效地应对高并发场景。能很好地提高系统整体的稳定性和可靠性,毕竟瞬间的大流量被缓冲到了消息中间件里。

但有些场景无法使用消息中间件,比如要求整个集群低到1TPS,又或者对接了外部上百个渠道,每个渠道要求不一样,有些要求最高20TPS,有些最高100TPS,使用消息中间件不好实现,就需要前面文章介绍的手撸一个漏桶或令牌桶。

下一篇聊聊阿里开源的流量控制与熔断利器:Sentinel。

8.精选

专栏地址 百图解码支付系统设计与实现
《百图解码支付系统设计与实现》专栏介绍
《百图解码支付系统设计与实现》专栏大纲及文章链接汇总(进度更新于2023.1.15)
领域相关(部分)
支付行业黑话:支付系统必知术语一网打尽
跟着图走,学支付:在线支付系统设计的图解教程
图解收单平台:打造商户收款的高效之道
图解结算平台:准确高效给商户结款
图解收银台:支付系统承上启下的关键应用
图解支付引擎:资产流动的枢纽
图解渠道网关:不只是对接渠道的接口(一)

技术专题(部分)
交易流水号的艺术:掌握支付系统的业务ID生成指南
揭密支付安全:为什么你的交易无法被篡改
金融密语:揭秘支付系统的加解密艺术
支付系统日志设计完全指南:构建高效监控和问题排查体系的关键基石
避免重复扣款:分布式支付系统的幂等性原理与实践
支付系统的心脏:简洁而精妙的状态机设计与核心代码实现
精确掌控并发:固定时间窗口算法在分布式环境下并发流量控制的设计与实现
精确掌控并发:滑动时间窗口算法在分布式环境下并发流量控制的设计与实现

相关推荐
NiNg_1_23416 分钟前
基于Hadoop的数据清洗
大数据·hadoop·分布式
隔着天花板看星星2 小时前
Spark-Streaming集成Kafka
大数据·分布式·中间件·spark·kafka
技术路上的苦行僧6 小时前
分布式专题(8)之MongoDB存储原理&多文档事务详解
数据库·分布式·mongodb
龙哥·三年风水6 小时前
workman服务端开发模式-应用开发-后端api推送修改二
分布式·gateway·php
小小工匠7 小时前
分布式协同 - 分布式事务_2PC & 3PC解决方案
分布式·分布式事务·2pc·3pc
闯闯的日常分享9 小时前
分布式锁的原理分析
分布式
太阳伞下的阿呆10 小时前
kafka常用命令(持续更新)
分布式·kafka
Java程序之猿10 小时前
微服务分布式(二、注册中心Consul)
分布式·微服务·consul
龙哥·三年风水10 小时前
workman服务端开发模式-应用开发-后端api推送修改一
分布式·gateway·php
power-辰南12 小时前
Zookeeper 底层原理解析
分布式·zookeeper·云原生