1.中间件

1.1中间件基础

• 平台+通信，通过遵循协议和规范和底层操作系统硬件打交道。
• 特性：跨平台

举例：
1，RMI（Remote Method Invocations, 远程调用）
2，Load Balancing(负载均衡，将访问负荷分散到各个服务器中)
3，Transparent Fail-over(透明的故障切换)
4，Clustering(集群,用多个小的服务器代替大型机）
5，Back-end-Integration(后端集成，用现有的、新开发的系统如何去集成遗留的系统)
6，Transaction事务（全局/局部）全局事务（分布式事务）局部事务（在同一数据库联接内的事务）
7，Dynamic Redeployment(动态重新部署,在不停止原系统的情况下，部署新的系统）
8，System Management(系统管理)
9，Threading(多线程处理)
10，Message-oriented Middleware面向消息的中间件（异步的调用编程）
11，Component Life Cycle(组件的生命周期管理)
12，Resource pooling（资源池）
13，Security（安全）
14，Caching（缓存）

特点：

（1）满足大量应用的需要
（2）运行于多种硬件和OS平台
（3）支持分布计算，提供跨网络、硬件和OS平台的透明性的应用或服务的交互
（4）支持标准的协议
（5）支持标准的接口

1.2中间件技术

• 分布式消息中间件

  • 1.ActiveMQ（以往使用，较复杂，java开发的）
  • 2.RabbitMQ（现在流行，和spring一家公司，功能完善，性能广泛）
  • 3.Kafka（高性能，基于TCP二进制开发的，最贴近底层，广泛用于大数据中，支持持久化和分发机制，但不支持事务）
  • 4.RocketMQ（很少人使用，国产消息队列，拖过给apach基金）
  • 5.场景
    • 消息中间件监控数据
    • 异步数据传输场景
    • 削峰填谷场景、
    • 任务调度场景
    • 海量数据同步场景
    • 分布式事务场景
    • 日记管理场景
    • 大数据分析场景
  • 6.协议设计（在TCP/IP协议之上拓展协议来规范）
    • AMQP
    • MQTT
    • 持久化设计
    • kafka协议
    • 消息分布设计
    • 高可用设计
    • 可靠性设计
    • 容错设计

• 负载均衡中间件

  • 1.Nginx（Tomcat负载均衡，部署前后端分离项目中的前端内容）
  • 2.LVS负载均衡软件（对Nginx做集群预防故障）
  • 3.KeepAilve（维持Nginx高可用）
  • 4.CDN（提升加速）

• 缓存中间件

  • Memcache（小项目，代码级别，会占用JVM内存，类似java中的map）
  • Redis（分布式，高性能）

• 数据库中间件（mysql具有持久化，但不具备高可用"及没有集群"）

  • Mycat（给数据库提供高可用）
  • Shardingjdbc（给数据库提供高可用）

• 案例

  • 异步数据保存（达到削峰的目的，同串行变并行）

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

  • 订单数据的消息分发
  • 分布式事务
  • 消息的容错
  • 分布式锁
  • 分布式会话
  • 分库分表

1.3架构

通俗一点：就是一个请求由服务器端的多个服务（服务或者系统）协同处理完成

​ 和单体架构不同的是，单体架构是一个请求发起jvm调度线程（确切的是tomcat线程池）分配线程Thread来处理请求直到释放。

​ 而分布式是系统是：一个请求是由多个系统共同来协同完成，jvm和环境都可能是独立。

​ 如果生活中的比喻的话，单体架构就想建设一个小房子很快就能够搞定，如果你要建设一个鸟巢或者大型的建筑，你就必须是各个环节的协同和分布，这样目的也是项目发展到后期的时候要去部署和思考的问题。

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

1.4本质设计

流程

它是一种接受数据，接受请求、存储数据、发送数据等功能的技术服务。

MQ消息队列：负责数据的传接受，存储和传递，所以性能要过于普通服务和技术。

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

消息中间件组成部分

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

小结

其实不论选择单体架构还是分布式架构都是项目开发的一个阶段，在什么阶段选择适合的架构方式，而不能盲目追求，最后造成的后果和问题都需要自己买单。但是作为一个开发人员学习和探讨新的技术是我们每个程序开发者都应该去保持和思考的问题。当我们没办法去改变社会和世界的时候，我们为了生活和生存那就必须要迎合企业和市场的需求，发挥你的价值和所学的才能，创造价值和实现自我。

1.5消息协议

协议流程

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

协议三要素

1.语法。语法是用户数据与控制信息的结构与格式,以及数据出现的顺序。
2.语义。语义是解释控制信息每个部分的意义。它规定了需要发出何种控制信息,以及完成的动作与做出什么样的响应。
3.时序。时序是对事件发生顺序的详细说明。
ing" onclick="mdcp.signin(event)" style="position: unset;">1：语法：http规定了请求报文和响应报文的格式。
2：语义：客户端主动发起请求称之为请求。（这是一种定义，同时你发起的是post/get请求）
3：时序：一个请求对应一个响应。（一定先有请求在有响应，这个是时序）
1
2
3

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

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

1.AMQP协议

AMQP：(全称：Advanced Message Queuing Protocol) 是高级消息队列协议。由摩根大通集团联合其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。Erlang中的实现有RabbitMQ等。
特性：
1：分布式事务支持。
2：消息的持久化支持。
3：高性能和高可靠的消息处理优势。

2.MQTT协议

MQTT协议：（Message Queueing Telemetry Transport）消息队列是IBM开放的一个即时通讯协议，物联网系统架构中的重要组成部分。
特点：
1：轻量
2：结构简单
3：传输快，不支持事务
4：没有持久化设计。
应用场景：
1：适用于计算能力有限
2：低带宽
3：网络不稳定的场景。

3.Kafka协议

Kafka协议：是基于TCP/IP的二进制协议。消息内部是通过长度来分割，由一些基本数据类型组成。
特点：
1：结构简单
2：解析速度快
3：无事务支持
4：有持久化设计

小结

协议：是在tcp/ip协议基础之上构建的一种约定成俗的规范和机制、它的主要目的可以让客户端（应用程序 java，go）进行沟通和通讯。并且这种协议下规范必须具有持久性，高可用，高可靠的性能。

1.6消息持久化

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

1.7消息分发策略

01、消息的分发策略

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

02、场景分析一

比如我在APP上下了一个订单，我们的系统和服务很多，我们如何得知这个消息被那个系统或者那些服务或者系统进行消费，那这个时候就需要一个分发的策略。这就需要消费策略。或者称之为消费的方法论。

场景分析二

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

04、消息分发策略的机制和对比

轮询分发：不论服务器能力高低，都平均分配

公平分发：能者多劳

重发：如果一个服务器出现问题，将把此条消息发给其他服务器，避免消息丢失

消息拉取：主动的过程，1.消息拉去客户端请求封装，2.消息服务器查找并返回消息，3.消息拉去客户端处理返回消息

1.8高可用和高可靠

00、集群

1：要么消息共享，
2：要么消息同步
3：要么元数据共享

01、什么是高可用机制

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

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

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

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

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

04、集群模式3 - 多主集群同步部署模式

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

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9ku4qf3o-1638262228601)(E:\亚信\亚信每周整理\week5\RabbitMQ\photo\09集群4.png)]

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

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

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

这么集群模式，具体在后续的课程中会进行一个分析和讲解。他们的最终目的都是为保证：消息服务器不会挂掉，出现了故障依然可以抱着消息服务继续使用。

07、什么是高可靠机制

所谓高可用是指：是指系统可以无故障低持续运行，比如一个系统突然崩溃，报错，异常等等并不影响线上业务的正常运行，出错的几率极低，就称之为：高可靠。
在高并发的业务场景中，如果不能保证系统的高可靠，那造成的隐患和损失是非常严重的。
如何保证中间件消息的可靠性呢？可以从两个方面考虑：
1：消息的传输：通过协议来保证系统间数据解析的正确性。
2：消息的存储可靠：通过持久化来保证消息的可靠性。