中间件

1. 什么是中间件

我国企业从20世纪80年代开始就逐渐进行信息化建设，由于方法和体系的不成熟，以及企业业务的市场需求的不断变化，一个企业可能同时运行着多个不同的业务系统，这些系统可能基于不同的操作系统、不同的数据库、异构的网络环境。现在的问题是，如何把这些信息系统结合成一个有机地协同工作的整体，真正实现企业跨平台、分布式应用。中间件便是解决之道，它用自己的复杂换取了企业应用的简单。

中间件（Middleware）是处于操作系统和应用程序之间的软件，也有人认为它应该属于操作系统中的一部分。人们在使用中间件时，往往是一组中间件集成在一起，构成一个平台（包括开发平台和运行平台），但在这组中间件中必须要有一个通信中间件，即中间件+平台+通信，这个定义也限定了只有用于分布式系统中才能称为中间件，同时还可以把它与支撑软件和使用软件区分开来。

2. 中间件技术及架构的概述

1. MQ相关概念

1.1 什么是MQ？

MQ(message queue)，从字面意思上看，本质是个队列，FIFO先入先出，只不过队列中存放的内容是message而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游“逻辑解耦+物理解耦”的消息通信服务。使用了MQ之后，消息发送上游只需要依赖MQ，不用依赖其他服务。

1.2 为什么要使用MQ？

2. 基于消息中间件的分布式系统的架构

2.1 基于消息中间件的分布式系统的架构

从上图中可以看出来，消息中间件是:

1. 利用可靠的消息传递机制进行系统和系统直接的通讯
2. 通过提供消息传递和消息的排队机制，它可以在分布式系统环境下扩展进程间的通讯。

2.2 消息中间件的应用场景

1. 跨系统数据传递
2. 高并发的流量削峰
3. 数据的分发和异步处理（就是并发处理）
4. 大数据分析与传递
5. 分布式事务
   比如你有一个数据要进行迁移或者请求并发过多的时候，比如你有10W的并发请求下订单，我们可以在这些订单入库之前，我们可以把订单请求堆积到消息队列中，让它稳健可靠的入库和执行。

上面第三点：

2.3 常见的消息中间件

RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMQ等

2.4 消息中间件的本质及设计

它是一种接受数据，接受请求、存储数据、发送数据等功能的技术服务。
MQ消息队列：负责数据的传接受，存储和传递，所以性能要过于普通服务和技术。

谁来生产消息，存储消息和消费消息呢?

2.5 消息中间件的核心组成部分

1. 消息的协议
2. 消息的持久化机制
3. 消息的分发策略
4. 消息的高可用，高可靠
5. 消息的容错机制

3. 消息队列协议

3.1 什么是协议？

我们知道消息中间件负责数据的传递，存储，和分发消费三个部分，数据的存储和分发的过程中肯定要遵循某种约定成俗的规范，你是采用底层的TCP/IP，UDP协议还是其他的自己取构建等，而这些约定成俗的规范就称之为:协议。

3.2 网络协议的三要素

1. 语法：语法是用户数据与控制信息的结构与格式以及数据出现的顺序。
2. 语义:语义是解释控制信息每个部分的意义。它规定了需要发出何种控制信息以及完成的动作与做出什么样的响应。
3. 时序：时序是对事件发生顺序的详细说明。

比如MQ发送一个信息，是以什么数据格式发送到队列中，然后每个部分的含义是什么，发送完毕以后的执行的动作,以及消费者消费消息的动作，消费完毕的响应结果和反馈是什么，然后按照对应的执行顺序进行处理。如果你还是不理解;大家每天都在接触的http请求协议:

• 语法: http规定了请求报文和响应报文的格式。
• 语义：客户端主动发起请求称之为请求。(这是一种定义，同时你发起的是post/get请求)
• 时序：一个请求对应一个响应。(一定是先有请求再有响应，这个是时序)

而消息中间件采用的并不是http协议，而常见的消息中间件协议有:OpenWire、AMQP、MQTT、Kafka，OpenMessage协议。

面试题：为什么消息中间件不直接使用 http协议？

1. 因为 http请求报文头和响应报文头是比较复杂的，包含了Cookie，数据的加密解密，状态码，响应码等附加的功能，但是对于一个消息而言，我们并不需要这么复杂，也没有这个必要性，它其实就是负责数据传递，存储，分发就行，一定要追求的是高性能。尽量简洁，快速。
2. 大部分情况下 http大部分都是短链接，在实际的交互过程中，一个请求到响应都很有可能会中断，中断以后就不会执行持久化，就会造成请求的丢失。这样就不利于消息中间件的业务场景，因为消息中间件可能是一个长期的获取信息的过程，出现问题和故障要对数据或消息执行持久化等，目的是为了保证消息和数据的高可靠和稳健的运行。

