阿里云消息队列（阿里云消息队列消费者接受慢）

本文目录一览：

• 1、阿里云的主要功能是什么？
• 2、阿里云微消息队列（MQTT）的基本使用
• 3、阿里云消息中间件（MQ）探秘
• 4、阿里云mqtt收费标准
• 5、简谈阿里云MQ消息队列云服务的计费模式
• 6、ons 阿里云 rocketMQ

阿里云的主要功能是什么？

阿里云致力于以在线公共服务的方式，提供安全、可靠的计算和数据处理能力，让计算和人工智能成为普惠科技。

阿里云服务着制造、金融、政务、交通、医疗、电信、能源等众多领域的领军企业，包括中国联通、12306、中石化、中石油、飞利浦、华大基因等大型企业客户，以及微博、知乎、锤子科技等明星互联网公司。在天猫双11全球狂欢节、12306春运购票等极富挑战的应用场景中，阿里云保持着良好的运行纪录。

阿里云在全球各地部署高效节能的绿色数据中心，利用清洁计算为万物互联的新世界提供源源不断的能源动力，目前开服的区域包括中国（华北、华东、华南、香港）、新加坡、美国（美东、美西）、欧洲、中东、澳大利亚、日本。

扩展资料：

阿里云主要产品：

1、弹性计算：

云服务器ECS：可弹性扩展、安全、稳定、易用的计算服务

块存储：可弹性扩展、高性能、高可靠的块级随机存储

专有网络VPC：帮您轻松构建逻辑隔离的专有网络

负载均衡：对多台云服务器进行流量分发的负载均衡服务

弹性伸缩：自动调整弹性计算资源的管理服务

资源编排：批量创建、管理、配置云计算资源

容器服务：应用全生命周期管理的Docker服务

高性能计算HPC：加速深度学习、渲染和科学计算的GPU物理机

批量计算：简单易用的大规模并行批处理计算服务

E-MapReduce：基于Hadoop/Spark的大数据处理分析服务

2、数据库：

云数据库RDS：完全兼容MySQL，SQLServer，PostgreSQL

云数据库MongoDB版：三节点副本集保证高可用

云数据库Redis版：兼容开源Redis协议的Key-Value类型

云数据库Memcache版：在线缓存服务，为热点数据的访问提供高速响应

PB级云数据库PetaData：支持PB级海量数据存储的分布式关系型数据库

云数据库HybridDB：基于GreenplumDatabase的MPP数据仓库

云数据库OceanBase：金融级高可靠、高性能、分布式自研数据库

数据传输：比GoldenGate更易用，阿里异地多活基础架构

数据管理：比phpMyadmin更强大，比Navicat更易用

3、存储：

对象存储OSS：海量、安全和高可靠的云存储服务

文件存储：无限扩展、多共享、标准文件协议的文件存储服务

归档存储：海量数据的长期归档、备份服务

块存储：可弹性扩展、高性能、高可靠的块级随机存储

表格存储：高并发、低延时、无限容量的Nosql数据存储服务

4、网络：

CDN：跨运营商、跨地域全网覆盖的网络加速服务

专有网络VPC：帮您轻松构建逻辑隔离的专有网络

高速通道：高速稳定的VPC互联和专线接入服务

NAT网关：支持NAT转发、共享带宽的VPC网关

2018年6月20日，阿里云宣布联合三大运营商全面对外提供IPv6服务。

5、大数据：

MaxCompute：原名ODPS，是一种快速、完全托管的TB/PB级数据仓库解决方案。

QuickBI：高效数据分析与展现平台，通过对数据源的连接，和数据集的创建，对数据进行即席的分析与查询。并通过电子表格或仪表板功能，以拖拽的方式进行数据的可视化呈现。

大数据开发套件：提供可视化开发界面、离线任务调度运维、快速数据集成、多人协同工作等功能，拥有强大的OpenAPI为数据应用开发者提供良好的再创作生态

DataV数据可视化：专精于业务数据与地理信息融合的大数据可视化，通过图形界面轻松搭建专业的可视化应用，满足您日常业务监控、调度、会展演示等多场景使用需求

