分布式架构中，一个系统由若干个子系统构成，因此系统与系统之间的通讯就显得很重要了

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

从上图中我们可以看到，消息中间件最根本的功能就是通讯，实现通信就需要遵守通信协议。通信协议有很多，比如TCP/IP协议、HTTP协议、AMQP、OpenMessage协议等，我们应该选择哪种呢？

其次，消息中间件需要具备高可用（持久化、集群），比如消息中间件刚收到消息后就宕机了，等待服务器恢复正常后，消息中间件是否还能够进行正常的消息分发呢？

然后，消息中间件还需要能给将消息分发给消费者，这就涉及到了分发策略的选择，是发布订阅模式？还是公平模式？还是轮询模式？

并且，消息中间件需要做到跨平台，不管我们的业务模块是用什么语言编写的，消息中间件都要能够支持

消息中间件所应该具备的能力

  • 跨系统数据传递
  • 高并发情况的流量削峰
  • 数据的分发和异步处理
  • 大数据分析和传递
  • 分布式事务

比如我们有一个数据要进行迁移或者请求并发过多的时候，假设我们现在有10w的并发请求下订单，我们可以在这些订单入库之前，将这批订单请求堆积到消息队列中，让它稳健可靠的入库和执行

常见的消息中间件

  • ActiveMQ
  • RabbitMQ
  • Kafka
  • RocketMQ

消息中间件的本质

接收数据、存储数据、发送数据

消息中间件的组成部分

  • 消息的协议（TCP/IP、UDP、AMQP、MQTT、Kafka协议、OpenMessage协议等）

    所谓的协议是指：

    计算机OS和应用程序通讯时所共同遵守的约定，只有遵循共同的约定和规范，应用和底层操作系统之间才能相互交流

    网络协议的要素

    1. 语法：数据的结构与格式，以及数据出现的顺序
    2. 语义：解释数据中每个部分的含义，它规定了我们需要发出怎样的数据，以及发送完成后的动作和返回怎样的响应
    3. 时序：对事件发生顺序的详细说明

    以http协议为例：

    语法：http规定了请求报文和响应报文的格式

    语义：客户端主动发起请求才称之为请求

    时序：一个请求对应一个响应，先有请求再有响应

    那为什么消息中间件的协议不直接使用http协议呢？

    1. 因为http请求报文头和响应报文头是比较复杂的，包含cookie、响应码、状态码等附加功能，但是这些东西对于消息中间件来说完全没用，它只需要负责数据的接收、存储、分发，它追求的是高性能、高可用，因此消息中间件所使用的协议一定要简洁、高效

    2. 大部分情况下http请求都是短链接，在实际交互过程中，客户端发起请求到响应结果返回，这个过程很可能会中断，中断以后不会进行持久化，就会造成消息的丢失，这对于消息中间件来说是不可接受的。

      因为消息中间件所面临的场景是接收、存储、发送消息，这是一个长期的过程，中间出现问题的话，消息中间件需要对消息进行持久化等操作，保证消息的可靠

    3. ps：短链接就是用户发起请求，此时服务器故障，则请求直接丢失，并不会维持客户端和服务端的链接；长链接就是当服务器出现故障，重启之后依然可以进行数据的传递，从而维持长久的关系

  • 消息的持久化机制

    ActiveMQ RabbitMQ Kafka RocketMQ
    文件存储 √ √ √ √
    数据库 √ - - -

  • 消息的分发策略

  • 高可用、扩展性

  • 消息的容错机制