消息队列(MQ)简介
消息队列的模型是【生产发送--消息队列存储--消费者消费】,通过指定的topic可以对发送和消费消息,出于安全考虑,也可以在消费和生产消息的时候添加权限认证。以下是消息队列的模型
消息队列的两种模式
点对点模式
点对点模式下包括三个角色:
- 消息队列
- 发送者 (生产者)
- 接收者(消费者)
消息发送者生产消息发送到queue中,然后消息接收者从queue中取出并且消费消息。消息被消费以后,queue中不再有存储,所以消息接收者不可能消费到已经被消费的消息。
点对点模式特点:
- 每个消息只有一个接收者(Consumer)(即一旦被消费,消息就不再在消息队列中);
- 发送者和接收者间没有依赖性,发送者发送消息之后,不管有没有接收者在运行,都不会影响到发送者下次发送消息;
- 接收者在成功接收消息之后需向队列应答成功,以便消息队列删除当前接收的消息;
发布/订阅模式
发布/订阅模式下包括三个角色:
- 角色主题(Topic)
- 发布者(Publisher)
- 订阅者(Subscriber)
发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。
发布/订阅模式特点:
- 每个消息可以有多个订阅者;
- 发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。
- 为了消费消息,订阅者需要提前订阅该角色主题,并保持在线运行;
消息队列的使用场景
消息队列的主要使用场景有4个:异步处理,应用解耦,流量削锋和消息通讯。
异步处理
引入消息队列,将不是必须的业务逻辑进行异步处理,相比串行或并行拥有搞好的响应速度。
应用场景:用户注册-》发送短信-》邮箱提醒,主逻辑为保存用户的注册信息。注册成功之后短信和邮箱提醒,这部分可以写入消息队列,之后由短信和邮箱服务消费,这样对于主服务拥有更好的响应速度。
应用解耦
场景说明:用户使用QQ相册上传一张图片,人脸识别系统会对该图片进行人脸识别,一般的做法是,服务器接收到图片后,图片上传系统立即调用人脸识别系统,调用完成后再返回成功。如果人脸识别系统被调失败,导致图片上传失败,而且延迟比较高,系统耦合度高。
应用场景:客户端上传图片后,图片上传系统将图片信息如uin、批次写入消息队列,直接返回成功;而人脸识别系统则定时从消息队列中取数据,完成对新增图片的识别。
此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上,由于用户并不需要立即知道人脸识别结果,人脸识别系统可以选择不同的调度策略,按照闲时、忙时、正常时间,对队列中的图片信息进行处理。
注意:之前在网上看到一些订单库存系统使用消息队列的,这一块对消息队列服务器的数据准确性和稳定性是比较有要求的,因为这一块也关系到事务管理,如果没有及时处理库存的话可能会照成实际库存不足,但用户依然可以下单的情况。
流量削峰
流量削锋也是消息队列中的常用场景,一般在秒杀或团抢活动中使用广泛。
应用场景:秒杀活动;短时间内的大流量直接访问数据会让服务有宕机的风险,因此使用消息队列分方式可以有效减缓大流量带来的压力。一般需要在应用前端不会直接请求服务,会先加入消息队列,之后由服务订阅消费消息。
消息通讯
消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等。
常见的消息队列
常见的消息队列有:RabbitMQ、ActiveMQ、RocketMQ、Kafka
各个消息队列的特点可以查看:https://www.cnblogs.com/Terry-Wu/p/7644279.html
常见消息队列的对比
消息队列的选型需要根据具体应用需求而定,RabbitMQ大而稳,Kakfa和RocketMQ快而强劲。