在阿里云生态日，阿里巴巴中间件产品专家不铭分享了《Aliware-MQ消息队列》。他从功能特性、技术架构、最佳实践、案例分析四个方面进行了分享。在分享中，他主要介绍了Aliware-MQ的线性扩展技术、存储模型、负载均衡、数据流、刷盘策略、高可靠/高可用方案进行了介绍，并通过案例进行了具体实践分享。

以下内容根据直播视频整理而成。

功能特性

Aliware-MQ是什么？它是企业级互联网架构的核心产品，基于高可用分布式集群技术，支持海量高并发，支持万亿级消息流转（双十一的万亿数据），支持海量的消息堆积，支持高可靠/高可用方案，提供运维、监控等一套完整的配套服务。

Aliware-MQ的功能特性如上图所示。它支持四种消息：普通消息、顺序消息、定时消息、事务消息。管理方面支持消息查询、消息回溯、全链路轨迹（消息发出到接收经过的链路）、监控报警机制。熔断机制是指把有问题的节点自动熔断，发送到可靠性最高的机器上。消息重投机制是指发送失败后重新投递消息，最多支持十六次的重投。

Aliware-MQ的功能架构图如上图所示。左边是控制台的管理，右边的接入方式支持TCP协议、HTTP协议和MQTT协议（面向手机终端的协议）。服务端包括了消息发送和订阅。

Open API是MQ提供给用户的管控方式，用于实现一系列资源管理和运维功能。把控制台功能包装成API对外提供，用户可以通过Open API查询所需要的任何东西，主要用来做运维管控。

上图是今年推出的Aliware-MQ移动物联网套件。之前的客户端，不管上游、下游发或收都不面向用户端，而是面向服务器。而移动互联网套件可以直接面向手机、汽车等移动设备，可以直接通过网关把消息系统打通。

技术架构

消息系统是基于队列的。队列要保证数据安全，要支持高并发、高性能读写，要足够大，要支持足够多数量。

上图中Producer是消息发送集群，下游是Consumer消费者集群，Broker是服务器，所有的消息都发送到服务器上，Name Server集群和VK功能类似，用来做服务发现。消息发送需要从Name Server获取到，订阅Topic时需要知道消息从哪里取同样需要Name Server。Broker上的Topic信息会定时向Name Server注册，Producer和Consumer在交互之前会从Name Server上获取目标。其中，master是主机，slave是备机，主备之间会做数据同步（异步和同步两种方式），一个master可以布多个节点。如果扩容的话，直接布一台master即可，它会自动将Topic注册到Name Server上。

Aliware-MQ所有数据存储在Commit Log里，实现上就相当于一个文件夹，每次会生成一个1G的文件，不管哪个Topic写消息都会直接存入这个文件中，直到存满。做索引的目的是为了区分每个Topic。上图中有5个队列，每个队列会生成定长的文件，会告诉我们这个Topic在哪个文件中。

Aliware-MQ的负载均衡比较简单。如果有5个队列，在消息量比较大的时候会平均分配到这5个队列中。消费负载均衡策略也比较简单，如果有两个订阅者，而总共有5个队列，那么其中一个消费两个，另一个消费三个。当队列数量小于订阅者数量时，需要根据业务实际情况手动将队列数量调大。

消息写进来先放在Java堆里，然后再到内存。对于用户，如果消息都在内存里，那么直接读走。但是有一种可能，消息堆积比较久，已经存储在了磁盘中，此时就需要从磁盘里加载数据，然后从内存中读取出来。如果一台机器上的用户量比较大，都在读取磁盘，磁盘IO占用比较高（可能达到100%），所以针对堆积比较多的业务需要单独划出来保证业务上不互相影响。

Aliware-MQ的刷盘策略包括两个：异步写，没有刷盘就返回成功；同步写，一定是消息刷到磁盘中才会返回成功。

Aliware-MQ的高可靠方案如上图所示。主备机有两种方案：一是备机不切，如果主机挂掉了，备机上有主机挂掉之前的全部数据，所有在主机上还未消费的事情都可以在备机上来读，备机不会切换成主机，只对外提供读的方案；二是备机可切，当主机挂掉之后，备机会切换为主机同时对外提供读和写的功能。主备同步的方案也有两种：一是同步；二是异步地同步，在主机宕机后可能出现一定的消息丢失。

最佳实践

对于Producer，有消息的失败补偿机制，一台机器发送失败之后会默认往另外两台机器再尝试，如果三次都失败了才会把最终的失败结果传回；可追踪机制，通过trace功能把整条链路追踪出来；One-way发送，没有返回接口，发出来是不可靠的，发出来就算成功。对于Consumer，需要做幂等性，没办法保证消息完全不重复，所以将其交给用户来做；做批量处理和并发性。

案例分析

Aliware-MQ的普通消息最大4M，消息越小，性能越高；定时消息可以实现消息的延时或者定时投递，最长40天；事务消息可以两阶段提交、解决分布式事务问题；顺序消息可以采用全局顺序、分区顺序，严格保证消息的顺序。

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

削峰填谷

双十一时有一个案例：内部有一个系统TP是做交易的，每一次下单都会在TP里面创建一笔订单，创建好订单后会调用物流LC接口，物流订单创建成功后又会调用交易接口。此过程中，交易TP和菜鸟LC是耦合的，但是从业务角度来看，实际上物流订单的创建是可以有一定延迟的。所以消息系统需要解耦，订单创建完成之后发一条消息到MQ，LC根据自己的业务需求去MQ来拉消息，这样就可以用少量的机器完成任务。

MQ顺序消息

MQ顺序消息分为两种情况：全局顺序，对于指定的一个Topic，所有消息将按照严格的先入先出的顺序，进行顺发布和顺序消费；分区顺序，对于指定的一个Topic，所有消息根据shardingkey进行区块分区，同一个分区内的消息将按照严格的先入先出的顺序，进行顺发布和顺序消费，可以保证一个消息被一个进程消费。

其中一个应用是，双十一要做买卖家的消息同步，即把买家数据同步到卖家库，具体来说根据seller_id做hash写到MQ的不同队列里面去，消费方来拉取每一个seller_id的消息，找到自己对应的卖家库进行同步。

分布式事务

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

大规模机器的Cache同步

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

实时计算

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

MQ应用案例

上图是管易用户通过MQ来做订单的流转、商品库存、实时监控的案例。