消息队列应用场景介绍及异步处理场景说明书

一、消息队列概述

消息队列中间件是分布式系统中重要的组件，主要解决应用前馈，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性构架。目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ

二、消息队列应用场景

以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用前馈，流量削锋和消息通信四个场景。

2.1异步处理

场景说明：用户注册后，须要发注册短信和注册邮件。传统的做法有两种1.串行的方法；2.并行形式

a、串行方法：将注册信息写入数据库成功后，发送注册电邮，再发送注册邮件。以上三个任务全部完成后，返回给顾客端。

b、并行形式：将注册信息写入数据库成功后，发送注册短信的同时，发送注册邮件。以上三个任务完成后，返回给顾客端。与串行的差异是，并行的方法可以提升处理的时间

假定三个业务节点每位使用50毫秒钟，不考虑网路等其他开支，则串行形式的时间是150纳秒，并行的时间可能是100纳秒。

由于CPU在单位时间内处理的恳求数是一定的，假定CPU1秒内吞吐量是100次。则串行形式一秒内CPU可处理的恳求量是7次（1000/150）。并行形式处理的恳求量是10次（1000/100）

小结：如以上案例描述，传统的方法系统的性能（并发量，吞吐量，响应时间）会有困局。怎么解决这个问题呢？

引入消息队列，将不是必须的业务逻辑，异步处理。改建后的构架如下：

根据以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50纳秒。注册电邮，发送邮件写入消息队列后，直接返回，因而写入消息队列的速率很快，基本可以忽视，因而用户的响应时间可能是50纳秒。因而构架改变后，系统的吞吐量提升到每秒20QPS。比串行提升了3倍消息队列使用流程图，比并行提升了两倍。

2.2应用前馈

场景说明：用户下单后，订单系统须要通知库存系统。传统的做法是，订单系统调用库存系统的插口。如右图：

传统模式的缺点：如果库存系统未能访问，则订单减库存将失败，因而造成订单失败，订单系统与库存系统耦合

怎样解决以上问题呢？引入应用消息队列后的方案，如右图：

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功

库存系统：订阅下单的消息，采用拉/推的形式，获取下单信息，库存系统按照下单信息，进行库存操作

如果：在下单时库存系统不能正常使用。也不影响正常下单，由于下单后，订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用前馈

2.3流量削锋

流量削锋也是消息队列中的常用场景，通常在秒杀或团抢活动中使用广泛。

应用场景：秒杀活动，通常会由于流量过大，致使流量暴增，应用死掉。为解决这个问题，通常须要在应用后端加入消息队列。

a、可以控制活动的人数

b、可以减轻短时间内高流量拖垮应用

用户的恳求，服务器接收后，首先写入消息队列。如果消息队列宽度超过最大数目，则直接抛弃用户恳求或跳转到错误页面。

秒杀业务依据消息队列中的恳求信息，再做后续处理

2.4日志处理

日志处理是指将消息队列用在日志处理中，例如Kafka的应用，解决大量日志传输的问题。构架简化如下

日志采集顾客端，负责日志数据采集，定时写受写入Kafka队列

Kafka消息队列，负责日志数据的接收，储存和转发

日志处理应用：订阅并消费kafka队列中的日志数据

2.5消息通信

消息通信是指，消息队列通常都外置了高效的通讯机制，因而也可以用在纯的消息通信。例如实现点对点消息队列，或则聊天室等

点对点通信：

顾客端A和顾客端B使用同一队列，进行消息通信。

聊天室通信：

顾客端A，顾客端B，顾客端N订阅同一主题，进行消息发布和接收。实现类似聊天室疗效。

以上实际是消息队列的两种消息模式，点对点或发布订阅模式。模型为示意图，供参考。

三、消息中间件示例

3.1电商系统

消息队列采用高可用，可持久化的消息中间件。例如ActiveMQ，RabbitMQ消息队列使用流程图，RocketMq。

（1）应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。（消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性）

（2）扩充流程（发邮件，配送处理）订阅队列消息。采用推或拉的形式获取消息并处理。

（3）消息将应用前馈的同时，带来了数据一致性问题，可以采用最终一致性方法解决。例如主数据写入数据库，扩充应用依据消息队列，并结合数据库方法实现基于消息队列的后续处理。

3.2日志搜集系统

分为Zookeeper注册中心，日志搜集顾客端，Kafka集群和Storm集群（OtherApp）四部份组成。

Zookeeper注册中心，提出负载均衡和地址查找服务

日志搜集顾客端，用于采集应用系统的日志，并将数据推送到kafka队列

Kafka集群：接收，路由，储存，转发等消息处理

Storm集群：与OtherApp处于同一级别，采用拉的形式消费队列中的数据

四、JMS消息服务

讲消息队列就不得不提JMS。JMS（JAVAMessageService，java消息服务）API是一个消息服务的标准/规范，容许应用程序组件基于JavaEE平台创建、发送、接收和读取消息。它使分布式通讯耦合度更低，消息服务愈发可靠以及异步性。

在EJB构架中，有消息bean可以无缝的与JM消息服务集成。在J2EE构架模式中，有消息服务者模式，用于实现消息与应用直接的前馈。

