消息中间件介绍

1、消息中间件概述

为什么需要使用消息中间件？

• 具体地说，中间件屏蔽了底层操作系统的复杂性，使程序开发人员面对一个简单而统一的开发环境，减少程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担。中间件带给应用系统的，不只是开发的简便、开发周期的缩短，也减少了系统的维护、运行和管理的工作量，还减少了计算机总体费用的投入。

• 在实际的项目中，大部分的企业项目开发中，在早期都采用的是单体的架构模式，如下图：

  
  • 在企业开发的中，大部分的初期架构都采用的是单体架构的模式进行架构，而这种架构的典型的特点：就是把所有的业务和模块，源代码，静态资源文件等都放在一个一工程中，如果其中的一个模块升级或者迭代发生一个很小变动都会重新编译和重新部署项目。这种的架构存在的问题就是：
    • 耦合度太高。
    • 运维的成本过高。
    • 不易维护。
    • 服务器的成本高。
    • 升级架构的复杂度也会增大。

• 于是会使用分布式架构，即一个请求由服务器端的多个服务（服务或者系统）协同处理完成，如图：

  
  • 这样带来的好处是：
    • 服务系统的独立，占用的服务器资源减少和占用的硬件成本减少，确切的说是：可以合理的分配服务资源，不造成服务器资源的浪费。
    • 系统的独立维护和部署，耦合度降低，可插拔性。
    • 系统的架构和技术栈的选择可以变的灵活（而不是单纯的选择java）
    • 弹性的部署，不会造成平台因部署造成的瘫痪和停服的状态。

• 而基于消息中间件的分布式架构如图：

  
  • 从上图中可以看出来，消息中间件是：
    • 利用可靠的消息传递机制进行系统和系统直接的通讯。
    • 通过提供消息传递和消息的排队机制，它可以在分布式系统环境下扩展进程间的通讯。

消息中间件的应用场景？

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

2、消息队列协议

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

  

• 而消息中间件采用的并不是http协议，而常见的消息中间件协议有：OpenWire、AMQP、MQTT、Kafka，OpenMessage协议。不使用http协议的原因如下：

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

• RabbitMQ是基于AMQP协议的，其是一种高级消息队列协议。由摩根大通集团联合其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。特性如下：

  • 分布式事务支持。

  • 消息的持久化支持。

  • 高性能和高可靠的消息处理优势。

    • AMQP生产者流转过程图：

      

    • AMQP消费者流转过程图：

      

3、消息队列持久化

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

  

4、消息分发策略

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

  • 生产者。
  • 存储消息。
  • 消费者。

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

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

5、消息队列的高可用和高可靠

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

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

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

  • 集群模式2：Master-slave主从同步部署方式。

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

  • 集群模式3：多主集群同步部署模式。

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

  • 集群模式4：多主集群转发部署模式。

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

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

    
    • 实现多主多从的热备机制来完成消息的高可用以及数据的热备机制，在生产规模达到一定的阶段的时候，这种使用的频率比较高。

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

  • 在高并发的业务场景中，如果不能保证系统的高可靠，那造成的隐患和损失是非常严重的。而保证中间件消息的可靠性呢可以从两个方面考虑：
    • 消息的传输：通过协议来保证系统间数据解析的正确性。
    • 消息的存储可靠：通过持久化来保证消息的可靠性。