阿里云消息队列RocketMQ版_云原声分布式消息中间件_分布式消息统一处理平台-云巴巴 -云巴巴

阿里云消息队列RocketMQ版

RocketMQ诞生于阿里内部核心电商系统，主要为业务系统提供异步化、低延迟、业务解耦、削峰填谷、异构数据复制的能力。功能多样，高性能，高可靠容灾，可观测运维，帮助业务系统完成高价值数据传输和驱动。解决CDC增量同步、顺序交易撮合难题，解决分布式定时调度难题。

立即咨询

首页

数字化产品

容器与中间件

阿里云消息产品全景

产品架构

RocketMQ 诞生于阿里内部核心电商系统，主要为业务系统提供异步化、低延迟、业务解耦、削峰填谷、异构数据复制的能力。核心价值主打：功能多样，高性能，高可靠容灾，可观测运维，帮助业务系统完成高价值数据传输和驱动。

功能丰富、开箱即用

多类型消息：顺序、定时、事务等多类型消息

多消费模式：集群、广播多消费模式、SQL/TAG多类型过滤

高性能、低延迟首选

高性能：横向可扩展，高并发海量存储支持

低延迟：存储毛刺优化，高峰期顺滑写入

可观测、易运维

可观测：轨迹追踪、告警大盘，可查可监控

易运维：消息路由、消息重置，消息可运维管理

容灾多活、业内领先SLA

多副本秒级RTO：可用性 99.95%，可靠性 10个9

多活容灾：业内领先异地多活等容灾能力

多功能消息类型：顺序消息——解决CDC增量同步、顺序交易撮合难题 icon

特性介绍：通过分区顺序传输能力支持传统严格顺序CDC数据同步以及交易撮合等场景

应用场景

在线教育信令场景：教育直播等场景需要保证交互信令顺序到达。证券交易场景：金融证券交易的场景需要对所有指令顺序投递。

用户痛点

性能热点、无法扩展：常规基于物理分区的顺序消息实现都会因为单分区物理节点的性能瓶颈而受阻，随着业务增长必须要做二次拆分。故障恢复慢：常规顺序消息的实现，单个顺序分区出现故障时该分区的消息读写都受影响，恢复时间长，业务体验查。

技术竞争力&价值

高并发无限扩展：在保持有序的前提下，可以通过水平扩容无限扩展每个逻辑分区的能力，用户无需特殊处理。秒级故障恢复能力：在单个物理节点故障时具备秒级自动切换能力，用户基本无感知。

多功能消息类型：精准定时消息——解决分布式定时调度难题 icon

特性介绍：无需借助外部依赖即可实现分布式秒级精度定时消息通知，解决传统数据库扫表定时等方案的低效不可扩展问题。

应用场景

交易订单超时场景：交易下单后如果未及时支付，被动触发订单超时的检查任务，指定时间后关闭订单。战斗组团超时场景：战斗组团场景、超时后被动触发下游处理。其他后台定时任务场景：服务后台的定时任务跨节点调度。

传统方案痛点

分布式场景调度困难：常规分布式场景下，涉及多个服务节点，扫描等机制需要做任务去重和分片，逻辑复杂，扩展性有待提高。定时精度不够：常规定时任务基于数据库扫表等方式只能基于固定间隔扫描，间隔太小性能消耗扛不住，间隔太大精度不够。

多功能消息类型：精准定时消息——解决分布式定时调度难题 icon

特性介绍：无需借助外部依赖即可实现分布式秒级精度定时消息通知，解决传统数据库扫表定时等方案的低效不可扩展问题。

RocketMQ定时消息三大优势

• 开发门槛低、上手容易：区别传统扫表定时的实现，业务无需再实现复杂的扫描和去重逻辑，只需触发消息，等待监听即可。开发门槛低更容易。

• 高性能、可扩展：RocketMQ 定时消息性能可以完全水平扩展，百万TPS调度无压力。

• 定时精度高：RocketMQ 定时消息支持最高秒级精度，支持长时间范围定时，业务适用范围更广，开发更简单。

多功能消息类型：事务消息——解决分布式事务一致性难题 icon

