共计 7208 个字符，预计需要花费 19 分钟才能阅读完成。
作者： 周新宇 & 陈涛 & 李凯
阿里云 RocketMQ 轻量版（MNS）音讯队列是一个轻量、牢靠、可扩大且齐全托管的分布式音讯队列服务。MNS 可能帮忙利用开发者在他们利用的分布式组件上更轻量的传递数据、告诉音讯，构建松耦合零碎。无需治理开销，而且模型简略，拆箱即用，主动横向扩容，无需治理分区等简单的逻辑运维，是一款 Serverless 音讯队列产品。
MNS 重点聚焦在基准音讯队列的外围能力建设，MNS 通过多年迭代与打磨，只管外部极为简单，但始终致力放弃其在客户端的简略易用，围绕轻量和集成两个命题，着力建设更易用的音讯队列产品。
外围劣势
MNS 围绕轻量音讯队列，提供一系列的轻量级能力。为企业和开发者升高音讯产品的复杂度，缩小运维开销，提供更易上手的音讯队列服务。
轻量模型
MNS 提供 1:1 和 1:N 两种轻量模型，可依据场景自行抉择须要的模型形式，学习成本低，上手快。无需了解简单的概念模型，无需刻意学习，几分钟即可疾速上手。
MNS 模型轻量次要体现在资源的操作方面，创立和删除等都配置有极简的 API，同时与数据链路的 API 属于同一个 SDK，不便用户像收发音讯那样进行资源的创立。相同，很多云产品资源的 API 都采纳了新的管控 SDK，应用门槛较高。
此外，MNS 的模型和资源是一一对应的，比方应用队列模型仅须要创立一个 Queue，十分易于上手和应用，而其余一些同类型产品，对于同一个模型会有实例、主题、队列、分区等多个资源。
轻量协定
采纳 HTTP RESTful 标准协议，接入不便，跨网络能力强，人造领有反对多语言拜访的能力。官网 SDK 笼罩各大支流语言，包含 C++，C#，.Net，Python，PHP 和 Java，社区奉献也有用 Go，Node 等。
同时拜访协定简略通用，即便不想依赖云产品提供 SDK，也能够很容易通过简略的编码来拜访 API，接入成本低，开发效率高。
轻量计费
MNS 是 Serverless 轻量计费，相较于依照实例付费，MNS 提供更加轻量的 Serverless 计费形式。依照申请量和资源占用状况付费，用多少付多少，无需为额定预留资源买单；同时提供每个月领有 2000 万次 API 收费调用额度。这种齐全后付费的定价形式能够为企业节约大量闲置资源。
轻量运维
MNS 能够依据利用状况进行弹性扩大，因而，无需放心容量布局和预配置。每个队列的音讯数量不限，而且规范队列能提供简直有限的吞吐量（QPS 范畴内）；提供 Serverless 化弹性服务，高效快捷，无需对资源做预留，随取随用，实时扩缩；更适宜产品集成与刹时队列场景。
同时 MNS 提供欠缺的音讯监控音讯告警等能力，反对高可靠性和高稳定性，打消治理和运维时的复杂性和研发开销。
根本模型
MNS 是一个交融了点对点（P2P）和公布订阅（Pub/Sub）两种生产模型的生产零碎，其中 MNS 的「队列」是 P2P 生产模型的实现，「主题」是 Pub/Sub 生产模型的实现。
MNS 也是业界鲜有的同时提供两种混合生产模型的云产品，用户能够通过「队列」或者「主题」来实现大部分对音讯零碎的需要。
队列（P2P 模型）
队列模型提供高牢靠、高并发的一对一生产模型，即队列中的每一条音讯都只可能被某一个消费者生产。队列就像一家旋转寿司店。寿司店中有多个寿司徒弟（生产者）在制作精美的寿司，每一份寿司都是独特的，顾客（消费者）能够从传送带上拿取中意的寿司进行食用（生产）。
队列是 MNS 的顶级资源，也是音讯的存储实体，有残缺的阿里云资源的生命周期，以及欠缺的权限管制机制。围绕队列有三个外围概念：
- 生产者（Producer）：生产者负责将音讯发送到指定的队列上，一个队列承受分布式的生产者并发投递音讯。
- 队列（Queue）：队列模型对应的物理资源，也是音讯的存储实体，MNS 通过一个分布式的存储集群来提供队列的分布式存储能力。
- 消费者（Consumer）：消费者负责从指定的队列通过轮询的机制获取音讯，一个队列承受分布式的消费者并发地生产音讯，同时保障同一条音讯在可见工夫内只会被一个消费者生产。
主题（Pub/Sub 模型）
主题模型提供一对多的公布订阅模型，反对音讯告诉。主题就像一份报纸，多个读者到邮局订阅了这份报纸。当报纸推出最新一期时，读者（包含邮局的合作伙伴）能够抉择以下形式来获取：
- 让邮局投递员将报纸都投递（推送）到家里（特定的地址）。
- 去就近的报刊亭（订阅点）自行获取报纸（报纸会先被邮局投递员集中送到各个报刊亭）。
主题是 MNS 的另一个顶级资源，其也具备音讯的存储能力，对应的 Topic 资源具备残缺的阿里云资源的生命周期，以及欠缺的权限管制机制。围绕主题也有三个外围概念：
- 生产者（Producer）：生产者除了能够把音讯发送至队列，也能够把音讯发送到主题上，主题也承受分布式的生产者并发投递音讯。
- 主题（Topic）：主题模型对应的物理资源同样具备音讯的存储能力。
- 订阅（Subscription）：能够为每个主题创立多个订阅，每个订阅将收到 Topic 上的残缺音讯，订阅的上游能够是多种类型的订阅者，用户往往通过订阅的能力将主题中的音讯扇出至多个队列。
性能个性
MNS 作为一款成熟的音讯产品，面向主题和队列提供了多种性能个性，可能深刻到利用的架构当中，帮忙用户升高业务流程开发的复杂度，让业务专一于业务逻辑的开发。比方多种音讯类型的反对，不便用户疾速实现定时、优先级相干的业务逻辑。
多种音讯类型的反对
MNS 队列反对一般音讯、提早音讯、优先音讯这 3 种音讯类型。
一般音讯是最根底的音讯类型，当一条一般音讯发送到了 MNS 之后，这一条音讯就会在队列中期待用户的拉取进行音讯的生产。
对于提早音讯，用户能够在发送的时候指定冀望这条音讯的延迟时间，当到了设定的延迟时间后，那么就能够生产到这条音讯。同时，在发送了提早音讯之后，除了能够获取到音讯的一些根本属性之外，还能够获取到一个音讯句柄，当冀望提前勾销掉这条提早音讯的时候，咱们能够应用这个音讯句柄进行 Delete。Delete 过后，这条音讯就不会再投递进去。通过提早音讯，用户能够轻松的实现一个分布式的提早调度零碎，在领有高精度提早的同时，实现超高的可扩展性和可用性。
对于优先音讯，咱们在发送音讯的时候能够指定音讯的优先级，优先级的取值范畴为 1 到 16。优先级的取值越小，那么这条音讯的优先级就越高。须要留神的是，优先音讯并不保障音讯的程序性，优先级越高的音讯领有更容易被生产的可能性，并不意味着优先级低的音讯肯定会在优先级高的音讯生产实现之后才可能被生产。
高效的长轮训机制
对于 音讯队列 MNS 来说，用户须要被动进行音讯的拉取，如果拉取的频率过低，那么就会导致音讯的提早；绝对应的，如果拉取的频率过高，那么又会带来过多有效的 API 调用。
为解决这个问题，MNS 队列提供了长轮训的机制，能够在肯定水平上缩小有效 API 的调用，同时保障音讯的及时性。当用户拉取音讯的时候，能够设置这次申请拉取音讯的 waitseconds，客户端则会以设置的工夫挂一个长轮训申请到服务端。如果在长轮训期间发现有音讯能够被生产，就会立刻返回；如果没有，就会最多期待长轮训工夫完结之后返回。但须要留神的是，尽管咱们能够应用长轮训来缩小有效的 API 调用，但整体上还是须要肯定的音讯拉取的并发度，以保障音讯的及时性。
灵便的音讯生命周期治理
对于队列中的一条音讯，其会具备可见、不可见、删除这 3 种状态。当音讯发送到队列中后，这条音讯就处于可见的状态，期待消费者来拉取。当音讯被消费者拉取出来之后，音讯会进入一段“不可见工夫”，在这段“不可见工夫”外面，这条音讯是不会被再次的拉取出来。但如果在“不可见工夫”外面这条音讯没有被删除，那么这一条音讯就会再次的可见，并能够被消费者再一次的从队列中拉取出来。
除此之外，当有消费者生产到音讯，在解决的过程中忽然呈现问题，例如宕机，那么这一条音讯则会在“不可见工夫”完结之后再一次的可见，能够被其余的消费者再次生产到。
这里可能就存在一个矛盾点，用户可能冀望有消费者宕机之后，没有被正确处理的音讯可能尽快的由其余消费者生产上来，但又因为自身的业务解决工夫可能有时候较长，可能会超过队列上所配置的默认的“不可见工夫”，导致音讯的反复生产。那么，为解决这种场景，MNS 也为用户提供了能够在音讯维度批改某一条音讯的“不可见工夫”性能。
当用户收到了一条音讯，发现这条音讯解决的工夫较长会超过队列所配置的“不可见工夫”的时候，用户能够通过音讯的句柄被动调用，批改这一条音讯的不可见工夫。例如上图，将这一条音讯的不可见工夫进行了缩短，留给了业务更多的解决工夫。当然，同之前的音讯生产一样，当这条音讯解决实现之后，也须要调用删除音讯的接口，进行音讯生产胜利的确认。
音讯多订阅推送
MNS 主题提供了一对多播送音讯的能力，咱们能够为一个主题创立多个订阅，路由到不同的 Endpoint。用户只须要将音讯发送到主题，就能够将这个一条音讯推送到多个订阅中去。
其次，在一对多播送音讯的能力的根底上，在订阅中，MNS 还反对订阅带有特定标签的音讯。咱们在创立订阅的时候能够指定这个订阅所关怀的音讯的 Tag，这样当 MNS 进行音讯推送的时候，就会主动进行音讯的过滤，仅将这个订阅所关怀的 Tag 推送进来。
为了保障音讯投递的可靠性，用户能够对每个订阅配置推送策略，能够指定应用退却重试策略或者指数衰减重试的策略。
对于退却重试策略，当音讯推送失败的时候，会重试 3 次，每一次的重试间隔时间为 10 到 20 秒的随机值。对于指数衰减重试，整体的重试工夫为 1 天，每次的重试工夫距离是指数递增的（1 秒，2 秒，4 秒，8 秒，…）。
最初，咱们还能够配置推送的音讯的格局，咱们能够在创立订阅的时候，指定推送格局为 XML、JSON 或者 SIMPLIFIED。对于 XML 和 JSON，推送给订阅的音讯内容，除了会蕴含发送到主题的音讯之外，还会增加例如 MessageID、TopicName、SubscriptionName 等属性。而对于 SIMPLIFIED，则是间接将发送到主题的音讯进行转发，不会增加额定的属性。
接入协定
MNS 以 HTTP 协定对外提供服务，蕴含近 30 个 RESTful 的 API，但外围业务场景往往应用 3 个左右的 API 就能够实现研发，十分易于上手。
另外，用户既能够间接依据 API 进行自行的封装，也能够间接应用官网所提供的的 SDK 进行集成。用户仅只须要依赖一个 SDK 就能够实现从服务的开明、资源的创立、再到音讯的收发。
在多语言 SDK 方面，MNS 提供了 8 种支流语言的 SDK，包含 Java、Python、C#、Node、PHP、C++、Go 等，同时也反对采纳 Java 畛域规范的 JMS SDK 接入 MNS。
实用场景解析
相较于 RabbitMQ，ActiveMQ，Kafka 等开源音讯队列，RocketMQ 轻量版 MNS 摒弃了非常复杂的概念模型及臃肿繁多的协定，通过简略模型，通用的 HTTP RESTful 标准协议即可高效实现音讯畛域的典型场景。提供齐全免运维的音讯集成计划，显著升高开发和保护老本，晋升新业务开发效率。
音讯播送（Fanout）场景解析
- 背景信息
轻量音讯队列 MNS 提供队列（Queue）和主题（Topic）两种模型，根本能满足大多数利用场景。队列提供的是一对一的共享音讯生产模型，采纳客户端被动拉取（Pull）模式。
主题模型提供一对多的播送音讯生产模型，采纳服务端被动推送（Push）模式。
推送模式的益处是即时性能较好，但需裸露客户端地址来接管服务端的音讯推送。有些状况下有的信息，例如企业内网，无奈裸露推送地址，心愿改用拉取（Pull）的形式。尽管音讯服务 MNS 不间接提供这种生产模型，但能够联合主题和队列来实现一对多的拉取音讯生产模型。
- 解决方案
通过创立订阅，让主题将音讯先推送到队列，而后由消费者从队列拉取音讯。这样既能够做到一对多的播送音讯，又可防止裸露消费者的地址。
超大音讯传输（Claim Check）场景解析
- 背景信息
音讯服务 MNS 的队列的音讯大小最大限度是 64 KB，这个限度根本可能满足在失常状况下音讯作为控制流信息替换通道的需要。然而，在某些非凡场景下，音讯数据比拟大时，就只能采纳音讯切片的形式。
上面是不做音讯切片，通过 OSS 来实现传递大于 64 KB 的音讯的解决方案。
- 解决方案
生产者在向音讯服务 MNS 发送音讯前，如果发现音讯体大于 64 KB，则先将音讯体数据上传到 OSS。
生产者把数据对应的 Object 信息发送到音讯服务 MNS。
消费者从音讯服务 MNS 队列里读取音讯，判断音讯内容是否为 OSS 的 Object 信息。
判断音讯内容是 OSS 的 Object 信息，则从 OSS 下载对应的 Object 内容，并作为音讯体返回给下层程序。
简略事务音讯场景解析
背景信息：一些业务场景须要保障本地操作和音讯发送的事务一致性，即音讯发送胜利，本地操作胜利。如果音讯发送胜利，本地操作失败，那么发送胜利的音讯须要回滚。操作流程如图所示：
- 解决方案
音讯发送胜利，事务操作胜利时操作步骤如下所示：
- 生产者发送一条事务筹备音讯到事务音讯队列；
- 生产者发送操作日志音讯到操作日志队列，日志中蕴含步骤 1 音讯的音讯句柄；
- 生产者执行本地事务操作胜利；
- 生产者申请批改音讯延迟时间，使音讯对消费者可见；
- 生产者向操作日志队列确认操作日志，删除日志音讯；
- 消费者从事务音讯队列中接管事务音讯；
- 消费者处理事务音讯；
- 消费者申请删除事务音讯。
音讯过滤（Message Filter）场景解析
- 背景信息
一些场景中须要依据音讯内容把音讯推送到不同的推送指标，为了达到这一性能，您能够创立多个主题，并为每个主题设置相应的推送指标，然而这样会减少额定的老本，并且减少了运维的复杂度。为了防止这种状况，音讯队列 MNS 提供了音讯过滤标签性能。您能够只创立一个主题，并在创立订阅时设置不同的音讯过滤标签，联合音讯的音讯过滤标签，MNS 就能够把音讯推送到不同的推送指标中。
- 解决方案
图示例场景中，在主题 Topic 1 创立 3 个音讯过滤标签不同的订阅，Subscription 1、Subscription 2 和 Subscription 3。这 3 个订阅的推送指标别离是 Queue 1、Queue 2 和 Queue 3。
- 音讯的音讯过滤标签和订阅的音讯过滤标签统一。音讯过滤过程如下：
音讯服务 MNS 将 Message 1 推送到队列 Queue 1；
音讯服务 MNS 将 Message 2 推送到队列 Queue 2。
- 订阅没有音讯过滤标签。音讯过滤过程如下：
音讯服务 MNS 将 Message 1 推送到队列 Queue 3；
音讯服务 MNS 将 Message 2 推送到队列 Queue 3；
音讯服务 MNS 将 Message 3 推送到队列 Queue 3。
客户案例及最佳实际
在线交易 – 利用解耦 – 削峰填谷（典型场景）
- 场景形容
淘宝 / 天猫主站最为外围的零碎是交易系统，每一笔交易订单数据都会有几百个上游业务零碎的关联，包含物流、购物车、积分、直充、阿里妈妈、流计算剖析等，整个零碎宏大而且简单，架构设计稍有不合理，将间接影响主站业务的连续性。
- 异步解耦
如此简单且宏大的零碎，若上、上游业务零碎紧耦合，那么任意一个子系统不可用都将间接导致外围交易系统不可用；
通过音讯队列实现上、上游业务零碎松耦合，那么，即使上游子系统（如物流零碎）呈现不可用，也不会影响到外围交易系统的失常运行；
- 削峰填谷
通过音讯队列不仅能够起到零碎间解耦的作用，更能在大促、秒杀等大型流动中起到削峰填谷的作用。
每年天猫双 11 凌晨，保障外围交易系统的业务解决能力始终为重中之重，每秒数十万笔的交易订单解决能力，且逐年线性增长；然而绝对的，各大物流零碎、银行的领取零碎的业务解决能力却无限，若不能进行流量缓冲将间接引发这些零碎的解体。因而，利用音讯队列弱小的音讯沉积能力则能够很好的起到削峰填谷的作用，将零碎压力全副转移到音讯队列，从而开释物流、领取等零碎的压力，保障业务的失常运行。
直播录制 – 合流 – 转码（Serverless 场景）
场景形容：视频的直播录制，合流，转码是在线教育和在线直播畛域的刚需场景，通过 MNS 能够对 FC Serverless 资源进行在线调度，帮忙客户实现异步直播流录制，合流转码等简单场景。
在线游戏场景
- 场景形容
游戏场景存在大量强交互场景的数据流转，对消息中间件的稳定性和端到端提早要求极高，自建消息中间件压力大、不稳固。游戏场景存在大量的指令传输以及定时工作，自建逻辑无奈解决热点问题。
通过 MNS 能够实现从游戏网关指令到后盾音讯协定的转换，同时 MNS 也反对后盾逻辑服、工会、战斗服之间的异步解耦拆分。
总结
MNS 围绕轻量音讯队列，提供一系列的轻量级能力。为企业和开发者升高音讯产品的复杂度，缩小运维开销，提供更易上手的音讯队列服务。
作为阿里云 RocketMQ 的轻量版，填补了 RocketMQ 在轻量化和易用性的有余。只管 MNS 版本随同 RocketMQ 通过多年迭代与打磨，外部极为简单，但始终致力放弃其在客户端的简略易用。为企业和开发者升高音讯产品的复杂度，缩小运维开销提供更易上手的音讯队列服务，是 MNS 的产品使命和愿景。
MNS 产品训练营流动炽热报名中
为了帮忙大家由浅入深的对阿里云音讯队列 MNS 有更加全面的理解，同时冀望音讯队列 MNS 可能帮忙大家解决日常工作和生产的问题，特推出音讯队列 MNS 产品训练营课程，课程中不仅有对产品简略形象的介绍，还有“首秀”的入手实际学习课程。
参加本次音讯队列 MNS 训练营，您能够学习并播种到：
- 音讯队列 MNS 的根底概念及个性
- 音讯队列 MNS 的最佳实际及案例
- 基于 MNS，0 根底轻松构建 Web Client
除了学习层面的播种，流动期间，实现所有参营工作且考试通过的前 20 名同学可取得（若问题雷同按考试工夫程序排名），即可收费取得小米充电宝。流动工夫：8 月 10 日 – 8 月 31 日（工作日期间）。
点击此处，立刻报名吧～