文章摘要：在阿里云上，就创建了一个消息队列的Topic，其他啥也没干，过了一天就欠阿里云2元了，消息队列这项云服务也太能吸金了吧？
一、谈谈MQ消息队列的产品概念
最简单地说，消息队列就是消息在传输过程中用于保存消息的容器，在一次发送接收的通信过程中，其主要充当了“中转站”的角色，内部提供路由并保证消息的可靠传递。如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。
消息队列目前已经逐渐成为企业IT系统内部通信的核心手段之一，可以说当前绝大部分的大型分布式互联网业务系统都基于消息队列来构建的。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列的功能，成为异步通信的主要手段之一。
二、MQ消息队列云服务产品定义
近几年，随着云计算技术的飞速发展，在IAAS产品已经相对成熟后，其他越来越多的产品也逐步推向了云端（很多中间件产品再用以前liences授权计费的方式已经不再受用）。MQ消息队列是中间件产品中比较重要的产品之一，其云化方案对于云计算平台能力的拓展与丰富有着重要的意义。
MQ（Message Queue）消息队列云服务是构成云计算核心能力不可或缺的一项产品，可以为云端的用户提供一种定义未来云端的应用开发和未来企业的技术架构方案的新方式。对于云端的消息队列服务，如果无法采用传统的liences授权方式计费，那么它又是如何计费的呢？今天小编就向大家介绍下消息队列中间件这项云服务在阿里云上是怎么来计费的。
三、阿里云MQ消息队列云服务的计费方式
3.1、两种主要的消息队列云服务计费模式
目前，阿里云上主要提供如下两种云化商用版MQ的计费模式：
（1）预付费（包年包月，MQ 铂金版）：即为业界常说的包周期云服务计费模式，云端客户根据自己的预算以几个月或者一年作为租赁使用周期进行预先付款结算。根据阿里云官方文档的说明：该种计费方式订购的MQ是：“专享实例，独占物理节点”；诸如“专家尊享通道 & 保价护航”、“SQL 属性过滤”、“数据传输加密”、“多路访问方式”、“VPC SingleTunnel 访问”和“消息轨迹”几个重要的功能特性方面都比（2）中的按量付费版要支持的更加全面和完善一些。其实，从性价比上面来说更加适合一些土豪级的企业级大客户来用了。对于这类用户，可能本身不会去过多的研究MQ的一些关键技术，可以完全依托于阿里云的MQ产品 & 研发团队核心成员直接为自己的云端系统的构建，提供较为全面的MQ技术支持。
（2）后付费（按量计费）：即为按量后付费的云服务计费模式，阿里云按照客户端的使用情况（一般，按照“Topic占用时长”+“API的调用次数”来计费的，具体的计费方法后面还会再讲）。各方面的功能都弱于（1）中的预付费版本。这种方式比较适合对MQ关键技术有一定了解的初中级使用者，完全可以按照自己的需求来构建适合云端业务系统的MQ。
3.2、阿里云MQ消息队列云服务的计费方法
MQ 费用 = API 调用费 + Topic 资源占用费
API 调用次数 = 发送消息 API 调用次数 + 订阅消息 API 调用次数 + 长轮询 API 调用次数（长轮询说明：MQ Consumer 为保证消息实时推送而产生的 API 调用，每个队列 15 秒一次长轮询，在此期间，若队列内有消息产生，则不计长轮询次数）。（摘自阿里云官网）
解读：从上面这段阿里云官网上的计费项目说明中，可以得出以下几点关键信息：
（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消息队列云服务两种计费项目的列表展示：
从这张阿里云官方的表格上面可以看出，无论是“按照API调用次数计费”还是“按照Topic的资源占用计费”都是采用阶梯计费方式。基本上采用的计费策略是，发送和消费的消息的调用次数越多则“每个Topic每日费用”和“每百万次费用”越便宜，这个倒是也符合批量销售云服务资源的原则哦！
另外，对于其中具体的实现，小编大胆地猜测下阿里云MQ消息队列云服务的Broker端可能是采用类似开源版本中的Broker状态统计服务实现类—BrokerStatsManager（内部构建定时任务）的方式，来做到对Topic占用时长和API调用次数的汇总统计，同时借助RocketMQ本身的store存储服务能力来持久化这些汇总统计的数据log至磁盘上。不过，这里需要考虑好如何解决Topic中多个messageQueue消息队列分布在不同broker上的数据统计问题。
3.3、阿里云MQ消息队列云服务的计费说明
- MQ 后付费产品，每小时进行一次结算，每 24 小时出一次账单（次日出账单），费用将自动从账户余额中扣除；
- Topic 资源占用费按每个 Topic 每日 API 调用次数阶梯计费，主-主账号授权双方均正常计费，主-子账号授权所有计费归属主账号；不再使用的 Topic 请及时删除，避免产生不必要的费用；
- 调用发送接收 API 均计费，计量单位为百万次；API 调用次数包括长轮询 API 的调用，正常收发消息时，不会产生多余长轮询 API 调用；
- 消息体大小最大限制为 4 MB，每 4 KB 发布或订阅数据以 1 次请求计费。例如，1 次负载（发布或订阅）为 256 KB 的 API 调用将以 256/4 次请求计费；
- 事务消息发布请求 1 次按照 50 次计费，订阅按照普通消息计费。例如，发布事务消息 1 次，订阅该消息 1 次，按照 50+1=51 次 API 调用计费；
- 顺序消息发布请求 1 次按照 25 次计费，订阅请求 1 次按照 25 次计费。例如，发布顺序消息 1 次，订阅该消息 1 次，按照 25+25=50 次 API 调用计费；
- 定时消息发布请求一次按照 25 次计费，订阅按照普通消息计费。例如，发布定时消息 1 次，订阅该消息1 次，按照 25+1=26 次 API 调用计费；（摘自阿里云官网）
对于上面的计费说明，从中可以看出关键信息有如下几点：
（1）阿里云MQ消息队列云服务是支持ACL权限分配的，可以将主账号创建的Topic分配给子帐号使用，子帐号产生的计费将会算到主账号上；
（2）MQ的后付费产品的结算方式应该是采用了根据出MQ云服务资源计量文件以后次日（T+1日来根据资源计量文件生成账单从账户扣费），这种方式就会存在余额不足的小风险（ps：欠费72小时后阿里云会自动清理该用户下面的Topic及其未消费而积压的存量消息）；
（3）计费中比较关键的一点是“每 4 KB 发布或订阅数据以 1 次请求计费”，小编认为这一点倒也合乎情理，消息发送或者接收本质上来说是一次RPC通信（基于TCP连接），那么按照消息大小来合理设置请求计费次数，即为对占用TCP带宽大小和吞吐量的计费。这一点在用户使用时候可能会忽略；
（4）事务消息、顺序消息和定时消息均比普通消息的计费价格来得更贵更高，所以使用的童鞋要好好考虑下发送和订阅这三类消息产生的资费问题；
四、总结
本文主要根据自己在阿里云上使用MQ消息队列云服务的一些经验展开叙述，从技术开发者的视角来看MQ消息队列云服务的产品概念和定义，并对阿里云MQ消息队列云服务的计费模式和方法进行深入分析。限于笔者的才疏学浅，对本文内容可能还有理解不到位的地方，如有阐述不合理之处还望留言一起探讨。
