那么,与其等“被动”业务反馈,能不能让这类问题“主动”推送给开发呢 我们能不做个“错误预警”的服务
消息推送技术,即是解决这类问题的良方
消息队列,一般我们会简称它为MQ(Message Queue),再介绍消息队列前,我们还是先简单解释一下队列这种数据结构
队列是一种先进先出的数据结构
如图,数据从队尾(右)进,从队头(左)出
消息队列可以简单的理解为:把要传输的数据放在队列中。
当我们需要使用消息的时候可以取出数据供自己使用。
从以上概念中我们不难看出有两个角色对队列至关重要,一个是放数据的,一个是取数据的
当然,这两个角色都有是有规范的名字的,同时,消息队列有两种场景,在这两种不同的场景里,这两个角色名字是不同的:
包括三个角色:
生产消费者模式特点:
包括三个角色:
发布订阅模式特点:
消息队列为了实现实现高性能,高可用,可伸缩和最终一致性架构,主要可以解决如下问题:
场景举例:
用户注册后,需要发注册邮件和注册短信
传统的做法有两种
场景举例:
银行身份z人脸识别系统,用户上传身份z,人脸识别系统会对该进行人脸识别
一般的做法是:
服务器接收到后,上传系统立即调用人脸识别系统,调用完成后再返回成功
该方法有如下缺点:
为了解决以上缺点,我们采用消息队列解决应用间的耦合问题:
消息队列的做法:
用户上传后,上传系统将信息顺序写入消息队列,直接返回成功;
人脸识别系统则定时从消息队列中取数据,完成对的识别。
上传系统并不需要关心人脸识别系统是否对这些信息的处理、以及何时对这些信息进行处理。事实上,由于用户并不需要立即知道人脸识别结果,人脸识别系统可以选择不同的调度策略,按照闲时、忙时、正常时间,对队列中的信息进行处理。
场景举例:
电商秒杀活动,常见的形式是数量极少的热门商品让大量的用户抢购
传统的做法是用户直接请求业务系统,但往往因为并发用户过大,或导致业务系统崩溃,或着出现超卖等等现象
采用消息队列后,系统可以从消息队列中取数据,相当于消息队列做了一次缓冲
采用消息队列处理秒杀有如下优点:
使用消息队列有如下优点:
消息队列是分布式系统中重要的组件,使用消息队列主要是为了通过异步处理提高系统性能和削峰、降低系统耦合性。目前使用较多的消息队列有ActiveMQ,RabbitMQ,Kafka,RocketMQ,这些消息中间件我们暂时不讲,本章,我们使用最为简单的方式REDIS来实现消息队列的发布订阅模式
Redis从2X版本开始,就支持一种基于非持久化消息的、使用发布/订阅模式实现的事件通知机制
所谓基于非连接保持,是因为一旦消息订阅者由于各种异常情况而被迫断开连接,在其重新连接后,
其离线期间的事件是无法被重新通知的(一些Redis资料中也称为即发即弃)
而其使用的发布/订阅模式,意味着其机制并不是由订阅者周期性的从Redis服务拉取事件通知,
而是由Redis服务主动推送事件通知到符合条件的若干订阅者
通俗的来讲,Redis实现的发布订阅模式有如下注意点:
以上已经实现了基于redis简单的发布订阅了
那么,在此之上我们多做一点来更好的理解发布订阅这块的内容
>注册一个微服务。
1、准备三个服务,Eureka服务+提供RESTAPI的两个简单的微服务。
2、将微服务注册到微服务中。
3、springboot不以任何方式限制这些应用程序的内存使用。此时springboot服务器就能共享内存了。商家的后台管理系统实现新订单提醒推送功能,利用Spring Boot + WebSocket实时消息推送的方式进行实现。
引入依赖,我使用的是SpringBoot版本226RELEASE,自动管理依赖版本
配置类WebSocketConfig,扫描并注册带有@ServerEndpoint注解的所有websocket服务端
新建WebSocketServer类,WebSocket服务端是多例的,一次WebSocket连接对应一个实例
辅助类
新建一个测试类,用于向客户端发送推送消息
1、 启动服务器程序,提供WebSocket服务。
2 、打开前端html客户端页面,连接WebSocket服务器。
3、向客户端发送推送消息
4、客户端收到新订单推送消息
当我们在本地开采用WebSocket用IP连接时是OK的,例如
当我们上线后,用Nginx部署,并用域名连接时就会失败。此时只需要在Nginx配置文件里加入一些配置即可。配置如下
参考文章
Websocket实时推送消息
阿里云折扣快速入口
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)