消息中间件

消息中间件产生背景

1.在网络通讯中，Http请求默认采用同步请求方式，基于请求与响应模式

2.在客户端与服务器进行通讯时，客户端调用服务端接口后，必须等待服务端完成处理后返回结果给客户端才能继续执行，这种情况属于同步调用方式。

3.如果服务器端发生网络延迟、不可达的情况，可能客户端也会受到影响。

网络通讯采用同步方式优缺点：

• 优点：及时响应数据给客户端，整个过程同步
• 缺点：可能会导致程序阻塞，效率比较低

什么是消息中间件

       面向消息的中间件(MessageOrlented MiddlewareMOM)较好的解决了以上问题。发送者将消息发送给消息服务器，消息服务器将消感存放在若千队列中，在合适的时候再将消息转发给接收者。

      这种模式下，发送和接收是异步的，发送者无需等待; 二者的生命周期未必相同: 发送消息的时候接收者不一定运行，接收消息的时候发送者也不一定运行;一对多通信: 对于一个消息可以有多个接收者。

JMS介绍

什么是JMS

       Java消息服务（Java Message Service），是一个Java平台中面向消息中间件的API，JMS的客户端之间可以通过JMS服务进行异步的消息传输。

角色划分

• 提供者： 实现JMS规范的消息中间件服务器 (存放消息容器)
• 客户端：发送或接收消息的应用程序
• 生产者/发布者： 创建并发送消息的客户端（向消息容器存放消息）
• 消费者/订阅者：接收并处理消息的客户端
• 消息：应用程序之间传递的数据内容
• 消息模式：在客户端之间传递消息的方式，JMS中定义了主题和队列两种模式，也称点对点与发布订阅模式。

点对点通讯

特性：

• 生产者发送一条消息到queue（队列）中，只有一个消费者能收到
• 消费者可以随时消费队列中的消息

发布订阅模式

特性：

• 发布者发送到topic（主题）的消息，只有订阅了topic的订阅者才会收到消息
• 主题中的消息被所有订阅者消费
• 消费者不能消费订阅之前就发送到主题中的消息

​​​​​​发布订阅与点对点方式的区别

• 点对点：只能保证一个消费者进行消费   一对一
• 发布订阅：只要集群的服务器订阅该主题，都会收到消息   一对多

消息中间件应用场景

• 异步处理
• 应用解耦
• 流量削锋

异步处理

     场景说明：用户注册后，需要发注册邮件和注册短信。

     传统的做法有两种 :串行的方式和并行方式。

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

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

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

       按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是50毫秒。注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，因此用户的响应时间可能是50毫秒。因此架构改变后，系统的吞吐量提高到每秒20 QPS。比串行提高了3倍，比并行提高了两倍。

应用解耦

      场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。

传统模式的缺点：假如库存系统无法访问，则订单减库存将失败，从而导致订单失败。
采用MQ方式，改造后的架构如下：

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

库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作。

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

流量削锋

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

       应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

      a、可以控制活动的人数

      b、可以缓解短时间内高流量压垮应用

1、用户的请求，服务器接收后，首先写入消息队列。假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面。

2、秒杀业务根据消息队列中的请求信息，再做后续处理。

3、秒杀如何实现核心Redis+MQ+服务保护机制（服务降级、隔离、熔断）+服务限流+图形验证+token。

MQ产品的分类

RabbitMQ

       是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了一个经纪人(Broker)构架，这意味着消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)或者数据持久化都有很好的支持。

Redis

       是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

	入队				出队
	128B	512B	1K	10K	128B	512B	1K	10K
Redis	16088	15961	17094	25	15955	20449	18098	9355
RabbitMQ	10627	9916	9370	2366	3219	3174	2982	1588

ZeroMQ

       号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中使用ZeroMQ作为数据流的传输。

ActiveMQ

       是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

Jafka/Kafka

       Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。