特性介绍：提供高吞吐、可扩展性能的分布式事务协调保障，解决传统XA事务无法突破的高性能问题。问题描述：如何保证核心业务（订单支付）和多个下游业务的执行结果完全一致，同时成功或者同时失败。特征拆解：问题有一个主分支，同时有若干个下游场景需要与之一致；该事务的处理耦合业务逻辑（数据库等操作）

多功能消息类型：事务消息——解决分布式事务一致性难题 icon

特性介绍：提供高吞吐、可扩展性能的分布式事务协调保障，解决传统XA事务无法突破的高性能问题。

RocketMQ事务消息优势

• 业务耦合性低：

区别传统本地事务消息表方案，RocketMQ 事务消息和业务系统解耦合，业务方无需存储中间事务状态和扫描重试。

• 高性能、可扩展：

RocketMQ 事务消息性能可以完全水平扩展，百万TPS调度无压力，支撑历年双十一流量。

多功能消息过滤：TAG/SQL过滤——高效率解决消费过滤问题 icon

特性介绍：提供TAG和SQL92两种过滤能力，支持服务端高效过滤自定义消息子集，避免流量传输浪费和客户端压力。

RocketMQ消息过滤优势

• 精细化业务分类：区别其他消息队列，RocketMQ支持按照Tag标签以及自定义属性做轻量级分类过滤，可以避免Topic、分区的重量级消耗。

• 强大、灵活的过滤规则：RocketMQ 支持SQL92语法过滤，主流的查询条件都支持计算，非常灵活。

• 高效率过滤传输：RocketMQ 消息过滤是服务端过滤，客户端完全无压力，无需浪费传输带宽和资源。

应用场景

• 订单交易等场景分类：交易等场景经常需要增加子订单分类，动态分类如果直接用不同Topic区分，流程太重，不利于业务扩展。

• 消息过滤诉求：不同业务下游，只需要处理少量消息子集，如果没有过滤能力，则需要大量的资源拉取全量消息再丢弃，浪费且不稳定。

稳定性：消息队列全生命周期稳定性建设 icon

系统性稳定性建设必须从架构设计研发开始，贯穿整个服务周期，仅依靠运维告警并不能完全兜底。

• 架构设计：弹性架构、水平扩展、无单点、高可用、隔离、限流

• 编码实现：防御编程、RPC 超时、上下游异常处理、checksum、资源有界定义

• 测试发布：单元测试、集成测试、性能测试、灰度发布、一键回滚

• 上线运行：容量评估、系统监控、应用监控、业务端到端巡检、故障演练

• 故障应急：紧急降级、快速止血、故障根因排查、后续 Action 跟进

稳定性：架构设计——高并发写毛刺优化 icon

核心交易链路等场景对消息发送耗时非常敏感，写入毛刺可能会引发系统雪崩，顺滑的写入体验至关重要。

• 系统参数调优：操作系统内存回收&脏页内存等参数调整

• 内存预分配：内置匿名内存分配池算法，避免内存分配延迟抖动。

• 二次异步缓冲：异步场景下消息存储经过匿名内存缓冲后刷入PageCache，避免 PageCache 抖动。

• 读写分离减少竞争：消息读取和消息写入分离在不同的内存区域，消除锁竞争压力

应用价值：大促场景下消息写入毫秒响应

• 客户痛点：大促场景下业务流量水位高，偶尔的发送 RT 抖动会带来业务线程池阻塞，进而引起失败和雪崩。

• 核心价值：通过存储毛刺优化处理实现写消息平滑，规避风险

应用场景：消息堆积冷读场景下不影响写入

• 客户痛点：在消息大量堆积的场景下，消费方消费冷数据导致PageCache 交换，影响热数据的写入稳定性。

• 核心价值：分离读写请求访问的内存区域，实现冷读场景下更稳定的写入体验。

稳定性：架构设计——存储碎片整理，优化堆积冷读性能 icon

消息读取场景堆积不可避免，大量堆积冷读情况下的性能会影响热消息写入，需要做好隔离和优化。热数据预计算索引：消息写入时预计算本分区的偏移量，不影响实时消息写入。异步归并索引计算：异步启动归并索引计算流程，以最小代价完成索引更新，不影响实时消息读取。消息存储碎片规整和替换：消息原始碎片化数据合并，顺序写入磁盘，最小限度影响 IO 性能。

应用场景：实时计算场景大规模Scan、堆积消费场景性能优化客户痛点：在大规模消息堆积或者实时计算场景下存储碎片化会导致冷读性能差、延迟高。核心价值：通过碎片规整充分利用操作系统预读提高性能和体验。

