RabbitMQ（一）【概述】
为什么需要使用消息中间件
具体地说，中间件屏蔽了底层操作系统的复杂性，是程序开发人员面对一个简单而统一的开发环境，减少了程序设计的复杂性，将注意力集中在自己的业务上，不必再为程序在不同系统软件上的移植而重复工作，从而大大减少了技术上的负担，中间件带给应用系统的，不i只是开发的简便、开发周期的缩短，也减少了系统的维护、运行和管理的工作量，还减少了计算机总体费用的投入
单体架构
存在的问题：
- 耦合度太高
- 运维成本过高
- 不宜维护
- 服务器的成本高
- 以及升级架构的复杂度也会增大
分布式架构
存在问题：
- 学习成本过高，技术栈过多
- 运维成本和服务器成本增高
- 人员的成本增高
- 项目的负载度上升
- 面临的错误和容错性也会成倍增加
- 占用的服务器端口和通讯的选择的成本高
- 安全性的考虑和因素逼迫可能选择 RMI/MQ 相关的服务器通讯
好处：
- 服务系统的独立，占用的服务器资源减少和占用的硬件成本减少
- 系统的独立维护和部署，耦合度降低，可插拔性
- 系统的框架和技术栈的选择可以变得灵活
- 弹性的部署，不会造成平台因为部署造成的瘫痪和停服的状态
常见的消息中间件
ActiveMQ、RabbitMQ、Kafka、RocketMQ等
消息中间件的使用
- 利用可靠的消息传递机制进行系统和系统直接的通讯
- 通过提供消息传递和消息的排队机制，它可以在分布式系统环境下扩展进程间的通讯
消息中间件的本质及设计
它是一种接收数据，接收请求、存储数据、发送数据等功能的技术服务
消息中间件的核心组成部分
- 消息的协议
- 消息的持久化机制
- 消息的分发策略
- 消息的高可用、高可靠
- 消息的容错机制
一、消息队列概述
1.1 消息队列协议
什么是协议
所谓协议是指：
- 计算机底层操作系统和应用程序通讯时共同遵守的一组约定，只有遵循共同的约定和规范，系统和底层操作系统之间才能相互交流
- 和一般的网络应用程序的不同，它主要负责数据的接收和传递，所以性能比较的高
- 协议对数据格式和计算机之间交换数据都必须严格遵守规范
网络协议的三要素
- 语法：语法使用户数据与控制信息的结构与格式，以及数据出现的顺序
- 语义：语义是解释控制信息每个部分的意义。它规定了需要发出任何控制信息，以及完成的动作与做出什么样的响应
- 时序：时序是对事件发生顺序的详细说明
1. 语法: http 规定了请求报文和响应报文的格式
2. 语义: 客户端主动发起请求称之为请求
3. 时序: 一个请求对应一个响应 (一定现有请求再有响应,这个是时序)
常见面试题：为什么消息中间件不直接使用 http 协议?
- 因为 http 请求报文头和响应报文头是比较复杂的，包含了cookie、数据的加密解密、状态码、响应码等附加的功能，但是对于一个消息而言，并不需要这么复杂，也灭有这个必要性，它其实就是负责数据传递、存储、分发就行，一定要追求的是高性能。尽量简洁，快速
- 大部分情况下 http 都是短链接，在实际的几乎过程中，一个请求到响应很可能会中断，中断以后就不会进行持久化，会造成请求的丢失。这样就不利于消息中间件的业务场景，因为消息中间件可能是一个长期的获取消息的过程，出现问题和故障要对数据或消息进行持久化等，目的就是为了保证消息和数据的高可靠和稳健的运行
AMQP 协议
AMQP：（全程 Advanced Message Queuing Protocol）是高级消息队列协议。由于摩根大通集团联合其他公司共同设计。是一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品、不同的开发语言等条件的限制
特性
- 分布式事务支持
- 消息的持久化支持
- 高性能和高可靠的消息处理优势
MQTT 协议
MQTT 协议（Message Queuing Telemetry Transport）消息队列是IBM开放的一个即时通讯协议，物联网系统架构中的重要组成部分
特点
- 轻量
- 结构简单
- 传输快，不支持事务
- 没有持久化技术
应用场景
- 适用于计算能力有限
- 低带宽
- 网络不稳定的场景
OpenMessage 协议
是最近几年由阿里、雅虎和滴滴出行、Steamalio等公司共同参与与创立的分布式消息中间件、流处理等领域的应用开发标准
特点
- 结构简单
- 解析速度快
- 支持事务和持久化设计
Kafka 协议
Kafka 协议是基于 TCP/IP 的二进制协议，消息内部是通过长度来分割，由一些基本数据类型组成
特点
- 结构简单
- 解析速度快
- 无事务支持
- 有持久化设计
1.2消息队列持久化
持久化
简单来说就是将数据存入磁盘，而不是存在内存中随服务重启断开而消失，使数据能够永久保存
常用的持久化方式
| ActiveMQ | RabbitMQ | Kafka | RocketMQ | |
|---|---|---|---|---|
| 文件存储 | 支持 | 支持 | 支持 | 支持 |
| 数据库 | 支持 | / | / | / |
1.3 消息的分发策略
MQ 消息队列有如下几个角色
- 生产者
- 存储消息
- 消费者
一般获取数据的方式无外乎"推"（push）或者"拉"（pull）两者方式，典型的就是 git 就有推拉机制，我们发送的 http 请求就是一种典型的拉取数据库数据返回的过程。而消息队列 MQ 是一种推送的过程，这些推机制会适用到很多的业务场景，也有很多对应推机制策略
消息分发策略的机制对比
| ActiveMQ | RabbitMQ | Kafka | RocketMQ | |
|---|---|---|---|---|
| 发布订阅 | 支持 | 支持 | 支持 | 支持 |
| 轮询分发 | 支持 | 支持 | 支持 | / |
| 公平分发 | / | 支持 | 支持 | / |
| 重发 | 支持 | 支持 | / | 支持 |
| 消息拉取 | / | 支持 | 支持 | 支持 |
1.4 消息队列高可用和高可靠
什么是高可用机制
高可用：是指产品在规定的条件和规定的时刻或时间内处于可执行规定功能状态的能力
当业务量增加时，请求也过大，一台消息中间件服务器会触及硬件（CPU、内存、磁盘）的极限，一台消息服务器已经无法满足业务的需求，所以消息中间件必须支持集群部署，来达到高可用的目的
集群模式1 - Master-Slave 主从共享数据的部署方式
解析：生产者将消费者发送到 Master 节点，所有的都连接这个消息队列共享这块数据区域，Master 节点负责写入，一旦 Master 挂掉，slave 节点继续服务。从而形成高可用
集群模式2 - Master-Slave 主从同步部署方式
解析：这种模式写入消息同样在 Master 主节点上，但是主节点会同步数据到 slave 节点形成副本，和 zookeeper 或者 redis 总从机制很类同。这样可以达到负载均衡的效果，如果消费者有多个这样就可以去不同的节点进行消费，以为消息的拷贝和同步暂用很大的带宽和网络资源
集群模式3- Master-Slave 多主集群同步部署方式
解析：和上面的区别不是很大，但是它的写入可以是任意节点去写入
集群模式4- Master-Slave 多主集群转发部署模式
解析：如果你插入的数据是 broker-1中，元数据信息会存储数据的相关描述和记录存放的位置（队列）
它会对描述信息，也就是算数据信息进行同步，如果消费者在broker-2进行消费，发现自己没有对应的消息，可以从对应的元数据信息中去查询，然后返回对应的消息信息，场景：比如买火车票或者黄牛买演唱会门票，假如第一个黄牛有顾客说要买演唱会门票，如果该黄牛没有则他回去找另外的黄牛询问，如果有就返回
集群模式5 Master-Slave与 Broker-Cluster组合的方案
解析：实现多主多从的热备机制来完成消息的高可用以及数据的热备机制，在生产规模达到一定的阶段的时候，这种使用的频率比较高
小结：要么消息共享，要么消息同步，要么元数据共享
高可靠机制
高可靠机制：系统可以无故障低持续运行，比如一个系统突然崩溃，报错，异常等等并不能影响线上业务的正常运行，出错的几率极低，就称之为：高可靠
在高并发的业务场景中，如果不能保证系统的高可靠，那造成的隐患和损失是非常严重的
保证消息中间件的可靠性可以从以下两方面考虑
- 消息的传输：通过协议来保证系统间数据解析的正确性
- 消息的存储可靠：通过持久化来保证消息的可靠性