关系网络分析：基于关系网络的大数据可视化分析平台，针对数据情报侦察场景赋能，如打击虚假交易，审理保险骗赔，案件还原研判等

推荐引擎：推荐服务框架，用于实时预测用户对物品偏好，支持A/BTest效果对比

公众趋势分析：利用语义分析、情感算法和机器学习，分析公众对品牌形象、热点事件和公共政策的认知趋势

企业图谱：提供企业多维度信息查询，方便企业构建基于企业画像及企业关系网络的风险控制、市场监测等企业级服务

数据集成：稳定高效、弹性伸缩的数据同步平台，为阿里云各个云产品提供离线(批量)数据进出通道

分析型数据库：在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索

流计算：流式大数据分析平台，提供给用户在云上进行流式数据实时化分析工具

6、人工智能：

机器学习：基于阿里云分布式计算引擎的一款机器学习算法平台，用户通过拖拉拽的方式可视化的操作组件来进行试验，平台提供了丰富的组件，包括数据预处理、特征工程、算法组件、预测与评估

语音识别与合成：基于语音识别、语音合成、自然语言理解等技术，为企业在多种实际应用场景下，赋予产品“能听、会说、懂你”式的智能人机交互体验

人脸识别：提供图像和视频帧中人脸分析的在线服务，包括人脸检测、人脸特征提取、人脸年龄估计和性别识别、人脸关键点定位等独立服务模块

印刷文字识别：将图片中的文字识别出来，包括身份证文字识别、门店招牌识别、行驶证识别、驾驶证识别、名片识别等证件类文字识别场景

7、云安全：

服务器安全（安骑士）：由轻量级Agent和云端组成，集检测、修复、防御为一体，提供网站后门查杀、通用Web软件0day漏洞修复、安全基线巡检、主机访问控制等功能，保障服务器安全

DDoS高防IP：云盾DDoS高防IP是针对互联网服务器（包括非阿里云主机）在遭受大流量的DDoS攻击后导致服务不可用的情况下，推出的付费增值服务，用户可以通过配置高防IP，将攻击流量引流到高防IP，确保源站的稳定可靠

Web应用防火墙：网站必备的一款安全防护产品。通过分析网站的访问请求、过滤异常攻击，保护网站业务可用及资产数据安全

加密服务：满足云上数据加密，密钥管理、加解密运算需求的数据安全解决方案

CA证书服务：云上签发Symantec、CFCA、GeoTrustSSL数字证书，部署简单，轻松实现全站HTTPS化，防监听、防劫持，呈现给用户可信的网站访问

数据风控：凝聚阿里多年业务风控经验，专业、实时对抗垃圾注册、刷库撞库、活动作弊、论坛灌水等严重威胁互联网业务安全的风险

绿网：智能识别文本、图片、视频等多媒体的内容违规风险，如涉黄，暴恐，涉政等，省去90%人力成本

安全管家：基于阿里云多年安全实践经验为云上用户提供的全方位安全技术和咨询服务，为云上用户建立和持续优化云安全防御体系，保障用户业务安全

云盾混合云：在用户自有IDC、专有云、公共云、混合云等多种业务环境为用户建设涵盖网络安全、应用安全、主机安全、安全态势感知的全方位互联网安全攻防体系

态势感知：安全大数据分析平台，通过机器学习和结合全网威胁情报，发现传统防御软件无法覆盖的网络威胁，溯源攻击手段、并且提供可行动的解决方案

先知：全球顶尖白帽子和安全公司帮你找漏洞，最私密的安全众测平台。全面体检，提早发现业务漏洞及风险，按效果付费

移动安全：为移动APP提供安全漏洞、恶意代码、仿冒应用等检测服务，并可对应用进行安全增强，提高反破解和反逆向能力。

8、互联网中间件：

企业级分布式应用服务EDAS：以应用为中心的中间件PaaS平台、

消息队列MQ：ApacheRocketMQ商业版企业级异步通信中间件

