网络文学网站开发,黄埔区建设局网站,视频网站开发公司,毕业设计做 做交易网站在笔者心中#xff0c;消息队列#xff0c;缓存#xff0c;分库分表是高并发解决方案三剑客。
在职业生涯中#xff0c;笔者曾经使用过 ActiveMQ 、RabbitMQ 、Kafka 、RocketMQ 这些知名的消息队列 。
这篇文章#xff0c;笔者结合自己的真实经历#xff0c;和大家分享…在笔者心中消息队列缓存分库分表是高并发解决方案三剑客。
在职业生涯中笔者曾经使用过 ActiveMQ 、RabbitMQ 、Kafka 、RocketMQ 这些知名的消息队列 。
这篇文章笔者结合自己的真实经历和大家分享消息队列的七种经典应用场景。 1 异步解耦 笔者曾经负责某电商公司的用户服务该服务提供用户注册查询修改等基础功能。用户注册成功之后需要给用户发送短信。 图中新增用户和发送短信都揉在用户中心服务里这种方式缺点非常明显 短信渠道不够稳定发送短信会达到 5 秒左右这样用户注册接口耗时很大影响前端用户体验; 短信渠道接口发生变化用户中心代码就必须修改了。但用户中心是核心系统。每次上线都必要谨小慎微。这种感觉很别扭非核心功能影响到核心系统了。 为了解决这个问题笔者采用了消息队列进行了重构。 异步 用户中心服务保存用户信息成功后发送一条消息到消息队列 ,立即将结果返回给前端这样能避免总耗时比较长从而影响用户的体验的问题。 解耦 任务服务收到消息调用短信服务发送短信将核心服务与非核心功能剥离显著的降低了系统间的耦合度。 2 消峰 高并发场景下面对突然出现的请求峰值非常容易导致系统变得不稳定比如大量请求访问数据库会对数据库造成极大的压力或者系统的资源 CPU 、IO 出现瓶颈。
笔者曾服务于神州专车订单团队在订单的载客生命周期里订单的修改操作先修改订单缓存然后发送消息到 MetaQ 订单落盘服务消费消息并判断订单信息是否正常比如有无乱序)若订单数据无误则存储到数据库中。 当面对请求峰值时由于消费者的并发度在一个阈值范围内同时消费速度相对均匀因此不会对数据库造成太大的影响同时真正面对前端的订单系统生产者也会变得更稳定。 3 消息总线 所谓总线就是像主板里的数据总线一样 具有数据的传递和交互能力各方不直接通信使用总线作为标准通信接口。
笔者曾经服务于某彩票公司订单团队在彩票订单的生命周期里经过创建拆分子订单出票算奖等诸多环节。每一个环节都需要不同的服务处理每个系统都有自己独立的表业务功能也相对独立。假如每个应用都去修改订单主表的信息那就会相当混乱了。
因此公司的架构师设计了调度中心的服务调度中心维护订单的信息但它不与子服务通讯而是通过消息队列和出票网关算奖服务等系统传递和交换信息。 消息总线这种架构设计可以让系统更加解耦同时也可以让每个系统各司其职。 4 延时任务 用户在美团 APP 下单假如没有立即支付进入订单详情会显示倒计时如果超过支付时间订单就会被自动取消。
非常优雅的方式是使用消息队列的延时消息。
订单服务生成订单后发送一条延时消息到消息队列。消息队列在消息到达支付过期时间时将消息投递给消费者消费者收到消息之后判断订单状态是否为已支付假如未支付则执行取消订单的逻辑。 RocketMQ 4.X 生产者发送延迟消息代码如下
Message msg new Message();
msg.setTopic(TopicA);
msg.setTags(Tag);
msg.setBody(this is a delay message.getBytes());
//设置延迟level为5对应延迟1分钟
msg.setDelayTimeLevel(5);
producer.send(msg); RocketMQ 4.X 版本默认支持 18 个 level 的延迟消息 通过 broker 端的 messageDelayLevel 配置项确定的。 RocketMQ 5.X 版本支持任意时刻延迟消息客户端在构造消息时提供了 3 个 API 来指定延迟时间或定时时间。 5 广播消费 广播消费当使用广播消费模式时每条消息推送给集群内所有的消费者保证消息至少被每个消费者消费一次。 广播消费主要用于两种场景消息推送和缓存同步。 01 消息推送 下图是专车的司机端推送机制用户下单之后订单系统生成专车订单派单系统会根据相关算法将订单派给某司机司机端就会收到派单推送消息。 推送服务是一个 TCP 服务自定义协议同时也是一个消费者服务消息模式是广播消费。
司机打开司机端 APP 后APP 会通过负载均衡和推送服务创建长连接推送服务会保存 TCP 连接引用 比如司机编号和 TCP channel 的引用。
派单服务是生产者将派单数据发送到 MetaQ , 每个推送服务都会消费到该消息推送服务判断本地内存中是否存在该司机的 TCP channel 若存在则通过 TCP 连接将数据推送给司机端。 02 缓存同步 高并发场景下很多应用使用本地缓存提升系统性能 。
本地缓存可以是 HashMap 、ConcurrentHashMap 也可以是缓存框架 Guava Cache 或者 Caffeine cache 。 如上图应用A启动后作为一个 RocketMQ 消费者消息模式设置为广播消费。为了提升接口性能每个应用节点都会将字典表加载到本地缓存里。
当字典表数据变更时可以通过业务系统发送一条消息到 RocketMQ 每个应用节点都会消费消息刷新本地缓存。 6 分布式事务 以电商交易场景为例用户支付订单这一核心操作的同时会涉及到下游物流发货、积分变更、购物车状态清空等多个子系统的变更。 1、传统XA事务方案性能不足
为了保证上述四个分支的执行结果一致性典型方案是基于 XA 协议的分布式事务系统来实现。将四个调用分支封装成包含四个独立事务分支的大事务。基于 XA 分布式事务的方案可以满足业务处理结果的正确性但最大的缺点是多分支环境下资源锁定范围大并发度低随着下游分支的增加系统性能会越来越差。 2、基于普通消息方案一致性保障困难 该方案中消息下游分支和订单系统变更的主分支很容易出现不一致的现象例如 消息发送成功订单没有执行成功需要回滚整个事务。 订单执行成功消息没有发送成功需要额外补偿才能发现不一致。 消息发送超时未知此时无法判断需要回滚订单还是提交订单变更。 3、基于 RocketMQ 分布式事务消息支持最终一致性
上述普通消息方案中普通消息和订单事务无法保证一致的原因本质上是由于普通消息无法像单机数据库事务一样具备提交、回滚和统一协调的能力。
而基于 RocketMQ 实现的分布式事务消息功能在普通消息基础上支持二阶段的提交能力。将二阶段提交和本地事务绑定实现全局提交结果的一致性。
RocketMQ 事务消息是支持在分布式场景下保障消息生产和本地事务的最终一致性。交互流程如下图所示 1、生产者将消息发送至 Broker 。 2、Broker 将消息持久化成功之后向生产者返回 Ack 确认消息已经发送成功此时消息被标记为暂不能投递这种状态下的消息即为半事务消息。 3、生产者开始执行本地事务逻辑。 4、生产者根据本地事务执行结果向服务端提交二次确认结果 Commit 或是 Rollback Broker 收到确认结果后处理逻辑如下 二次确认结果为 Commit Broker 将半事务消息标记为可投递并投递给消费者。 二次确认结果为 Rollback Broker 将回滚事务不会将半事务消息投递给消费者。 5、在断网或者是生产者应用重启的特殊情况下若 Broker 未收到发送者提交的二次确认结果或 Broker 收到的二次确认结果为 Unknown 未知状态经过固定时间后服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。 生产者收到消息回查后需要检查对应消息的本地事务执行的最终结果。 生产者根据检查到的本地事务的最终状态再次提交二次确认服务端仍按照步骤4对半事务消息进行处理。 7 数据中转枢纽 近10多年来诸如 KV 存储HBase、搜索ElasticSearch、流式处理Storm、Spark、Samza、时序数据库OpenTSDB等专用系统应运而生。这些系统是为单一的目标而产生的因其简单性使得在商业硬件上构建分布式系统变得更加容易且性价比更高。
通常同一份数据集需要被注入到多个专用系统内。
例如当应用日志用于离线日志分析时搜索单个日志记录同样不可或缺而构建各自独立的工作流来采集每种类型的数据再导入到各自的专用系统显然不切实际利用消息队列 Kafka 作为数据中转枢纽同份数据可以被导入到不同专用系统中。
日志同步主要有三个关键部分日志采集客户端Kafka 消息队列以及后端的日志处理应用。 日志采集客户端负责用户各类应用服务的日志数据采集以消息方式将日志“批量”“异步”发送Kafka客户端。 Kafka客户端批量提交和压缩消息对应用服务的性能影响非常小。 Kafka 将日志存储在消息文件中提供持久化。 日志处理应用如 Logstash订阅并消费Kafka中的日志消息最终供文件搜索服务检索日志或者由 Kafka 将消息传递给 Hadoop 等其他大数据应用系统化存储与分析。 文章转载自勇哥编程游记 原文链接https://www.cnblogs.com/makemylife/p/18101509 体验地址引迈 - JNPF快速开发平台_低代码开发平台_零代码开发平台_流程设计器_表单引擎_工作流引擎_软件架构