4.1消息模型

在JMS标准中，有两种消息模型P2P（PointtoPoint）,Publish/Subscribe(Pub/Sub)。

4.1.1P2P模式

P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每位消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直至她们被消费或超时。

P2P的特征

每位消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)

发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息以后，不管接收者有没有正在运行，它不会影响到消息被发送到队列

接收者在成功接收消息以后需向队列应答成功

假如希望发送的每位消息就会被成功处理的话，这么须要P2P模式。

4.1.2Pub/Sub模式

包含三个角色主题（Topic），发布者（Publisher），订阅者（Subscriber）多个发布者将消息发送到Topic，系统将这种消息传递给多个订阅者。

Pub/Sub的特征

每位消息可以有多个消费者

发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者然后，就能消费发布者的消息

为了消费消息，订阅者必须保持运行的状态

为了缓和这样严格的时间相关性，JMS容许订阅者创建一个可持久化的订阅。这样，虽然订阅者没有被激活（运行），它也能接收到发布者的消息。

假如希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，这么可以采用Pub/Sub模型。

4.2消息消费

在JMS中，消息的形成和消费都是异步的。对于消费来说，JMS的消息者可以通过两种方法来消费消息。

（1）同步

订阅者或接收者通过receive方式来接收消息，receive方式在接收到消息之前（或超时之前）将始终阻塞；

（2）异步

订阅者或接收者可以注册为一个消息窃听器。当消息抵达以后，系统手动调用窃听器的onMessage方式。

JNDI：Java命名和目录插口,是一种标准的Java命名系统插口。可以在网路上查找和访问服务。通过指定一个资源名称，该名称对应于数据库或命名服务中的一个记录，同时返回资源联接构建所必须的信息。

JNDI在JMS中起到查找和访问发送目标或消息来源的作用。

五、常用消息队列

通常商用的容器，例如WebLogic，JBoss，都支持JMS标准，开发上很便捷。但免费的诸如Tomcat，Jetty等则须要使用第三方的消息中间件。本部份内容介绍常用的消息中间件（ActiveMQ,RabbitMQ，ZeroMQ,Kafka）以及她们的特征。

5.1ActiveMQ

ActiveMQ是Apache出品，最流行的，能力强劲的开源消息总线。ActiveMQ是一个完全支持JMS1.1和J2EE1.4规范的JMSProvider实现，虽然JMS规范颁布早已是许久的事情了，而且JMS在现今的J2EE应用中间一直饰演着特殊的地位。

ActiveMQ特点如下：

⒈多种语言和合同编撰顾客端。语言:Java,C,C++,C#,Ruby,Perl,Python,PHP。应用合同：OpenWire,StompREST,WSNotification,XMPP,AMQP

⒉完全支持JMS1.1和J2EE1.4规范（持久化，XA消息，事务)

⒊对Spring的支持，ActiveMQ可以很容易内嵌到使用Spring的系统上面去，但是也支持Spring2.0的特点

⒋通过了常见J2EE服务器（如Geronimo,JBoss4,GlassFish,WebLogic)的测试，其中通过JCA1.5resourceadaptors的配置，可以让ActiveMQ可以手动的布署到任何兼容J2EE1.4商业服务器上

⒌支持多种传送合同：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA

⒍支持通过JDBC和journal提供高速的消息持久化

⒎从设计上保证了高性能的集群，顾客端-服务器，点对点

⒏支持Ajax

⒐支持与Axis的整合

⒑可以很容易得调用内嵌JMSprovider，进行测试

5.2Kafka

Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者规模的网站中的所有动作流数据。这些动作（网页浏览，搜索和其他用户的行动）是在现代网路上的许多社会功能的一个关键诱因。这种数据一般是因为吞吐量的要求而通过处理日志和日志聚合来解决。对于像Hadoop的一样的日志数据和离线剖析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群机来提供实时的消费。

Kafka是一种高吞吐量的分布式发布订阅消息系统，有如下特点：

通过O(1)的c盘数据结构提供消息的持久化，这些结构对于虽然数以TB的消息储存也就能保持长时间的稳定性能。（文件追加的形式写入数据，过期的数据定期删掉）

高吞吐量：虽然是十分普通的硬件Kafka也可以支持每秒数百万的消息

支持通过Kafka服务器和消费机集群来分区消息

支持Hadoop并行数据加载

Kafka相关概念

Broker

Kafka集群包含一个或多个服务器，这些服务器被称为broker[5]

Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（化学上不同Topic的消息分开储存，逻辑上一个Topic的消息其实保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而毋须关心数据存于何处）

Partition

Parition是化学上的概念，每位Topic包含一个或多个Partition.

Producer

负责发布消息到Kafkabroker

Consumer

消息消费者，向Kafkabroker读取消息的顾客端。

ConsumerGroup

每位Consumer属于一个特定的ConsumerGroup（可为每位Consumer指定groupname，若不指定groupname则属于默认的group）。

通常应用在大数据日志处理或对实时性（少量延后），可靠性（少量丢数据）要求稍低的场景使用。