稳定性：架构设计——局部节点故障隔离 icon

生产环境局部节点宕机故障不可避免，系统架构在设计上能够及时隔离故障节点，降低局部异常的影响对业务非常重要

• 服务端响应时间探测：基于RPC 协议获取发消息请求耗时统计

• 健康度动态评估：SDK内置健康度评估算法，动态计算各个服务端节点的优先级，选择最优的服务端节点写消息。

• 自动隔离异常节点：服务端部分节点宕机、FGC 等场景下，客户端自动隔离该节点。应用场景：部分节点宕机或者慢响应时，客户端快速收敛，降低影响范围

• 客户痛点：服务端部分节点出现异常或者响应慢时，客户端的发送请求无法绕过，导致部分请求超时，影响上层业务。

• 核心价值：通过动态探测算法可以保证在部分服务端节点异常时客户端能够自动探测剔除，降低影响范围。

稳定性：系统可观测——360自动化巡检 icon

生产环境所有实例均部署有自动化巡检，以用户视角模拟消息收发和API调用，实时预警，先于用户发现问题

• 检测真实度高：基于原生 SDK接口实现黑盒探测逻辑，最大程度模拟用户行为。

• 覆盖范围广：巡检组件实现核心收发功能全覆盖，管控类功能基本覆盖。

• 探测实时性高：全天 24 小时运行覆盖，异常状态 1 分钟探测，实时告警到钉钉、邮箱和电话渠道。

稳定性：专家系统——快速定位问题利器 icon

MQ耦合业务逻辑，生产环境故障问题需要收集大量信息才能做判断，专家经验至关重要，以产品化能力沉淀专家系统，支持快速定位问题

场景痛点

消息收发疑难杂症难排查：RocketMQ消息收发，特别是消费，耦合业务逻辑，出问题很大概率是业务逻辑问题，但缺少信息证明和排查。线上信息零散，无法统一收集：线上系统排查问题需要收集大量日志、指标和运行配置状态，人工脚本执行效率低、耗时长，故障应急压力大。

专家系统价值

内置统一数据收集：阿里云RocketMQ 内置专家系统，统一收集信息，排查问题无需人工收集信息。内置疑难问题模板：小白也可快速基于模板定位线上问题，排查问题门槛大幅降低。

稳定性：专家系统操作演示视频 icon

容灾体系：消息队列容灾体系分级 icon

更易用：实时扩缩容——解决自建消息扩容慢、缩容困难痛点 icon

消息系统容量保障是核心链路生命线，容量过剩是浪费，容量不足系统挂掉，扩缩容效率和稳定性至关重要

自建消息扩缩容痛点

痛点一：扩容效率低，无法应对突发流量和故障应急

• 缺少弹性资源池，物理资源生产慢，故障应急恢复慢

• 部署自动化、标准化扩缩容系统欠缺，手工脚本易错高风险

痛点二：缩容需要缩队列，平滑下线难，容易造成故障

• 缩容需要对队列做长时间禁写等待消息消费完，否则丢消息

• 队列禁写缩容期间容易造成消费空转和不均衡

痛点三：扩缩容受本地磁盘挂载架构约束，利用率低

• 挂载本地磁盘的架构，流量不足或者磁盘不足时只能一起扩容，存在浪费。

• 挂载本地磁盘，无法缩容，磁盘太小消息保存不够，容量太大后期磁盘无法缩。

阿里云云消息扩缩容能力

能力一：全系列实例随时升降配，最快秒级生效

• 云产品拥有大量弹性资源池，热备资源实时扩容

• 全自动运维系统，扩缩容过程无需人工介入，不易出错

能力二：扩缩容业务无感，无需业务配合

• 云上存算分离架构，队列变化客户端侧无感知，无均衡性和丢消息问题

能力三：存算分离+分级存储能力，计算和存储按需扩缩

• 云上消息收发按需扩容即可，和存储解耦。

• 分级存储能力，支持存储低成本按量使用，不再有任何浪费，费用降低67%。

更易用：多接入点——解决线下IDC访问、混合组网问题 icon

一个实例（集群）同时支持VPC内网、公网、线下IDC、多VPC访问，兼顾安全和成本