分布式关系型数据库服务DRDS：水平拆分/读写分离的在线分布式数据库服务

云服务总线CSB：企业级互联网能力开放平台

业务实施监控服务ARMS：端到端一体化实时监控解决方案产品

9、分析：

E-MapReduce：基于Hadoop/Spark的大数据处理分析服务

云数据库HybirdDB：基于GreenplumDatabase的MPP数据仓库

高性能计算HPC：加速深度学习、渲染和科学计算的GPU物理机

大数据计算服务MaxCompute：TB/PB级数据仓库解决方案

分析型数据库：海量数据实时高并发在线分析

开放搜索：结构化数据搜索托管服务

QuickBI：通过对数据源的连接，对数据进行即席分析和可视化呈现。

参考资料：

百度百科-阿里云

阿里云微消息队列（MQTT）的基本使用

最近应系统功能需求，采购了一款云喇叭的物联网设备，就是插着4G卡那种，可以播放各种语音，仔细阅读了开发文档之后发现使用的是MQTT的协议，记录一下在对接中遇到的各种问题

MQTT是一个轻量的发布订阅模式消息传输协议，专门针对低带宽和不稳定网络环境的物联网应用设计。

MQTT特点：

阿里云的MQTT有两个版本，这里只说没有RocketMQ依赖的3.1.1及以上版本。

这里会自动生成用户名密码

阿里云消息中间件（MQ）探秘

阅读字数： 2513 | 5分钟阅读

获取嘉宾演讲视频及PPT ，请点击：

阿里巴巴中间技术专家不铭从功能特性、技术架构、最佳实践、案例分析四个方面进行了《Aliware-MQ消息队列》的分享。

Aliware-MQ是阿里云提供的企业级互联网架构的核心产品，基于高可用分布式集群技术，支持海量高并发和万亿级消息流转，支持海量的消息堆积，支持高可靠/高可用方案，提供了运维、监控等一系列完整的配套服务。

如上图所示，从消息的维度来看分为普通消息、顺序消息、定时消息和事务消息等四种消息,无论是发送哪种消息客户端都支持熔断机制，即如果发现发送目标节点有性能问题，客户端会自动进行熔断，把有问题的节点排出去，保证消息发往可靠性最高的机器。管理方面已经支持消息的查询、消息回溯、消息全链路轨迹和监控报警机制。性能上MQ已经达到了百亿级的堆积能力，毫秒级的投递延迟，支持万级节点高并发，集群水平热扩缩。消息消费方面，支持失败后的消息重投机制，失败的消息会重新投递到队列中去，现在最多支持16次重投。

上图是Aliware-MQ的功能架构。左边是控制台的管理，可以在上面做发布订阅管理。右边目前的接入方式是SDK支持TCP协议，同时也支持HTTP接口，以及面向手机终端的MQTT协议。

OpenAPI是MQ提供给用户的管控方式，用于实现一系列资源管理和运维功能，用户可以通过Open API查询所需要的任何东西。

上图中是我们今年推出的一个MQ移动物联网套件。之前的客户端，不管是上游还是下游收发都是用各自的服务器。但是今年我们有了移动物联网套件，可以直接面向终端设备。比如手机、汽车等移动设备利用移动物联网套件，通过一个网关就可以直接和消息系统打通。

Aliware-MQ的消息系统是基于队列。队列要保证数据安全，是支持高并发和高性能读写的最基本元素。

如上图所示，Producer是消息发送集群，下游的Consumer是消费者集群，都依赖于MQ的SDK。Broker是消息服务器，所有的消息都发送到Broker上面；Name Server和ZK功能类似，用来做服务发现。Producer要从Name Server获取到Topic在哪个节点上，订阅Topic时需要知道Topic从哪里取，同样需要Name Server。Broker上的Topic信息会定时在Name Server上注册，Producer和Consumer在交互之前会从Name Server上获取目标。

图中的master是主机，slave是备机，主备之间会做数据同步，有异步和同步两种方式。一个master可以布多个节点，这个根据自己的成本来决定。如果扩容的话，只要直接布一台master即可，它会定时地将Topic注册到Name Server上，发送方和订阅方也会定时地感知这个过程，整个扩容的过程对于用户来说大概30秒就能完成。

