分布式消息中间件设计
分布式架构
要说分布式消息中间件,需要先了解什么是分布式,我们可以从架构入手。
单体架构
我们最先接触到的系统很多都是单体架构,所有的代码和模块都放在一个系统里面,若其中一个模块需要升级,那么整个系统都需要升级,这样子系统的耦合度太高,开发起来较为困难。如下图所示:
分布式架构
分布式系统架构:就是把一个大的系统按照业务模块或者功能模块技术的划分,如下图,我们三个系统都是独立部署的,其中一个升级的时候,剩下两个系统不需要去调整,所以一般多系统协同处理一个请求的系统我们就会认为它是分布式系统,比如前台需要展示用户信息和用户的订单就需要调用订单系统和会员系统,除了请求的调用,系统与系统之间也会互相调用,会使用rpc接口调用等方式来实现。但是系统之间这样直接调用会有很强的耦合度,所以就出现了消息中间件,用消息中间件来解决分布式系统之间的耦合。
基于消息中间件的分布式系统架构
如果用户发送一个注册信息,或者创建一个订单,将这些消息传递给消息中间件后,再由小子中间件,再由消息对应的子系统处理,处理完成后再进行一个客户端的响应。当用户创建订单的时候,会有一个创建订单的消息传递个消息中间件,消息中间件只是临时存储一些消息或者数据,处于各个系统之间,用于数据交换。这样子系统与系统之间就不存在一个直接的调用,这是一个异步的处理和消息分发。
消息中间件
我们已经了解了什么是分布式,也知道了基于消息中间件的分布式架构的好处,那么我们接下来就可以去学习消息中间件
消息中间件概述
利用高效可靠的消息传递机制进行平台无关的数据交流;并基于数据通信来进行分布式系统的集成;通过提供消息传递(生产者消费者)和消息排队模型,它可以在分布式环境下扩展进程间的通信。
应用场景
跨系统数据传输、高并发流量削峰、数据异步处理…等等
常用的消息中间件
ActiveMQ、RAbbitMQ、kafaka、RocketMQ
消息中间件的核心设计
本质
一种具备接受请求,保存数据,发送数据等功能的网络应用。和一般网络应用程序的区别是他主要负责数据的接收和传递,所以性能一般都高于普通程序。
五大核心组成
- 协议
- 持久化机制
- 消息分发机制
- 高可用机制
- 高可靠机制
协议
协议是计算机之间通信时共同遵从的一组约定,都遵守相同的约定,计算机之间才能相互交流。是对数据格式和计算机之间相互交换数据时必须遵守的规则的正式描述。例如:HTTP协议。
HTTP协议三要素举例
- 语法:Http规定了请求报文和响应报文的具体格式
- 语义:客户端主动发起的操作成为请求(post、get)
- 时序:一个请求对应一个响应
常用的消息中间件协议
虽然在系统与系统之间的调用我们经常使用Http,但是消息中间件基本上不会使用Http,因为HTTP协议内容很多,不利于消息的快速传输,所以消息中间件常用的协议有:OpenWire、AMQP、MQTT、Kafka、OpenMessage
AMQP
AMQP(Advanced Message Queuing Protocol)是高级消息队列协议,04年JPMorgan Chase(摩根大通集团)联合其他公司共同设计。
特性:事务支持,持久化支持,出生金融行业,在可靠性消息处理上具备天然优势。
MQTT
MQTT(Message Queuing Telemetry Transport)消息队列遥测传输,是IBM开发的一个即时通讯协议,物联网系统架构中的重要组成部分。
特性:轻量、结构简单、传输快、没有事务支持、没有持久化相关设计
应用场景:适用于计算能力有限、低带宽、网络不稳定的场景
Kafka
kafka协议是基于TCP的二进制协议。消息内部是通过长度来分隔,由一些基本数据类型组成。
特性:结构简单、解析快、无事务设计、有持久化设计
消息中间中的数据有的补需要存储,而有的则需要进行存储,数据的存储就是持久化。简单来说就是将数据存入磁盘,而不是存在内存中随服务重启而消失,使数据能够永久保存叫做持久化
OpenMessage
Open Message是近一两年,由阿里发起,与雅虎,滴滴出行,Sreamlio等公司共同参与创立的分布式消息中间件、流处理领域的应用开发标准。是国内首个在全球范围内发起的分布式消息领域国际标准
特性:结构简单、解析快、有事务设计、有持久化设计
持久化
简单来说就是将数据存入磁盘,而不是存在内存中随服务重启而消失,使数据能够永久保存叫做持久化
常用持久化方式
ActiveMQ | RabbitMQ | Kafka | RocketMQ | |
---|---|---|---|---|
文件系统 | 支持 | 支持 | 支持 | 支持 |
数据库 | 支持 | \ | \ | \ |
消息分发
为什么要有消息分发策略
例如网上购物的时候,前台系统生成一个订单消息传入消息中间件,消息中间需要根据消息分发策略将这个订单消息传递个合适的系统进行处理;或者网上支付的是会遇到支付失败的时候,当用户支付失败后(支付系统处理失败),这个时候就需要重发。
常用的消息中间件分发策略
ActiveMQ | RabbitMQ | Kafka | RocketMQ | |
---|---|---|---|---|
发布订阅 | 支持 | 支持 | 支持 | 支持 |
轮询分发 | 支持 | 支持 | 支持 | |
公平分发 | 支持 | 支持 | ||
重发 | 支持 | 支持 | 支持 | |
消息拉取 | 支持 | 支持 | 支持 |
高可用
高可用机制
高可用性是指产品在规定的条件和规定的时刻或者时间区间处于可执行规定功能状态的能力
当业务量大时,一台消息中间件服务器可能无法满足需求,所以需要消息中间件能够集群部署,来达到高可用的目的。
Master-Slave主从共享数据的部署方式
当客户端发送消息到主服务器上时,它会将消息存入文件系统或者数据库中,当主服务器挂了以后,客户端回去连接第二个从服务器,因为数据是共享的,所以读取到的数据是一样的。
Master-Slave主从同步部署方式
生产者发送数据过来以后,数据不仅仅存在于主服务器上面,数据还会同步到从服务器上面,所以此时三台服务器都可以提供服务,但是修改数据只能交给主服务器,解决读数据的负载均衡的问题,但是同步数据会占用大量资源(带宽)。
Broker-Cluster多主集群同步部署方式
此时有多台主服务器,可以在不同主服务器上插入数据,服务器之间相互进行同步。读写都实现了负载均衡。
Broker-Cluster多主集群转发部署方式
主机之间不同步数据信息,将数据进行描述(元数据),同步元数据,当消费者请求服务器1,服务器1上没有消费者所需要的数据,服务器1就会将请求转发给有相应数据的服务器2上或者去读取服务器2上的数据做一个代理,共享元数据相比于共享具体数据,开销要小一些,但是若其中一台服务器挂掉了,那么这台服务器上的数据就无法读取。
Master-Slave与Broker-Cluster结合
既可以实现负载均衡,又可以实现热备份,大的方向上看有多台主机,每一台主机又有自己的从服务器进行数据的备份。
高可靠
高可靠性是指系统可以无障碍地持续运行。比如一个系统从来不崩溃、报错,或者崩溃、报错的几率比较低,那就是高可靠。
在高并发业务场景下,如果不能保证系统的高可靠,那么造成的损失将会非常严重。
保证消息中间件的高可靠性,可以从下面几方面考虑:
消息传输可靠:通过协议来保证系统间数据解析的正确性。
消息存储可靠:通过持久化来保证消息的存储可靠性。