美文网首页
java消息机制

java消息机制

作者: Mango_yes | 来源:发表于2018-03-20 09:58 被阅读0次

    1.什么是消息队列?

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

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

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

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

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

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

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

    3.应用场景

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

    (1)异步处理

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

    串行方式:

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

    并行方式:

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

    引入消息队列:

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

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

    2.应用解耦

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

    传统模式的特点:

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

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

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

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

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

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

    3.流量削峰

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

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

    1.可以控制活动的人数

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

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

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

    4.日志处理

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

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

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

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

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

    (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同时使用同一队列,进行消息通讯。

    聊天室通讯:

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

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

    相关文章

      网友评论

          本文标题:java消息机制

          本文链接:https://www.haomeiwen.com/subject/zlepqftx.html