Aliware-MQ所有数据存储在Commit Log里，它在实现上就相当于一个文件夹，每次会生成一个1G的文件。不管哪个Topic写过来的消息都会直接写入这个文件中，这个文件写满后再直接写下一个。

针对每一个Topic，要在业务层面对它进行区分，所以我们做了一层索引。例如在上图中有5个队列，每个队列都会生成定长的索引文件，通过索引，可以找到这条消息当前处于哪个CommitLog文件的某个具体位置中。

这样存储结构，保证了无论多少个topic，CommitLog的写是顺序的，能较大的保证MQ的写入性能。

Aliware-MQ的负载均衡是按照队列维度来做的，消费的时候会把topic的队列平均分配给消费实例。比如有2个消费实例，topic队列是4个，那么每个消费实例就消费2个；而如果共有5个队列，那么就是是1个消费2个，另1个消费3个。一个队列同一时间只会被一个消费实例消费，所以当出现队列数量小于消费实例数量的情况时，就会有消费实例出现空闲，这个时候可以根据业务实际情况手动通过工具将队列数量调大。

消息写进来都是先放在Java堆里，然后再落盘。如果用户要消费的消息都在内存里，那么就可以很快的读取到。但是如果用户消息堆积比较久，消息已经不在内存里而是存储在了磁盘中，这个时候就需要去磁盘里取数据，然后加载到内存里面读取出来。

Aliware-MQ的刷盘策略有异步和同步两种。异步到内存就返回成功，同步写则一定是消息刷到磁盘中才会返回成功。这种刷盘方式可以根据业务的具体需求进行配置，从写入的性能来看，异步写的性能肯定是会比同步的好。

从发消息的角度来看，如果发送失败，会有补偿机制。MQ的客户端会做三次重发，一台机器发送失败之后会默认往另外两台机器再尝试，如果三次都失败了才会把最终的失败结果传回，这个时候用户需要自己对发送异常进行相关处理。

有幂等要求的业务，Consumer在使用的时候需要自己做去重操作，在一些场景下，如客户端本地等待超时等，是无法保证消息完全不重复的，因此用户在进行系统设计时需要考虑到这一点。

Aliware-MQ目前支持的消息最大是4M，消息越小，性能越高。定时消息是支持消息的定时投递，可以自行设置要投递的时间，最长是40天。事务消息通过两阶段的提交的方式，来解决分布式事务问题。顺序消息可以采用全局顺序、分区顺序，严格保证消息的顺序。

Aliware-MQ的使用场景主要有系统间异步解耦、分布式事务、异构数据复制与分发、双十一大促的削峰填谷、大规模机器的Cache同步、日志服务和IM实时通信以及实时计算分析。

MQ顺序消息分为全局有序和队列有序。全局有序是从指所有消息发出开始，下游的接收方都是按照顺序接收；队列有序则是将消息进行区块分区，同一个分区内的消息按照先入先出的顺序进行顺序消费，保证一个队列只会被一个进程消费。

当一个交易系统下单之后，会发一条消息到MQ，购物车接收消息把购物车里的状态清空。如果这时交易消息发送失败，购物车就无法清空，对于数据来说这就是一个脏数据。面对这种情况我们有事务消息可以解决这个问题，在交易开始时先发送一条半事务消息，然后交易系统开始下单，所有事情做完之后再提交半事务，这时只有主动提交成功，消息队列才会将这条消息实际发送给用户。如果交易下单过程失败，则可以主动回滚这条消息，购物车和交易系统之间可以做到没有脏数据。

双十一大促时，各个分会场会有玲琅满目的商品，每件商品的价格都会实时变化。使用缓存技术也无法满足对商品价格的访问需求，缓存服务器网卡跑满。访问较多次商品价格查询影响会场页面的打开速度。于是MQ提供了一种广播机制，本来一条消息只会被集群的一台机器消费。如果使用广播模式，那么这条消息会被集群下的所有节点消费一次，相当于把价格信息同步到需要的每台机器上，可以取代缓存的作用。

