2.1 什么是JMS?
JMS是java的消息服务,JMS的客户端之间可以通过JMS服务进行异步的消息传输。
2.2 什么是消息模型
○ Point-to-Point(P2P) — 点对点 ○ Publish/Subscribe(Pub/Sub)— 发布订阅 |
即点对点和发布订阅模型
2.2.1 P2P (点对点)
1、P2P
2、涉及到的概念
-
- 消息队列(Queue)
- 发送者(Sender)
- 接收者(Receiver)
- 每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,直到他们被消费或超时。
3、P2P的特点
- 每个消息只有一个消费者(Consumer)(即一旦被消费,消息就不再在消息队列中)
- 发送者和接收者之间在时间上没有依赖性,也就是说当发送者发送了消息之后,不管接收者有没有正在运行,它不会影响到消息被发送到队列
- 接收者在成功接收消息之后需向队列应答成功
如果你希望发送的每个消息都应该被成功处理的话,那么你需要P2P模式。
应用场景
A用户与B用户发送消息
2.2.2Pub/Sub (发布与订阅)
Pub/Sub模式图
涉及到的概念
主题(Topic)
发布者(Publisher)
订阅者(Subscriber)
客户端将消息发送到主题。多个发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
Pub/Sub的特点
每个消息可以有多个消费者
发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息,而且为了消费消息,订阅者必须保持运行的状态。
为了缓和这样严格的时间相关性,JMS允许订阅者创建一个可持久化的订阅。这样,即使订阅者没有被激活(运行),它也能接收到发布者的消息。
如果你希望发送的消息可以不被做任何处理、或者被一个消息者处理、或者可以被多个消费者处理的话,那么可以采用Pub/Sub模型
消息的消费
在JMS中,消息的产生和消息是异步的。对于消费来说,JMS的消息者可以通过两种方式来消费消息。
○ 同步
订阅者或接收者调用receive方法来接收消息,receive方法在能够接收到消息之前(或超时之前)将一直阻塞
○ 异步
订阅者或接收者可以注册为一个消息监听器。当消息到达之后,系统自动调用监听器的onMessage方法。
发布订阅模式:
消息容器 类似队列
队列里面存放多个消息,消息容器里面可以存放多个队列
原则: 先进先出原则
生产者 消费者 消息容器
消费者和消息容器建立长链接 一旦生产者发布消息后 推送退给 消费者(监听)
如果消费者宕机了,消息会丢失吗?
不会的。原因消息存在队列里面的。队列中存放消息,如果消费者没有及时消费的话,都会存放在消息队列中。
消息中间件可以解决高并发问题,流量削锋问题,如果生产者上产一万个消息,消费者每次只能一千个消息消费。
整个过程属于异步方式的。
1、生产者发送一条消息到queue,只有一个消费者能收到 (一对一模式)
2、客户端包括生产者和消费者 队列中的消息只能被一个消息消费者消费
消息消费者可以随时消费队列中的消息
1、发布者发送套tipic的消息,只有订阅了topic的订阅者才会收到消息
1 特性:
客户端暴扣发布者和订阅者
主题中的消息被所有订阅者消费
消费者不能消费订阅之前就发送到主题中的消息
发布订阅和点对点通讯方式的却别:
点对点 只能保证一个消费者进行消费
发布订阅 只要集群服务订阅该主题都会收到消息 一对多
下次队列指的是生产者与消费者传递数据
队列里存放消息集合
消息中间件包括 消息队列 和 发布订阅
应用场景:
用户注册、订单修改库存、日志存储
画图演示
异步处理
场景说明:用户注册后,需要发注册右键和注册短信。传统的做法两种:
1、串行方式 将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。串行方式: 一步一步走 是同步的过程 单线程的
2、并行方式 将信息写入数据库成功后,发送注册邮件的同时,发送注册短信。完成任务后,返回给客户端,与串行的区别是,并行方式可以提高处理的时间
2、引入消息队列。将不是必须的业务逻辑异步处理。用户响应时间相当于是注册信息写入数据库的时间,也就是50毫秒。注册邮件发送短信写入消息队列后,直接返回。因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。系统的吞吐量提高到每秒20 QPS,比串行提高了3倍,比并行提高了2倍。
这样提高程序效率
如果消费者发送短信或者邮件消费失败的话,MQ自带重合和补偿机制。
耗时间的接口 统一采用MQ推送 不建议使用激光同步方式
消息队列应用场景 流量削峰的使用
流量削峰是消息队列汇总的常用场景,一般再秒杀或者团抢活动中使用
秒杀活动,一般回应为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要再应用其那段加入消息队列。
1、控制活动人数
2、缓解短时间内流量压垮应用
用户的请求,服务器接受后,首先写入消息队列。加入消息队列长度超过最大数量,则直接抛弃用户请求或者跳转错误页面
秒杀业务根据消息队列中的请求信息,在做后续处理
秒杀: Redis+MQ+服务保护机制(服务降级、隔离、熔断)+服务限流+图像验证码+token
原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/16180.html