3.3 AMQP协议

AMQP:(全称: Advanced Message Queuing Protocol)是高级消息队列协议。由摩根大通集团联合其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。

特性:

1. 分布式事务支持。
2. 消息的持久化支持。
3. 性能和高可靠的消息处理优势。
   

3.4 MQTT协议

MQTT协议（Message Queueing Telemetry Transport）消息队列是 IBM开放的及时通讯协议，物联网系统架构中的重要组成部分。

特点：

1. 轻量
2. 结构简单
3. 传输快，不支持事务
4. 没有持久化设计

应用场景：

1. 适用于计算能力有限
2. 低带宽
3. 网络不稳定的场景

3.5 OpenMessage协议

是近几年由阿里、雅虎和滴滴出行、Stremalio等公司共同参与创立的分布式信息中间件、流处理等领域的应用开发标准。

特点：

1. 结构简单
2. 解析速度快
3. 支持事务和持久化设计

3.6 Kafka协议

Kafka协议是基于 TCP/IP的二进制协议。消息内部是 通过长度来分割，由一些基本数据类型组成。

特点：

1. 结构简单
2. 解析速度快
3. 无事务支持
4. 有持久化设计

4. 消息队列持久化

4.1 持久化

简单来说就是将数据存入磁盘，而不是存在内存中随服务器重启断开而消失，使数据能够永久保存。

4.2 常见消息队列对持久化的支持

5. 消息的分发策略

5.1 消息的分发策略

MQ消息队列有如下几个角色:

1. 生产者
2. 存储消息
3. 消费者

那么生产者生成消息以后，MQ进行存储，消费者是如何获取消息的呢?一般获取数据的方式无外乎推(push）或者拉(pull）)两种方式，典型的git就有推拉机制，我们发送的http请求就是一种典型的拉取数据库数据返回的过程。而消息队列MQ是一种推送的过程，而这些推机制会适用到很多的业务场景也有很多对应推机制策略。

5.2 场景分析

在发送消息的过程中可能会出现异常，或者网络的抖动，故障等等因为造成消息的无法消费，比如用户在下订单，消费MQ接受，订单系统出现故障，导致用户支付失败，那么这个时候就需要消息中间件就必须支持消息重试机制策略。也就是支持:出现问题和故障的情况下，消息不丢失还可以进行重发。

5.3 常见消息队列的消息分发策略的机制和对比

6. 消息队列高可用和高可靠

6.1 什么是高可用机制

所谓高可用:是指产品在规定的条件和规定的时刻或时间内处于可执行规定功能状态的能力。当业务量增加时，请求也过大，一台消息中间件服务器的会触及硬件（CPU,内存，磁盘)的极限，一台消息服务器你已经无法满足业务的需求，所以消息中间件必须支持集群部署。来达到高可用的目的。

6.2 集群模式1 Master-slave主从共享数据的部署方式

解说:生产者讲消费发送到Master节点，所有的都连接这个消息队列共享这块数据区域，Master节点负责写入，一旦Master挂掉,slave节点继续服务。从而形成高可用,

6.3 集群模式2-Master- slave主从同步部署方式

解释:这种模式写入消息同样在Master主节点上，但是主节点会同步数据到slave节点形成副本，和zookeeper或者redis主从机制很类同。这样可以达到负载均衡的效果，如果消费者有多个这样就可以去不同的节点就行消费，但是消息的拷贝和同步会暂用很大的带宽和网络资源。在后续的RabbitMq中会有使用。

6.4 集群模式2-多主集群同步部署方式

解释：和上面的区别不是特别的大，但是它的写入可以往任意节点去写入

6.5 集群模式4-多主集群转发部署模式

解释:如果你插入的数据是broker-1中，元数据信息会存储数据的相关描述和记录存放的位置（队列)。
它会对描述信息也就是元数据信息就行同步，如果消费者在broker-2中进行消费，发现自己几点没有对应的消息，可以从对应的元数据信息中去查询，然后返回对应的消息信息，场景:比如买火车票或者黄牛买演唱会门票，比如第一个黄牛有顾客说要买的演唱会门票，但是没有但是他会去联系其他的黄牛询问，如果有就返回。

6.6 集群模式5 Master-slave与Breoker-cluster组合的方案

6.7 什么是高可靠？

所谓高可靠是指:是指系统可以无故障地持续运行，比如一个系统突然崩溃，报错，异常等等并不影响线上业务的正常运行，出错的几率极低，就称之为:高可靠。

在高并发的业务场景中，如果不能保证系统的高可靠，那造成的隐患和损失是非常严重的。如何保证中间件消息的可靠性呢?可以从两个方面考虑:

1. 消息的传输:通过协议来保证系统间数据解析的正确性。
2. 消息的存储可靠:通过持久化来保证消息的可靠性。