开发者学堂课程【消息队列 MNS （RocketMQ 轻量版）入门课程：消息队列 MNS 简史】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1237/detail/18413
消息队列 MNS 简史
本次课程主要分为五个部分，包括消息队列mns的简介，优势特点，最佳实践案例以及mns快速入门，还有动手实践，期望通过本期课程的介绍，能够带领大家由浅入深的对阿里云交易队列有更加全面的了解，也期望学习能够帮助大家解决日常工作和生产的问题，那今天来开始第一课，先带大家简要的对mns消息队列有基础的认识跟了解，在整体介绍mns之前，一起对消息队列的整体概念行一个回顾和温习，用更加形象的方式和大家一起来看一看为什么要使用消息队列以及消息队列有哪些基础的模型？
当你的业务或系统需要异步解耦和削峰填谷的时候，自然而然会想到使用消息队列，那什么是消息队列呢？让我们先忘掉眼前的电脑跟代码一起回到童年，趴在电视前看电视剧的那个年代。
早上五更十分，早朝开始，每个大臣都向皇帝进行汇报，这种情况大臣向皇帝的汇报就是一个一对一输出的过程，时间短还好，时间一长，皇帝受不了，排队的大臣也会有点儿崩溃那类业务系统来说，这种官员道皇帝传递信息的模式就像同步处理系统简单还好，一旦系统复杂起来，比如说有了微服务等应用，这种同步可能就比较容易崩溃，那怎么办呢？皇帝便走进他的内阁和六部来请减负，由六部大臣和内阁以及各地的大臣经联动来帮助皇帝处理动者，各地的大臣送来的斗折先交，由内阁暂存，然后再交，用六步来处理，这样一来，不必每时每刻仅一对一的汇报，这就是异步结尾，同时即使遇到了洪灾，旱灾，这种各地救灾奏折暴增传来的这种情况，也能有序的由内阁向六部经三发，不至于让整个朝廷崩溃，这个就叫削峰填谷。
对比于业务系统来说，由各地官员到内阁再到六部处理的这个流程，就像我们常见的消息队列的模式，可以有效的解决系统和业务之间义务结构以及削峰填谷。
在了解完什么是消息队列，来看一下消息队列主要的两种模型，还是刚才的故事，有大臣不断的向那个去发送奏折，这个时候可以也看成一个传送带来进行传送组织，每个六个大臣只能在座位上拿上一个对应的奏折，这就类比于我们的这种队列的模型，它实现的是什么呢？它实现的就是一对一的消费模式及队列中的每一个消息都只能够被某一个消费者来消费，如果要将一条消息发送给多个消费者，比如一个地方同一份同单的走着，既要发给兵部来派兵救灾，同时又需要发给户部来申请相应的救灾款，还需要发给公布来申请筑坝的工人，这个时候那个就充当了类似于有几个角色，将同一分斗既可以投递给不同的部门，同时也可以放到不同的衙门，有各自的官员来自行自行来取，这种就是一对多的消费模型，也就是订阅发布模型，在订阅发布模型中消息的发送方式，发布者消息的接收方为订阅者服务端存放消息的容器就叫做主题，这个月在接受消息的时候应该先订阅主题，第一个在这里它既是一个动作，同时也可以认为是主题在消费时的一个逻辑副本，每一份的订阅中，订阅者都可以教授到主题的所有的消息.
在介绍完消息队列的基础概念之后，就比较好理解了，来看一下消息队长的整体定义。
定位是提供的是进量的模型，进量的HTTP协议运维比较奇妙，同时计费也比较轻妙，具备一级成等特点，这里进量的HTTP协议比较好理解，可以轻松的实现系统的对接，进量模型纸以队列模型为核心，可以实现队列的弹性扩容，相对来说也比较的灵活我PPT中所示，然后mns有需进行资源的规划，同时还支持弹性的按量计费的，计费方面也比较轻量，我们近期也推出了相关的资源包，在购买的方式上也会更加的便捷使用消息队列。最重要的尤其是云产品，可能最重要的考虑的是它的可靠性，我们从校一队列跟自建队列的可靠性的对比上，来对mns进行一个简单的小结，
创建队列，在稳定性和性能方面非常的依赖内存，一不小心内存用完了，这个服务可能就挂掉了，mns是标准的云消息队列产品开箱即用，除了在应用层具备刚才所说的几个方面的基础特性之外呢，在运煤层面也具备副本能在多租户隔离，高可用的特性，简单来说具有的特点是1+2+3+n，外加一些高级功能。
下一课对于mns的特点进行详细的介绍，最后，再加一个餐，刚才介绍到mns是以队列模型为核心，但消息队列的mns它同样支持定位发布模型的最佳实践，具体方式如图所示，
它就是通过创建订阅，让主题将消息先推送到各个队里边儿去，然后消费者再从对月里去拉取消息，这样既可以得到一对多的广播，又可以避免掉暴露消费者的地址。