实时计算功能主要是做一个消息总线，业务系统自动采集数据，把消息分发达下游的实时计算系统里，根据实时计算结果来给业务方做服务。

我今天的分享就到这里，谢谢大家！

阿里云mqtt收费标准

以下是阿里云mqtt收费标准：

其中铂金版实例、标准版实例、轻量版实例是包年包月（预付费）。是一种预付费模式，即先付费再使用。一般适用于业务量较大且长期运行的场景，通过包年包月付费方式您可以提前预留资源，同时享受更大的价格优化，帮您最大程度节省成本。

还有就是按量付费实例是按量付费（后付费）。即是一种后付费模式，即先使用再付费。一般适用于业务流量波峰波谷差异明显或临时测试的场景，可以有效避免资源浪费。

微消息队列mqtt版费用组成：

按量付费包括：同时在线连接数；消息收发量；订阅关系数

包年包月包括：连接数上限；消息TPS上限；订阅关系数上限

计价倍率介绍：

MQTT协议QoS=0且cleanSession=true 1

MQTT协议QoS=0且cleanSession=false 1

MQTT协议QoS=1且cleanSession=true 2

MQTT协议QoS=1且cleanSession=false 5

MQTT协议QoS=2且cleanSession=true 5

简谈阿里云MQ消息队列云服务的计费模式

文章摘要：在阿里云上，就创建了一个消息队列的Topic，其他啥也没干，过了一天就欠阿里云2元了，消息队列这项云服务也太能吸金了吧？

最简单地说，消息队列就是消息在传输过程中用于保存消息的容器，在一次发送接收的通信过程中，其主要充当了“中转站”的角色，内部提供路由并保证消息的可靠传递。如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。

消息队列目前已经逐渐成为企业IT系统内部通信的核心手段之一，可以说当前绝大部分的大型分布式互联网业务系统都基于消息队列来构建的。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列的功能，成为异步通信的主要手段之一。

近几年，随着云计算技术的飞速发展，在IAAS产品已经相对成熟后，其他越来越多的产品也逐步推向了云端（很多中间件产品再用以前liences授权计费的方式已经不再受用）。MQ消息队列是中间件产品中比较重要的产品之一，其云化方案对于云计算平台能力的拓展与丰富有着重要的意义。

MQ（Message Queue）消息队列云服务是构成云计算核心能力不可或缺的一项产品，可以为云端的用户提供一种定义未来云端的应用开发和未来企业的技术架构方案的新方式。对于云端的消息队列服务，如果无法采用传统的liences授权方式计费，那么它又是如何计费的呢？今天我就向大家介绍下消息队列中间件这项云服务在阿里云上是怎么来计费的。

目前，阿里云上主要提供如下两种云化商用版MQ的计费模式：

（1） 预付费（包年包月，MQ 铂金版） ：即为业界常说的包周期云服务计费模式，云端客户根据自己的预算以几个月或者一年作为租赁使用周期进行预先付款结算。根据阿里云官方文档的说明：该种计费方式订购的MQ是：“专享实例，独占物理节点”；诸如“专家尊享通道 保价护航”、“SQL 属性过滤”、“数据传输加密”、“多路访问方式”、“VPC SingleTunnel 访问”和“消息轨迹”几个重要的功能特性方面都比（2）中的按量付费版要支持的更加全面和完善一些。其实，从性价比上面来说更加适合一些土豪级的企业级大客户来用了。对于这类用户，可能本身不会去过多的研究MQ的一些关键技术，可以完全依托于阿里云的MQ产品 研发团队核心成员直接为自己的云端系统的构建，提供较为全面的MQ技术支持。

（2） 后付费（按量计费） ：即为按量后付费的云服务计费模式，阿里云按照客户端的使用情况（一般，按照“Topic占用时长”+“API的调用次数”来计费的，具体的计费方法后面还会再讲）。各方面的功能都弱于（1）中的预付费版本。这种方式比较适合对MQ关键技术有一定了解的初中级使用者，完全可以按照自己的需求来构建适合云端业务系统的MQ。

