中间件技术与分布式架构
分布式中间件
消息中间件
类型：ActiveMQ、RabbitMQ、Kafka、RocketMQ
场景：消息中间件监控数据 、异步数据传输场景、流量削峰、任务调度、海量数据同步、分布式事务、日志管理、大数据分析与传递、数据的分发与异步处理
协议与设计：AMQP、MQTT、持久化设计、Kafka协议、消息分发设计、高可用设计、可靠性设计、容错设计。
本质：是一种接收数据、存储数据、发送数据等功能的服务。
核心组成部分：协议、持久化机制、分发策略、高可用、高可靠、容错机制
消息中间件是什么：
利用可靠的消息传递机制进行系统和系统之间的直接通信。
通过提供消息传递和消息排队机制，可以在分布式系统环境下扩展进程间的通信。
负载均衡中间件
Nginx、LVS 负载均衡软件、KeepAlive、CDN
数据库中间件
Mycat、ShardingJDBC
缓存中间件
MemCache、Redis
案例分析：
异步数据保存、订单数据消息分发、分布式事务、消息容错、分布式锁、分布式会话、分库分表
消息队列协议
网络协议三要素
- 语法：用户数据与控制信息的结构格式及数据出现的顺序。
- 语义：解释控制信息每个部分的意义。规定了需要发出何种控制信息以及完成的动作，做出啥样的响应。
- 时序：对事件发生顺序的详细说明。
http协议：
语法：http规定请求报文和响应报文的格式
语义：客户端主动发起请求称为请求。
时序：一个请求对应一个响应。先有请求后有响应。
消息中间件采用的并不是http协议，常见的消息中间件协议有：OpenWire、AMQP、MQTT、Kafka、OpenMessage
为什么消息中间件不直接采用http协议？
扫描二维码关注公众号，回复： 14725793 查看本文章
- 由于http请求头和响应头比较复杂。包含了cookie、数据加密解密、状态码、响应码等附加功能，但是对于一个消息而言，不需要这么复杂。只需要负责数据的传递、存储、分发即可，追求的是高性能、简洁
- 大部分情况下http都是短链接，在实际交互过程中，一个请求到响应可能会中断，中断以后就不会进行持久化，会造成数据丢失。不利于消息中间件的业务场景。因为消息中间件可能是一个长期获取消息的过程，出现问题和故障要对数据或消息进行持久化，目的是为了保证消息和数据的高可靠和稳健的运行。
AMQP协议（Advance Message Queuing Protocol）
一个提供同意消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件产品不同，语言不同的限制。Erlang中的实现有RabbitMQ。
特性：分布式事务、消息的持久化、高性能与高可靠的消息处理优势
MQTT协议（Message Queuing Telemetry Transport）
物联网系统架构中的重要组成部分。
特点：轻量、结构简单、传输快、不支持事务、没有持久化设计
应用场景：适用于计算能力有限、低带宽、网络不稳定的场景。
RabbitMQ默认关闭。
OpenMessage
分布式中间件、流处理的呢个领域的应用开发标准。
特点：结构简单、解析速度快、支持事务和持久化设计。
Kafka协议
基于TCP/IP的二进制协议。消息内部通过长度来分割，由一些基本数据类型组成。
特点：结构简单、解析速度快、无事务支持、有持久化设计
消息队列的持久化
持久化：简单来说就是将数据存入硬盘，而不是存储在服务器内存中，使数据能够永久保存。
消息的分发策略
消息队列的角色：生产者、存储消息、消费者
生产者生成消息后，MQ进行存储，消费者如何获取消息？
- 推送push：
- 拉取pull：
高可用、高可靠
当业务量增加时，请求也过大，一台消息中间件服务器会触及CPU、内存、磁盘的极限，一台消息服务器无法满足业务需求，所以消息中间件必须支持集群来达到高可用目的。
集群模式
1. 主从共享数据的部署方式
生产者将消息发送到master节点，所有的都链接这个消息队列共享这块数据区域，master负责写入，一旦master挂掉，slave节点继续服务，从而形成高可用。
2. 主从同步数据的部署方式
写入消息同样在master节点，但是主节点会同步数据到slave节点形成副本，和zookeeper或者redis主从机制类似。这样可以达到负载均衡的效果，如果消费者有多个，这样就可以取不同的节点进行消费，因为消息的拷贝和同步会占用很大的带宽和网络资源。
3. 多主集群同步部署模式
与前面的区别不是很大，但是可以从任意的节点进行写入。
4. 主从转发
如果插入的数据是broker1中，元数据信息会存储数据的相关描述和记录存放位置(队列)。会对描述信息也就是元数据信息进行同步，如果消费者在broker2进行消费，发现自己没有对应的消息，额可以从对应的元数据信息中取查询，然后返回对应的消息信息。eg：买黄牛票，第一个黄牛手里没票会找同行调货。
Master-Slave和Broker-Cluster组合方案
实现多主多从的热备份机制来完成消息的高可用，及数据的热备份，在生产达到一定的阶级规模才会采用。
核心
其最终目的是为了保证消息服务器不挂掉，出现故障依然可以使用。
总结：要么消息共享、要么消息同步、要么元数据共享。
什么是高可靠机制
所谓的靠可用是指的系统无故障底持续运行，比如一个系统突然崩溃、报错、异常但是不影响业务运行，出错概率低，成为高可靠。
如何保证消息中间件的高可靠：
- 消息的传输可靠：通过协议来保证系统间数据解析的正确性。
- 消息的存储可靠：通过持久化来保证消息的可靠性。
入门与安装
Windows版本安装步骤参考：
SpringBoot学习笔记（九）消息，JMS、AMQP、RabbitMQ
https://blog.csdn.net/qq_40366738/article/details/108799244
授权账号密码
- 新增用户
rabbitmqctl add_user admin admin123 - 设置用户分配操作权限
rabbitmqctl set_ser_tags admin administrator - 为用户添加资源权限
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*"
用户级别
- administrator：可以登录控制台、查看所有信息、对rabbitmq进行管理
- monitoring：监控者，登录控制台、查看所有信息
- policymaker：策略制定者，登录控制台、制定策略
- management：普通管理员，登录控制台
用户命令
rabbitmqctl add_user uname pwd
rabbitmqctl set_user_tags 账号 administrator # 为用户分配操作权限
rabbitmqctl change_password uname pwd
rabbitmqctl delete_user uname
rabbitmqctl list_users # 查看用户列表
rabbitmqctl set_permissions -p /uname ".*" ".*" ".*" #为用户设置admin权限
Docker安装RabbitMQ
参照官方文档：https://registry.hub.docker.com/_/rabbitmq/
# 拉取镜像
docker pull rabbitmq
# 启动
docker run -it --rm --hostname rabbit1 --name rabbit1 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin123 -p 5672:5672 -p 15672:15672 rabbitmq:3.11-management
--hostname：指定容器主机名称
--name：指定容器名称
-p：将rabbitmq端口映射到本地
# 查看日志
docker logs -f rabbitmq
角色分类
none：
不能访问management plugin
management：查看自己节点的相关信息
- 列出自己可以通过AMQP登录的虚拟机
- 查看自己的虚拟机节点（Virtual hosts）的queues、exchanges、bindings信息
- 查看和关闭自己的channels和connections
- 查看有关自己的虚拟机节点virtual hosts的统计信息。包括其他用户在这个节点virtual hosts中的活动信息。
policymaker
- 包含management的所有权限
- 查看、创建、删除自己的virtual hosts所属的policies和parameters信息
monitoring
- 包含management所有权限
- 罗列出所有的virtual hosts，包括不能登录的virtual hosts
- 查看其他用户的connections和channels信息
- 查看节点级别的数据如clustering和memory使用情况
- 查看所有的virtual hosts的全局统计信息。
Administrator
- 最高权限
- 可以创建、删除virtual hosts
- 可以查看、创建、删除user
- 查看、创建permissions
- 关闭所有用户的connections