河南艾特软件 网站建设,网站建设 企业网站 框架,南通网站建设祥云,wordpress创建标签页这是《百图解码支付系统设计与实现》专栏系列文章中的第#xff08;18#xff09;篇#xff0c;也是流量控制系列的第#xff08;4#xff09;篇。点击上方关注#xff0c;深入了解支付系统的方方面面。
本篇重点讲清楚分布式消息中间件的特点#xff0c;常见消息中间件…这是《百图解码支付系统设计与实现》专栏系列文章中的第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. 支付系统应用案例
消息中间件在支付系统中核心有几个核心应用场景
流量的削峰填谷。尤其是支付交易。系统应用间的解耦。比如支付成功后渠道网关发出支付成功消息由支付引擎和账务分别监听。事务消息。离线数据同步。有些公司使用离线库来做有些公司直接抛消息。比如实时库根据用户来分库分表离线库要根据商户来聚合等。 基本上消息中间件在支付系统中无所不在。 6. JAVA版的示例代码
先声明以下代码纯演示生产环境需要考虑更多因素。
比如支付场景下接收请求后先放到队列然后使用单独的消费线程去消费。以下是简单示例。 1. 添加依赖
首先你需要在项目的 pom.xml 文件中添加 RocketMQ 的依赖
dependenciesdependencygroupIdorg.apache.rocketmq/groupIdartifactIdrocketmq-client/artifactIdversion5.1.4/version/dependency
/dependencies
确保使用最新版本的依赖。 2. 创建生产者 (Producer)
创建一个生产者以发送消息到 RocketMQ 服务器
public class PayServiceImpl implements PayService {Autowiredprivate 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 发送的消息
public class PayConsumerServiceImpl implements PayConsumerService {Autowiredprivate MQConsumer mqConsumer;Autowiredprivate PayService payService;Postconstructpublic 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生成指南揭密支付安全为什么你的交易无法被篡改金融密语揭秘支付系统的加解密艺术支付系统日志设计完全指南构建高效监控和问题排查体系的关键基石避免重复扣款分布式支付系统的幂等性原理与实践支付系统的心脏简洁而精妙的状态机设计与核心代码实现精确掌控并发固定时间窗口算法在分布式环境下并发流量控制的设计与实现精确掌控并发滑动时间窗口算法在分布式环境下并发流量控制的设计与实现
