消息中间件
什么是消息中间件?
- 消息中间件是在消息的传输过程中保存消息的容器
- 消息中间件将消息从源中继(生产者)到目标(消费者)时充当中间人的角色
消息中间件的目的是提供路由并保证消息的传递,如果发送消息时接收者不可用,消息队列会保留消息,直到可以成功地传递它为止,当然消息队列保存消息也是有期限的。
消息中间件 Broker消息中间件有什么特点呢?
- 异步处理模式
消息发送者发送一个消息而无需等待响应,消息发送者将消息发送到一条虚拟的通道(主题或队列)上,消息接收者订阅或监听通道。一条消息可能最终转发给一个或多个消息接收者,这些接收者都无需对消息发送者做出同步回应,整个过程是异步的。
例如:用户信息注册,注册完毕后发送邮件和短信。
- 应用程序之间调用关系为松耦合
- 消息发送者和接收者不必了解对方,只需要确认消息。
- 消息发送者和接收者不必同时在线
例如:在线交易系统为了保证数据的最终一致(一致性),在支付系统处理完毕后会把支付结果放到消息中间件中通知订单系统修改订单支付状态。两个系统通过消息中间件解耦。
消息传递服务模型
消息传递服务模型 消息传递服务模型消息中间件英文全称为Message Oriented Middleware,简称为MOM。
Message-oriented middleware(MOM)is software or hardware infrastructure supporting sending and receiving messages between distributed systems.
消息中间件是在分布式系统间支持收发消息的软件或硬件
消息中间件消息中间件的传递模型
- 点对点模型(PTP, Point To Point)
- 点对点模型用于消息生产者和消费者之间点到点的通信
- 消息生产者将消息发送到由某个名字标识的特定消费者。这个名字实际上对应消息服务中的一个队列(Queue),在消息传递给消费者之前会被存储在这个队列中。
- 队列消息可以存放在内存中也可以是持久的,以保证在消息服务出现故障时仍然能够传递消息。
点对点模型特性
- 每个消息只有一个消费者
- 发送者和接收者之间没有时间依赖
- 接收者确认消息接收和处理成功
- 发布订阅模型(Pub/Sub)
- 发布订阅模型支持向一个特定的消息主题生产消息
- 零个或多个订阅者可能对接收来自特定消息主题的消息感兴趣
- 发布订阅模型中发布者和订阅者彼此不知道对方,好比是匿名公告板。
- 多个消费者可以获得消息
- 在发布者和订阅者之间存在时间依赖性
- 发布者需要建立一个订阅(subscription)以便消费者能够订阅
- 订阅者必须保持持续的活动状态以接收消息
- 除非订阅者建立了持久的订阅,在订阅者未连接时发布的消息将在订阅者重新连接时重新发布。
发布订阅模型特性
- 每个消息可以有多个订阅者
- 客户端只有订阅后才能接收到消息
- 持久订阅和非持久订阅
发布订阅模型特点
- 发布者和订阅者之间有时间依赖
接收者和发布者之间只有建立了订阅关系后才能接收到消息 - 持久订阅
订阅关系建立后消息就不会消失,不管订阅者是否在线。 - 非持久订阅
订阅者为了接收消息必须一直在线,当仅有一个订阅者时相当于点对点模型。
互联网消息中间件应用场景
- 用户注册,注册成功后过一会儿发送邮件确认或短信确认。(发布订阅模式)
SOA(Service-oriented Architecture)面向服务的架构,是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和锲约联系起来。
SOA- 日志分析,将日志进行集中收集,用于计算PV、用户行为分析...
MVP(Minimum Variable Product)最小可行产品,小流量实验 AV-Test
,通过Nginx分流,需要集中收集日志。
- 数据复制
- 将数据从源头复制到多个目的地,一般是要求顺序或保证因果序列。
- 用于跨机房数据传输、搜索、离线数据计算等。
数据复制需要做到两点
- 数据的完整性:
md5
校验... - 数据的顺序性:有限状态机(FSM,Finite-state machine)
- 延迟消息发送和暂存(点对点模式)
- 将消息中间件当成可靠的消息暂存地
- 定时进行消息投递,比如模拟用户秒杀访问,进行系统性能压测。
TCPcopy是一种请求复制的工具,基于TCP的packages,其功能时候复制在线数据包,修改TCP/IP头部信息,发送给测试服务器,达到欺骗测试服务器的TCP程序的目的,从而为欺骗上层应用打下坚实基础。
- 分布式压力测试工具,利用在线数据,可以测试系统能够承受的压力大小,可提前发现bug。
- 普通上线测试,发现新系统是否稳定。
- 对比试验,针对不同版本程序做性能对比等试验。
- 流量放大,利用多种手段构造无限在线压力。
- 热备份
- 实战演练
- 消息广播(发布订阅模式)
- 缓存数据同步更新
- 往应用推送数据,比如更新本地缓存...
利用分布式租约(Lease)机制的方式保证数据的一致性,通过添加时间戳的方式保证数据一致。
消息中间件分类
-
push
推消息模型
消息生产者将消息发送给消息传递服务,消息传递服务再将消息推送给消息消费者。对于发布订阅模式,推消息模型使用的会多一些。推消息模型的好处在于实时性比较高。 -
pull
拉消息模型
消费者请求消息服务接收消息,生产者从消息服务中拉取该消息。拉消息模型适合于点对点的模式,针对时效性要求不高的场景。
推拉模型对比
- 服务端
-
push
处理消息存储、处理请求、保存推送轨迹、保存订阅关系、消费者负载均衡、集中式... -
pull
处理消息存储、处理请求、分布式...
- 客户端
-
push
处理响应与请求 -
pull
处理响应和请求,保存pull
状态(如拉取位置的偏移量offset
)、异常情况下的消息暂存和恢复recover
...
- 实时性
-
push
较好,收到消息后可立即发送给客户端。 -
pull
方式主要取决于pull
的时间间隔
- 消费者故障
-
push
中消费者故障情况下服务端堆积消息,重复推送耗费资源。保存推送轨迹压力很大。 -
pull
中消费者故障对服务端没有影响。
- 其他
-
push
对消息推送有更多控制,能实现多样化的推送机制,当消费者数量增多时,推送压力大性能天花板,消费者处理能力差异导致堆消息。 -
pull
需要在客户端实现消息过滤,浪费资源。需要在不同客户端之间协调,做负载均衡。
应用场景
- 消息广播适用于
push
推送的消息队列 - 延迟消息发送和暂存适用于
pull
拉取的方式
未完待续...