行列步队中间件是分布式系统中主要的组件，紧张办理运用解耦，异步，流量削锋等问题，实现高性能，高可用，可伸缩和终极同等性架构。目前利用较多的行列步队有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ
二、行列步队运用处景
以下先容行列步队在实际运用中常用的利用场景。异步处理，运用解耦，流量削锋和通讯四个场景。
2.1异步处理
场景解释：用户注册后，须要发注册邮件和注册短信。传统的做法有两种 1.串行的办法；2.并行办法
a、串行办法：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。
b、并行办法：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的办法可以提高处理的韶光
假设三个业务节点每个利用50毫秒钟，不考虑网络等其他开销，则串行办法的韶光是150毫秒，并行的韶光可能是100毫秒。
由于CPU在单位韶光内处理的要求数是一定的，假设CPU1秒内吞吐量是100次。则串行办法1秒内CPU可处理的要求量是7次（1000/150）。并行办法处理的要求量是10次（1000/100）
小结：如以上案例描述，传统的办法系统的性能（并发量，吞吐量，相应韶光）会有瓶颈。如何办理这个问题呢？
引入行列步队，将不是必须的业务逻辑，异步处理。改造后的架构如下：
按照以上约定，用户的相应韶光相称于是注册信息写入数据库的韶光，也便是50毫秒。注册邮件，发送短信写入行列步队后，直接返回，因此写入行列步队的速率很快，基本可以忽略，因此用户的相应韶光可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。
2.2运用解耦
场景解释：用户下单后，订单系统须要关照库存系统。传统的做法是，订单系统调用库存系统的接口。如下图：
传统模式的缺陷：如果库存系统无法访问，则订单减库存将失落败，从而导致订单失落败，订单系统与库存系统耦合
如何办理以上问题呢？引入运用行列步队后的方案，如下图：
订单系统：用户下单后，订单系统完成持久化处理，将写入行列步队，返回用户订单下单成功
库存系统：订阅下单的，采取拉/推的办法，获取下单信息，库存系统根据下单信息，进行库存操作
如果：不才单时库存系统不能正常利用。也不影响正常下单，由于下单后，订单系统写入行列步队就不再关心其他的后续操作了。实现订单系统与库存系统的运用解耦
2.3流量削锋
流量削锋也是行列步队中的常用场景，一样平常在秒杀或团抢活动中利用广泛。
运用处景：秒杀活动，一样平常会由于流量过大，导致流量暴增，运用挂掉。为办理这个问题，一样平常须要在运用前端加入行列步队。
a、可以掌握活动的人数
b、可以缓解短韶光内高流量压垮运用
用户的要求，做事器吸收后，首先写入行列步队。如果行列步队长度超过最大数量，则直接抛弃用户要求或跳转到缺点页面。
秒杀业务根据行列步队中的要求信息，再做后续处理
2.4日志处理
日志处理是指将行列步队用在日志处理中，比如Kafka的运用，办理大量日志传输的问题。架构简化如下
日志采集客户端，卖力日志数据采集，定时写受写入Kafka行列步队
Kafka行列步队，卖力日志数据的吸收，存储和转发
日志处理运用：订阅并消费kafka行列步队中的日志数据
2.5通讯
通讯是指，行列步队一样平常都内置了高效的通信机制，因此也可以用在纯的通讯。比如实现点对点行列步队，或者谈天室等
点对点通讯：
客户端A和客户端B利用同一行列步队，进行通讯。
谈天室通讯：
客户端A，客户端B，客户端N订阅同一主题，进行发布和吸收。实现类似谈天室效果。
以上实际是行列步队的两种模式，点对点或发布订阅模式。模型为示意图，供参考。
三、中间件示例
3.1电商系统
行列步队采取高可用，可持久化的中间件。比如Active MQ，Rabbit MQ，Rocket Mq。
（1）运用将主干逻辑处理完成后，写入行列步队。发送是否成功可以开启的确认模式。（行列步队返回吸收成功状态后，运用再返回，这样保障的完全性）
（2）扩展流程（发短信，配送处理）订阅行列步队。采取推或拉的办法获取消息并处理。
（3）将运用解耦的同时，带来了数据同等性问题，可以采取终极同等性办法办理。比如主数据写入数据库，扩展运用根据行列步队，并结合数据库办法实现基于行列步队的后续处理。
3.2日志网络系统
分为Zookeeper注册中央，日志网络客户端，Kafka集群和Storm集群（OtherApp）四部分组成。
Zookeeper注册中央，提出负载均衡和地址查找做事
日志网络客户端，用于采集运用系统的日志，并将数据推送到kafka行列步队
Kafka集群：吸收，路由，存储，转发等处理
Storm集群：与OtherApp处于同一级别，采取拉的办法消费行列步队中的数据
四、JMS做事
讲行列步队就不得不提JMS 。JMS（JAVA Message Service，java做事）API是一个做事的标准/规范，许可运用程序组件基于JavaEE平台创建、发送、吸收和读取消息。它使分布式通信耦合度更低，做事更加可靠以及异步性。
在EJB架构中，有bean可以无缝的与JM做事集成。在J2EE架构模式中，有做事者模式，用于实现与运用直接的解耦。
4.1模型
在JMS标准中，有两种模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。
4.1.1 P2P模式
P2P模式包含三个角色：行列步队（Queue），发送者(Sender)，吸收者(Receiver)。每个都被发送到一个特定的行列步队，吸收者从行列步队中获取消息。行列步队保留着，直到他们被消费或超时。
P2P的特点
每个只有一个消费者（Consumer）(即一旦被消费，就不再在行列步队中)
发送者和吸收者之间在韶光上没有依赖性，也便是说当发送者发送了之后，不管吸收者有没有正在运行，它不会影响到被发送到行列步队
吸收者在成功吸收之后需向行列步队应答成功
如果希望发送的每个都会被成功处理的话，那么须要P2P模式。
4.1.2 Pub/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等则须要利用第三方的中间件。本部分内容先容常用的中间件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他们的特点。
5.1 ActiveMQ
ActiveMQ 是Apache出品，最盛行的，能力强劲的开源总线。ActiveMQ 是一个完备支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，只管JMS规范出台已经是良久的事情了，但是JMS在当今的J2EE运用中间仍旧扮演着分外的地位。
ActiveMQ特性如下：
⒈ 多种措辞和协议编写客户端。措辞: Java,C,C++,C#,Ruby,Perl,Python,PHP。运用协议： OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完备支持JMS1.1和J2EE 1.4规范 （持久化，XA，事务)
⒊ 对Spring的支持，ActiveMQ可以很随意马虎内嵌到利用Spring的系统里面去，而且也支持Spring2.0的特性
⒋ 通过了常见J2EE做事器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的测试，个中通过JCA 1.5 resource adaptors的配置，可以让ActiveMQ可以自动的支配到任何兼容J2EE 1.4 商业做事器上
⒌ 支持多种传送协议：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通过JDBC和journal供应高速的持久化
⒎ 从设计上担保了高性能的集群，客户端-做事器，点对点
⒏ 支持Ajax
⒐ 支持与Axis的整合
⒑ 可以很随意马虎得调用内嵌JMS provider，进行测试
5.2 Kafka
Kafka是一种高吞吐量的分布式发布订阅系统，它可以处理消费者规模的网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在当代网络上的许多社会功能的一个关键成分。 这些数据常日是由于吞吐量的哀求而通过处理日志和日志聚合来办理。 对付像Hadoop的一样的日志数据和离线剖析系统，但又哀求实时处理的限定，这是一个可行的办理方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的处理，也是为了通过集群机来供应实时的消费。
Kafka是一种高吞吐量的分布式发布订阅系统，有如下特性：
通过O(1)的磁盘数据构造供应的持久化，这种构造对付纵然数以TB的存储也能够保持永劫光的稳定性能。（文件追加的办法写入数据，过期的数据定期删除）
高吞吐量：纵然是非常普通的硬件Kafka也可以支持每秒数百万的
支持通过Kafka做事器和消费机集群来分区
支持Hadoop并行数据加载
Kafka干系观点
Broker
Kafka集群包含一个或多个做事器，这种做事器被称为broker[5]
Topic
每条发布到Kafka集群的都有一个种别，这个种别被称为Topic。（物理上不同Topic的分开存储，逻辑上一个Topic的虽然保存于一个或多个broker上但用户只需指定的Topic即可生产或消费数据而不必关心数据存于何处）
Partition
Parition是物理上的观点，每个Topic包含一个或多个Partition.
Producer
卖力发布到Kafka broker
Consumer
消费者，向Kafka broker读取消息的客户端。
Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
一样平常运用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢数据）哀求稍低的场景利用。