痛点：自建公网访问成本高、不安全；4.x版本是软负载源端IP暴露服务，不适合直接暴露公网。公网传输，需要传输可信加密，保障数据安全。解法：单实例支持按需开启公网传输；基于存算分离Proxy代理可以低成本暴露公网接入点。默认支持TLS加密传输以及ACL身份校验，更安全。

痛点：早期版本实例不支持多地域访问；4.x版本是单地域接入点，不支持多地域vpc共同访问。解法：单实例支持多地域VPC访问；5.x版本默认提供VPC私网地址，支持CEN组网后跨地域、多VPC访问。

痛点：线下IDC异构云访问冲突；4.x版本IDC和异构云访问需要添加大段边界路由。IDC容易和云IP造成网段和路由冲突。解法：新版本无需额外配置即可互通；5.x版本默认提供VPC私网地址，无需添加边界。路由即可实现互联互通，且不会冲突。

更易用：收发流量隔离约束——读写分离控制提高集群稳定性 icon

读写TPS自定义比例量化隔离约束，以明确SLA确保收发相互不影响，提高集群稳定性

场景痛点

消息收发缺少量化SLA：自建集群以机器规格评估水位，对收发消息TPS缺少量化SLA保障，特殊场景下容易造成短板和风险。读写压力不隔离存在风险：消息场景存在堆积和冷读，一对一和一堆多广播；大量广播和冷读场景容易影响热消息写入，造成故障。需要对读写进行隔离和限制。

产品能力价值

消息收发量化SLA保障：阿里云消息实例全部提供TPS量化SLA保障，涵盖各种极端场景，业务评估更容易。读写自定义比例隔离和约束：消息收发全部独立限流，可以保证大量冷读和广播场景被限制，避免影响热消息写入。

更易用：客户端动态配置管理——故障降级止血利器 icon

通过客户端配置动态下发更新机制，实现消费顺序性、重试策略等重要参数的动态更新，在故障降级和止血场景速度更快、不易出错

场景痛点

缺少元数据管理，配置容易不一致：自建集群缺少元数据中心，客户端配置和服务端配置零散多处，容易出现行为不一致。故障应急需要依次重启应用，恢复慢、风险高：在典型的消息消费堆积、卡顿等场景需要紧急降级顺序约束或者重试次数，重启客户端应用慢，且容易造成Rebalance、流量抖动风险。

产品能力价值

统一内置元数据中心保障一致性：阿里云RocketMQ 内置支持统一元数据中心，保证服务端、客户端的重要配置持久化和一致性。动态配置，实时生效：在典型的消息消费堆积、卡顿等场景需要紧急降级顺序约束或者重试次数，只需白屏化操作，最快秒级即可快速恢复

更易用：轻量客户端——彻底解决消费不均衡堆积痛点 icon

RocketMQ 5.0客户端轻量化设计，负载均衡收敛到服务端，支持消息粒度负载均衡，队列数量和客户端不再有绑定和关联。

历史痛点

消费不均衡：V4版本按照队列绑定的方式负载均衡，如果部分队列堆积，其他客户端无法分摊压力。消费者数量和队列绑定：V4版本绑定队列的方式，一个队列只能被一个消费者处理，不利于运维管理。节点上下线空转易故障：V4版本在部分队列下线时，禁写容易造成客户端空转。

价值体现

消费更均衡：V5版本基于Proxy计算层，普通消息可以实现消息粒度负载均衡，客户端之间相互分摊压力。消费者数量和队列解耦：V5版本无需绑定队列，一个队列可以被多个消费者处理，应用扩缩容更灵活。节点上下线无感：V5版本在部分队列下线时，禁写不再会造成客户端空转。

更易用：多语言客户端——解决多语言能力不对齐历史问题 icon

RocketMQ 5.0基于gRPC协议以及轻量化设计，可以快速补齐java/C++/.NET/Go等主流SDK能力，提供稳定可靠的版本。

早期版本多语言问题

痛点一：历史版本C++/.NET客户端存在稳定性问题

• 历史版本C++ SDK连接管理稳定性欠缺，业务异常容易导致core dump

• 历史版本.NET SDK存在句柄泄露风险，需要定期重启清理

• 历史版本Go SDK 存在跨平台适配兼容性问题

痛点二：历史版本多语言SDK功能行为和Java未对齐

