分布式消息中间件设计

目录

1、什么是分布式消息中间件

1.1、单体架构

1.2、分布式系统架构

2、基于消息中间件的分布式系统架构

2.1、什么是消息中间件

2.2消息中间件概述 

3、消息中间件的核心设计 

3.1、本质

3.2、五大核心组成部分

 3.2.1、协议 

3.2.2、持久化

3.2.3消息分发

3.2.4高可用 

3.2.5高可靠

---

1、什么是分布式消息中间件

1.1、单体架构

单体应用：所有代码、模块，全部放在一个应用里面。如果其中一个模块要升级，那么整个系统全部要升级。如果部署在十个机器中，改了一个小功能，十个机器全部都得升级。

面临问题：耦合度高、开发困难，面临的问题很多

1.2、分布式系统架构

分布式系统：将一个大的系统按照业务模块、功能模块的技术划分，分成多个独立的子系统。

 下图将一个大系统拆分为前台系统、订单系统、会员系统 ，各系统之间相互独立、独立部署。升级某一个系统，其他子系统不需要调整。

用户发送请求到前台系统，用户的一个请求不是一个前台系统可以完成的。

例如：用户需要自己的订单信息和会员信息，发送请求到前台系统，前台系统需要系统订单系统和会员系统，处理此次请求。

像这种多系统协同处理一个请求的场景，我们称为分布式系统。

系统与系统之间也存在相互调用，这就需要rpc（远程过程调用）技术。这样的做法，系统之间存在强耦合度。为了实现降耦合，实现更强的扩展性架构，所以在分布式系统中引入了消息中间件。

通过消息中间件解决系统之间的耦合

2、基于消息中间件的分布式系统架构

用户发送创建订单的请求，并不是直接由订单系统处理。

用户发送创建 订单的请求给前台系统，前台系统将请求传递至消息中间件暂存之后，由消息中间件传递给对应的子系统处理，再进行一个客户端的相应。

 

2.1、什么是消息中间件

消息中间件：临时存储一些消息、一些数据的，独立部署的，所以叫中间件。用于各个系统之间，进行数据交换的。

系统之间用了这个消息中间件之后，就没有一个直接的关联了，不会直接调用，由消息中间件进行转换。

系统之间交换数据：可以用接口直接调用、还可以用消息中间件异步处理，异步分发。
 

2.2消息中间件概述 

什么是消息中间件

①利用高效可靠的消息传递机制进行平台无关的数据交流。

②并基于数据通信来进行分布式系统的集成。

③通过提供消息机制和消息排队模型，它可以在分布式环境下扩展进程间的通信；

消息中间件的应用场景

• 跨系统数据传递
• 高并发流量削峰
• 数据异步处理等

例如：现在有1万条数据需要插入数据库，直接插入数据库压力大，可以将插入数据缓存在消息中间件里，异步处理，流量削峰，降低并发量。

常见的消息中间件

 ActiveMQ、RabbitMQ、Kafka、RocketMQ  

 这些都是基于网络的，基于消息传递机制的，也就是生产者消费者的场景。

3、消息中间件的核心设计 

我们自己怎么去写消息中间件？ 

3.1、本质

一种可以接收请求、保存数据、发送数据等功能的网络应用。

和一般的网络应用的区别：它主要负责数据的接收和传递，所以性能一般都高于普通程序。

3.2、五大核心组成部分

• 协议
• 持久化机制
• 消息分发机制
• 高可用设计
• 高可靠设计

 3.2.1、协议 

协议是计算机通信之间共同遵从的一组约定，都遵守相同的约定，计算机之间才能相互交流。

是对数据格式和计算机之间交换数据时必须遵守的规则的正式描述。

例如：服务端xml数据，客户端用json解析数据。不遵守同一协议无法解析。

 协议三要素：

• 语法：数据与控制信息的结构与格式。（传输数据的结构是什么样子的）
• 语义：需要发出何种控制信息，完成何种动作以及做出何种响应（发送什么样的信息） 
• 时序（同步）：事件实现顺序的详细说明

常见协议

Http协议三要素：

语法：规定了请求报文和响应报文的具体格式。(nio、bio)

语义：客户端主动发起的操作称为请求；（post、get请求...）

时序：一个请求对应一个响应(request、respond）

http不太适合消息中间件MQ来使用，

消息中间件常用的协议：

OpenWire（ActiveMQ专属）、AMQP、MQTT、Kafka、OpenMessage

为什么消息中间件不使用Http协议？

①http请求内容很多，一个简单的请求需要传递一堆的数据，语法格式复杂，包含请求头、Coking等信息，状态码信息等。消息中间件，需要的是单一的，尽量简洁、尽量减少我们传递数据的大小。这就是大部分消息中间件不使用Http的原因，Http太大了。

②Http大部分情况下都是短连接。每次交互请求响应之后，就会中断，不利于消息中间件的场景。因为消息中间件可能是一个客户端长期去获取消息中间件里的信息，或者往消息中间件里发数据，不太适合短连接 

AMQP协议：

Advanced Message Queuing Protocol 高级消息队列协议。

04年Jpmorgan Chase 摩根大通集团联合其他公司共同设计。

特性：

事务支持、持久化支持 ，出生金融行业，在可靠性消息处理上具备天然的优势。

MQTT协议：

Open Message协议 

Kafka协议：

3.2.2、持久化

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

不做持久化，服务器突然宕机，消息中间件中未处理的消息就会消失。 

常用的持久化方式

写到日志文件，特定格式存储。或者用数据库的场景。

3.2.3消息分发

消息中间件中的数据，将消息推送给消费者。消费者拉取消息队列中的数据。

为什么要有消息分发策略？

一个消息中间件链接多个系统，消息中间件中的消息应该发送给那个系统呢？根据什么样的策略准确发送给对应的系统 

第一次发送给消费者，处理错误，是否可以重发，继续分发处理

 常用的消息中间件分发策略

3.2.4高可用 

高可用机制

高可用是指产品在规定的条件和规定的时刻或时间区间内处于可执行规定功能状态的能力。

当业务量大时，一台消息中间件可能无法满足需求，所以需要消息中间件能够集群部署，来达到高可用目的。

Master-Slave主从共享数据的部署方式：

主broker获取数据，消息存储，其他broker可以共享读取。

Master-Slave主从同步部署方式：

生产者发送数据过来，会把数据存储在 主服务器和从服务器上。三台机器同时对外服务，解决读数据的负载均衡问题。 生产者数据插入修改只能在主服务器上执行。

同步占用很大的带宽。 

Broker-Cluster多主集群同步部署方式

都是主服务器，可以进行相互之间的数据同步

不管是读还是写，都可以负载均衡 

 Broker-Cluster多主集群转发部署方式

不同的元数据存储在不同的broker上， 元数据的描述信息同步在各个broker上。

请求拉取broker-1上的某条数据时，broker-1上没有该数据，但是它知道broker-2上有这个数据，于是就转发到broker-2上。

Master-Slave和 Broker-Cluster结合

挂了数据不会丢失还可以用。

3.2.5高可靠