1.1. 什么是消息中间件MQ全称为Message Queue，消息队列是应用程序和应用程序之间的通信方法。 1.1.1 为什么使用MQ在项目中，可将一些无需即时返回且耗时的操作提取出来，进行异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高了系统的吞吐量。 - 在分布式服务中，当A系统需要远程调用B系统的API，一般是 同步处理。
 - 通过增加 中间件MQ，那么则可以将 A系统 调用 B系统的请求 改为 异步处理。
 - 分布式系统通信两种方式：直接远程调用 和 借助第三方 完成间接通信
1.1.2 MQ 的优势和劣势：优势： 劣势： 1.1.3 MQ 的优势：1、应用程序解耦合MQ相当于一个中介，生产方通过MQ与消费方交互，它将应用程序进行解耦合。 “如果有一个订单系统，这个订单系统要完成订单，需要请求各个系统，例如：库存、支付、物流等等。如果这个过程是一个同步遍历请求，那么只要其中一个系统挂掉了，那么这个请求就失败了。 ”  “如果在订单系统请求各个依赖系统之间增加 MQ，通过MQ进行解耦，那么就可以解决上述的问题。 ”  2、异步提速“如果订单系统同步请求各个依赖的系统，那么这个请求的时间就会很长！用户体验当然就很差了。 ”  “如果订单系统只要将请求发至MQ，而其他依赖系统自动从MQ中取消息进行处理，这样用户的响应时间就只有 请求系统 请求 MQ，以及 请求数据库 DB 的耗时，也就只有 25ms 了。 ”  3、削峰填谷如订单系统，在下单的时候就会往数据库写数据。但是数据库只能支撑每秒1000左右的并发写入，并发量再高就容易宕机。低峰期的时候并发也就100多个，但是在高峰期时候，并发量会突然激增到5000以上，这个时候数据库肯定卡死了。  消息被MQ保存起来了，然后系统就可以按照自己的消费能力来消费，比如每秒1000个数据，这样慢慢写入数据库，这样就不会卡死数据库了。  但是使用了MQ之后，限制消费消息的速度为1000，但是这样一来，高峰期产生的数据势必会被积压在MQ中，高峰就被“削”掉了。但是因为消息积压，在高峰期过后的一段时间内，消费消息的速度还是会维持在1000QPS，直到消费完积压的消息,这就叫做“填谷”  4. 小结1.1.4 MQ 的劣势： 系统可用性降低系统引入的外部依赖越多，系统稳定性越差。一旦 MQ 宕机，就会对业务造成影响。如何保证MQ的高可用？ 系统复杂度提高MQ 的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过 MQ 进行异步调用。如何保证消息没有被重复消费？怎么处理消息丢失情况？怎么保证消息传递的顺序性？ 一致性问题A 系统处理完业务，通过 MQ 给B、C、D三个系统发消息数据，如果 B 系统、C 系统处理成功，D 系统处理失败。如何保证消息数据处理的一致性？
1.1.5 使用 MQ 的条件既然 MQ 有优势也有劣势，那么使用 MQ 需要满足什么条件呢？ 生产者不需要从消费者处获得反馈。引入消息队列之前的直接调用，其接口的返回值应该为空，这才让明明下层的动作还没做，上层却当成动作做完了继续往后走，即所谓异步成为了可能。 确实是用了有效果。即解耦、提速、削峰这些方面的收益，超过加入MQ，管理MQ这些成本。
1.2. AMQP 和 JMSMQ是消息通信的模型；实现MQ的大致有两种主流方式：AMQP、JMS。 1.2.1. AMQPAMQP是一种协议，更准确的说是一种binary wire-level protocol（链接协议）。这是其和JMS的本质差别，AMQP不从API层进行限定，而是直接定义网络交换的数据格式。 1.2.2. JMSJMS即Java消息服务（JavaMessage Service）应用程序接口，是一个Java平台中关于面向消息中间件（MOM）的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。 1.2.3. AMQP 与 JMS 区别- JMS是定义了统一的接口，来对消息操作进行统一；AMQP是通过规定协议来统一数据交互的格式
- JMS限定了必须使用Java语言；AMQP只是协议，不规定实现方式，因此是跨语言的。
- JMS规定了两种消息模式；而AMQP的消息模式更加丰富
1.3. 消息队列产品市场上常见的消息队列有如下： - RabbitMQ：基于AMQP协议，erlang语言开发，稳定性好
- Kafka：类似MQ的产品；分布式消息系统，高吞吐量
常见的 MQ 产品对比：  1.4. RabbitMQ1.4.1 RabbitMQ 简介AMQP，即 Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。2006年，AMQP 规范发布。类比HTTP。 2007年，Rabbit 技术公司基于 AMQP 标准开发的 RabbitMQ 1.0 发布。RabbitMQ 采用 Erlang 语言开发。Erlang 语言由 Ericson 设计，专门为开发高并发和分布式系统的一种语言，在电信领域使用广泛。 RabbitMQ官方地址：http://www./ 1.4.2 RabbitMQ 基础架构RabbitMQ 基础架构如下图： 1.4.3 RabbitMQ 中的相关概念：- Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker
- Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多个vhost，每个用户在自己的 vhost 创建 exchange／queue 等
- Connection：publisher／consumer 和 broker 之间的 TCP 连接
- Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含了channel id 帮助客户端和message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大减少了操作系统建立 TCP connection 的开销
- Exchange：message 到达 broker 的第一站，根据分发规则，匹配查询表中的 routing key，分发消息到queue 中去。常用的类型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
- Queue：消息最终被送到这里等待 consumer 取走
- Binding：exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key。Binding 信息被保存到 exchange 中的查询表中，用于 message 的分发依据
1.4.4 RabbitMQ提供了6种模式：简单模式，work模式，Publish/Subscribe发布与订阅模式，Routing路由模式，Topics主题模式，RPC远程调用模式（远程调用，不太算MQ；暂不作介绍）； 官网对应模式介绍：https://www./getstarted.html
|