• 缩容需要对队列做长时间禁写等待消息消费完，否则丢消息

5.0版本新多语言SDK

能力一：稳定可靠的多语言实现

• 5.0版本基于gRPC协议，复杂通信层native实现更稳定，上层配合存算分离架构，复杂逻辑上移，客户端更简单稳定

• 5.0版本所有SDK都是native实现，平台兼容性更好

能力二：客户端行为统一定义对齐

• 5.0多语言客户端严格遵循proto协议定义，行为一致，除部分语言不支持异步多线程外，基本无差异。

更易用：便捷消息查询——快速排查消息收发问题 icon

RocketMQ 支持一键消息查询，透出消息关键元信息以及消息内容等，并支持消息下载和消费验证。

产品能力价值

• 支持多样查询：阿里云RocketMQ 提供开箱即用消息查询，支持MessageID、MessageKey 查询。

• 消息内容搜索展示：支持系统属性、自定义属性展示和搜索，支持消息内容关键字搜索。

• 消息内容下载：支持消息内容下载保存。

• 消费验证：支持对单条消息进行消费验证，模拟触发业务调用。

大规模弹性：突发流量自适应弹性——兜底业务不确定性风险 icon

业务消息往往存在预期之外的突发业务热点和毛刺流量，常规扩缩容无法及时应对，服务存在不确定性风险。突发流量弹性机制

• 预留规格部分流量：建议按照常规水位和基线购买预留规格，分布在该区间的流量无额外计费，基础预留规格单价更便宜。

• 突发弹性部分流量：对于超过预留规格的流量，可以按需开启突发弹性能力，分布在该区间的流量按小时周期峰值按量计费。

• 完全超限部分流量：对于超过弹性上限的流量，服务端为保证系统稳定性，会进行限流，拒绝超限的流量。

场景痛点

• 突发流量毛刺影响稳定性：自建集群应对不确定的突发流量，常规扩容需要分钟级，业务受损，平时预留大量buffer不划算。

• 少量时间段的高峰，需要按最大规格预留资源：云产品售卖时，如果业务存在少量时间段的高峰，按最大规格预留资源不划算。

产品能力价值

• 秒级自适应弹性，兜底突发流量毛刺：阿里云RocketMQ支持突发流量弹性，秒级即可恢复应对突发毛刺。

• 间歇高峰型流量，成本更优：突发流量弹性部分按量付费，业务无需为全部时间段的峰值规格买单，更实惠。

大规模弹性：存储Serverless——解决大容量低成本按需存储 icon

提供按需使用、按量付费、高可靠三副本的低成本长期存储，解决存储弹性伸缩和成本难题。

应用场景：消息存储按需使用、按量付费

• 痛点问题：开源服务端挂载本地盘架构，单盘无法缩容，存在浪费；单盘原地扩容需要重启，时间周期长，业务有感；业务侧多副本机制，需要N份复制流量压力，宕机或更换机器存在大量数据复制补齐压力。

• 核心价值：分级存储架构，存储按需使用、按量付费，无需管理扩缩容问题，宕机后也无需业务复制流量，业务无感。

应用场景：自定义存储时长，实现历史数据长期存储

• 痛点问题：如果需要长期保存消息需要自己将数据转存到其他存储，需要时再次从外部存储中取出，开发成本高。

• 核心价值：以自建三分之一的成本享受长时间存储消息的服务，无需自己做二次开发。

应用场景：消息堆积场景，冷热数据分离处理

• 客户痛点：在用消息大量堆积的场景下，消费方消费冷数据，会影响热数据的写入稳定性。

• 核心价值：冷热数据分离存储，昂贵的高级存储自动用来处理用户热数据，冷数据存储到低成本存储，保障服务稳定性。

消息可观测：点、线、面解决线上收发问题排查痛点 icon

消息链路耦合业务系统，复杂带状态，问题排查需要强大的可观测系统和经验做支撑才能提高运维效率。生产者、消费者多对多：业务调用链路网状结构，上下游梳理困难。上下游解耦、异步链路：异步化调用，信息收集不完整。消息是状态数据：未消费成功、定时中等状态增加排查的复杂度。消费链路耦合复杂的业务处理逻辑：无法快速定位问题边界。

消息可观测：仪表盘功能 icon

开箱即用的仪表盘，快速巡检查看线上问题和风险