解读：从上面这段阿里云官网上的计费项目说明中，可以得出以下几点关键信息：

（1） Topic资源占用费 ：这部分费用可能往往会被用户忽略。使用MQ消息队列云服务的费用实际是包含两部分的，也就是说像我一样虽然没有用阿里云的MQ消息队列进行消息的发送和消费，但是因为创建并占用着一个Topic一天（ Topic也是MQ消息队列资源的一部分 ），因此也会对我的账户进行扣费。所以，这里也提醒各位使用阿里云MQ消息队列云服务的各位童鞋要注意下，对于自己不用的Topic尽快删除，否则也会产生资费；

（2） API调用次数 ：这部分的第一点应该比较好理解，对于MQ消息队列的使用（即为消息的发送和接收），需要按照调用Client端的API发送消息或者消费消息的次数来进行累计产生资费。但是，对于第二点没有实际使用过RocketMQ的童鞋可能不太好理解。在RocketMQ中，在Push的消费模式中有长轮询机制，如果Consumer端第一次发送Pull消息的请求至Broker，此时Broker端尚无可消费的消息时，会先hold住该Pull消息的请求，通过Broker端的两个后台线程服务—PullRequestHoldService和ReputMessageService来重新尝试Pull消息和二次处理。这里，默认长轮询的RPC通信的超时时间为30s，而Broker端挂起Pull消息请求的最长时间即为15s。从这里来看，第一次hold住Pull请求的15s是不计费长轮询次数的（即为不计费的，我认为因为hold住Pull请求是broker端来完成的本身就不会带来PRC远程通信的一次调用），倘若第二次从consumer端再发起长轮询请求则会进行计费，我个人想想觉得也合理的，因为毕竟会耗费一次RPC的远程通信访问。

这里列出下阿里云MQ消息队列云服务两种计费项目的列表展示：

对于上面的计费说明，从中可以看出关键信息有如下几点：

（1）阿里云MQ消息队列云服务是支持ACL权限分配的，可以将主账号创建的Topic分配给子帐号使用，子帐号产生的计费将会算到主账号上；

（2）MQ的后付费产品的结算方式应该是采用了根据出MQ云服务资源计量文件以后次日（T+1日来根据资源计量文件生成账单从账户扣费），这种方式就会存在余额不足的小风险（ps：欠费72小时后阿里云会自动清理该用户下面的Topic及其未消费而积压的存量消息）；

（3）计费中比较关键的一点是“每 4 KB 发布或订阅数据以 1 次请求计费”，我认为这一点倒也合乎情理，消息发送或者接收本质上来说是一次RPC通信（基于TCP连接），那么按照消息大小来合理设置请求计费次数，即为对占用TCP带宽大小和吞吐量的计费。这一点在用户使用时候可能会忽略；

（4）事务消息、顺序消息和定时消息均比普通消息的计费价格来得更贵更高，所以使用的童鞋要好好考虑下发送和订阅这三类消息产生的资费问题；

本文主要根据自己在阿里云上使用MQ消息队列云服务的一些经验展开叙述，从技术开发者的视角来看MQ消息队列云服务的产品概念和定义，并对阿里云MQ消息队列云服务的计费模式和方法进行深入分析。限于笔者的才疏学浅，对本文内容可能还有理解不到位的地方，如有阐述不合理之处还望留言一起探讨。

ons 阿里云 rocketMQ

ons 默认有两个brokerName组,分别有0-7共16个队列

还有两个死信队列 topic是 %RETRY%+tag

consumer15分钟消费超时，broker会重发消息

轮询发送到broker队列

如果发送失败会换个队列

自动创建topic时设置队列数量

ons不允许自动创建topic，也不允许修改队列数量

平均分配可消费的 Broker 对应的消息队列 c1对应b1,b2,b3 c2对应d1,d2,d3

以环状轮流分Broker

每个Consume都订阅每个Broker