java消息机制

1.什么是消息队列?

1.消息队列是一个队列,先进先出,你无法读取消息队列中间的消息,只能按照顺序,从消息队列的头一个接一个的读,

2,要控制消息队列的权限,example:msmq,加入建立完消息队列但是不给消息队列的权限上加上用户的话,那么这个用户是不可以想这个消息队列发送消息的。

3.消息队列是要分事务性和非事务性的。

2.为什么要使用消息队列?什么情况下会使用消息队列?

个人理解是:实时性要求不高、而且耗时的任务,是队列的最佳应用场景。

example1:在网战注册一个账号,当信息入库注册成功后网站需要发送一个邮件激活,这个激活邮件其实并不是需要实时响应的,没有必要卡在注册页面等待邮件的发送成功,再说发送邮件本身就是一个很耗时的操作(需要第三方smtp服务器),此时选择消息队列去处理。注册完成之后,想消息队列中投递一个消息,消息的内容包含我要发送邮件的一些设置,发送时间,重试次数等消息属性,这里的入库(可以是入库、写入缓存redis)是要消息进入一个实体的队列。其中应该有一进程(消费者)一直在后台运行,它不断地轮询消息队列中的消息(按时间顺序,队列是先进先出),看有没有达到执行条件的,如果有就取出一条,根据消息的配置去执行任务,如果成功,就销毁这条消息,继续轮询,如果失败,则重试,直到达到重试次数,这是用户已经收到注册成功的提示,但是已经去做其他事情了,邮件来了之后,点击邮件激活,注册成功。这个例子是消息队列的一个典型应用。

example2:点赞。这个在高并发的情况下很容易造成数据库链接占满 ,导致整个网站响应缓慢,所以想到解决数据库压力的问题,方法有两种:planA、提高数据库本身的能力(如:增大数据库的连接数量、读写分离等),但数据库的连接数量总是有限的,到达了极限是没有办法再提升的了,此时要考虑planB:释放数据库的压力。将压力转移到缓存里面。用户的点赞到来,我只是讲点赞请求投递到消息队里面,后续的点赞请求可以将消息合并,即只更新点赞数,不产生新的任务,此时有个进程在不断的轮询消息队列,将点赞消息消耗,并将值更新到数据库里面,这样就有效降低了数据库的压力,因为在缓存层将数个数据库更新请求合并成一个,大大提高了效率,降低了负载。

3.应用场景

下面说一下消息队列的具体应用场景

(1)异步处理

还是上述提到的注册发送邮件的例子,用户注册后,需要发注册邮件和注册短信。传统的做法有两种1.串行的方式;2.并行方式。

串行方式:

将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端。用时150ms


java消息机制_第1张图片

并行方式:

将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间,用时100ms


java消息机制_第2张图片

引入消息队列:

将非必须的业务逻辑,异步处理。用时55ms,改造后的架构如下:

java消息机制_第3张图片

可以明显看出消息队列比串行提高了3倍,比并行提高了两倍。

2.应用解耦

场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是:订单系统调用库存系统的接口,如下图:

java消息机制_第4张图片

传统模式的特点:

1)加入库存系统无法访问,则订单减库将失败,从而导致订单失败;

2)订单系统与库存系统耦合;

如何解决以上问题呢?引入消息队列后的方案,如下图:


java消息机制_第5张图片

订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单成功。

库存系统:订阅下单的消息,采取拉/推的方式,获取下单信息,库存系统根据下单信息,进行库存操作。

假如:在下单时库存系统不能正常使用,也不影响正常下单,因为下单后,订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦。

3.流量削峰

流量削峰一般也是消息队列的常用场景,一般在秒杀或团抢活动中应用广泛。

应用场景:秒杀活动,一般会因为流量暴增,应用挂掉。为解决这个问题一般会在前端加入消息队列。    

1.可以控制活动的人数

2.可以缓解短时间内高流量压跨应用。


java消息机制_第6张图片

1)用户的请求,服务器接收后首先写入消息队列。假如消息队列长度超过最大长度,则直接抛弃用户请求或跳转到错误页面;

2)秒杀业务根据消息队列中的请求信息,再做后续处理。

4.日志处理

日志处理是指将消息队列应用在日志处理中,比如kafka的应用,解决大量日志传输问题,架构简化如下:

java消息机制_第7张图片

1)日志采集客户端,负责日志数据采集,定时接受写入Kafka消息队列。

2)Kafka消息队列,负责日志数据的接收、存储、和转发;

3)日志处理应用:订阅并消费Kafka队列中的日志数据。

下图是新浪Kafka日志处理应用案例:




java消息机制_第8张图片

(1)Kafka:接收用户日志的消息队列。

(2)Logstash:做日志解析,统一成JSON输出给Elasticsearch。

(3)Elasticsearch:实时日志分析服务的核心技术,一个schemaless,实时的数据存储服务,通过index组织数据,兼具强大的搜索和统计功能。

(4)Kibana:基于Elasticsearch的数据可视化组件,超强的数据可视化能力是众多公司选择ELK stack的重要原因。

(1)Kafka:接收用户日志的消息队列。

(2)Logstash:做日志解析,统一成JSON输出给Elasticsearch。

(3)Elasticsearch:实时日志分析服务的核心技术。一个schemaless实时的数据存储服务,通过index组织数据,兼具强大的搜索和统计功能。

(4)Kibana:基于ElasticSearch的数据可视化组件,超强的数据可视化能力是众多公司选择ElasticSearch的重要原因。

5.消息通讯

消息通讯是指消息队列一般都内置了高效的通讯机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等。

点对点通讯:

客户端A与客户端B同时使用同一队列,进行消息通讯。

java消息机制_第9张图片

聊天室通讯:

客户端A、客户端B、客户端N同时订阅同一主题,进行消息发布和接收。实现类似聊天室效果。

以上实际是消息队列的两种消息模式,点对点和订阅发布模式。


java消息机制_第10张图片

你可能感兴趣的:(java消息机制)