实例 Top10 问题资源：一眼可见

✓ 按失败率倒序排序：着重加强了复杂的消费链路的指标和监控。

✓ 按堆积严重程度排序：

✓ 按消息量倒序排序：为用户提供最佳模板，并持续迭代更新

生产消费指标详情：定位问题边界和原因

✓ 消息量指标：着重加强了复杂的消费链路的指标和监控。

✓ 堆积量指标：消息量和延时时间，准确反映消费及时性

✓ 错误率指标：反映生产和消费的健康度

✓ 耗时指标：为用户提供最佳模板，并持续迭代更新

实例使用量指标：容量成本规划

✓ 流量峰值：评估容量规格，及时扩缩容

✓ 限流次数：评估容量规格，及时扩缩容

✓ 存储、带宽使用量：评估使用量

消息可观测：消息轨迹功能 icon

产品集成组合

RocketMQ5.0提供主流云产品集成，开箱即用，免开发。统一基于阿里云事件中心，提供高可用和Serverless弹性能力，免运维。

竞争分析：对比开源自建优势 icon

钉钉——定时消息实现已读用户功能 icon

钉钉(Ding Talk)是阿里巴巴集团打造的企业级智能移动办公平台,引领未来新一代工作方式,将陪伴每一个企业成长,是数字经济时代的企业组织协同办公和应用开发平台,是新生产力工具。

典型场景：在线交易 - 应用解耦 + 削峰填谷 icon

场景描述：作为淘宝/天猫主站最为核心的系统的交易系统，整个系统庞大而且复杂，架构设计稍有不合理，将直接影响主站业务的连续性。异步解耦：如此复杂且庞大的系统，若上、下游业务系统紧耦合，那么任意一个子系统不可用都将直接导致核心交易系统不可用；通过消息队列实现上、下游业务系统松耦合，那么，即便下游子系统（如物流系统）出现不可用，也不会影响到核心交易系统的正常运转；削峰填谷 :通过消息队列不仅可以起到系统间解耦的作用，更能在大促、秒杀等大型活动中起到削峰填谷的作用。因此，利用消息队列强大的消息堆积能力则可以很好的起到削峰填谷的作用，将系统压力全部转移到消息队列，从而释放物流、支付等系统的压力，保证业务的正常运转。

客户案例：银行交易系统 icon

客户介绍：中国XX银行是中国一家全国性商业银行。 XX银行的核心交易系统组件繁多，交易相关的变更需要实时通知到诸多外围系统。随着业务规模增长，系统稳定性压力越来越大。客户痛点：银行消息系统采用 ActiveMQ，在性能、可用性和数据可靠性方面瓶颈明显，影响业务。用户账号动态变更的实时通知对接的各种外围系统不稳定，影响核心业务的稳定性。解决方案：使用 RocketMQ 完成核心交易系统和外围系统的解耦合拆分。使用 RocketMQ 的事务消息简化分布式事务的处理逻辑。使用 RocketMQ 实现民生银行新系统（DCBC）、老系统（ BPP ）之间客户号变更信息同步。使用 RocketMQ 构建异地双活业务系统。客户价值：RocketMQ 的异步解耦能力以及双活架构的落地提高了核心系统的稳定性。RocketMQ 事务消息的高级特性降低用户的业务开发成本。

客户案例：XX游戏

XX网络是一家的国内著名的互动娱乐游戏供应商，专注于全球化游戏研发与发行、大数据应用、IP管理工程、泛娱乐产业投资等业务板块。客户痛点：存在大量强交互场景的数据流转，对消息中间件的稳定性和端到端延迟要求极高，自建消息中间件压力大、不稳定。游戏场景存在大量的顺序指令传输以及定时任务，自建逻辑无法解决热点问题。解决方案：使用 RocketMQ 实现从游戏网关指令到后台消息协议的转换。使用 RocketMQ 实现后台逻辑服、工会、战斗服之间的异步解耦拆分。使用 RocketMQ 高可用顺序消息和秒级定时消息解决定时和顺序数据传输需求。客户价值：通过 RocketMQ 的引入，彻底解耦合网关服务和后台游戏逻辑服务，系统稳定性提升。使用 RocketMQ 提供的顺序消息和定时消息高级功能，轻松构建业务逻辑，缩短游戏开发周期。