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

摘要

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

内容来源：2017年6月4日，阿里巴巴中间件技术部消息中间件技术专家周礼（不铭）在“企业互联网架构优化升级之路”进行《阿里云消息中间件（MQ）原理及实践》演讲分享。IT 大咖说做为独家视频合做方，经主办方和讲者审阅受权发布。

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

嘉宾演讲视频回放：t.cn/RHt7T9e

功能特性

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提供了一种广播机制，原本一条消息只会被集群的一台机器消费。若是使用广播模式，那么这条消息会被集群下的全部节点消费一次，至关于把价格信息同步到须要的每台机器上，能够取代缓存的做用。

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

我今天的分享就到这里，谢谢你们！