MQ见解

MQ

 消息队列是系统级、模块级的通信。RPC是对象级、函数级通信。 

1) 什么是推模式,什么是拉模式

2) 有没有消息丢失情况,如何防止

3) MQ用来解决什么问题

4) 你们用的什么MQ,为什么要用这个,它的最大吞吐量是多少

AcitveMQ是作为一种消息存储和分发组件

  ActiveMQ默认的使用的协议是openWire,端口号:61616   一条消息从producer端发出之后,一旦被broker正确保存,那么它将会被consumer消费,然后ACK,broker端才会删除;不过当消息过期或者存储设备溢出时,也会终结它

持久化   非持久化消息是存储在内存中的,持久化消息是存储在文件中的 ActiveMQ会将内存中的非持久化消息写入临时文件中,以腾出内存。虽然都保存到了文件里,但它和持久化消息的区别是,重启后持久化消息会从文件中恢复,非持久化的临时文件会直接删除   设置2G左右的持久化文件限制,大量生产持久化消息直到文件达到最大限制,此时生产者阻塞,但消费者可正常连接并消费消息,等消息消费掉一部分,文件删除又腾出空间之后,生产者又可继续发送消息,服务自动恢复正常。

  设置2G左右的临时文件限制,大量生产非持久化消息并写入临时文件,在达到最大限制时,生产者阻塞,消费者可正常连接但不能消费消息,或者原本慢速消费的消费者,消费突然停止。整个系统可连接,但是无法提供服务,就这样挂了。

  解决方案:尽量不要用非持久化消息,非要用的话,将临时文件限制尽可能的调大

死信队列   一条消息不能正常处理.重发给其他服务器处理依旧不能处理.重试6次(重试次数可配置)后MQ就把这条消息放到死信队列 optimizeACK(可优化的ACK 延迟确认”的语义(ACK时机))和 prefethSize(批量预获取(默认1000))   optimizeACK时机 () optimizeACK优化了消息确认的性能     只有当session的ACK_MODE为AUTO_ACKNOWLEDGE时才会生效 client端在消费消息后暂且不发送ACK,而是把它缓存下来(pendingACK),等到这些消息的条数达到一定阀值时,只需要通过一个ACK指令把它们全部确认;这比对每条消息都逐个确认,在性能上要提高很多     optimizeACK有效时,如果客户端已经消费但尚未确认的消息(deliveredMessage)达到prefetch * 0.65,consumer端将会自动进行ACK;同时如果离上一次ACK的时间间隔,已经超过"optimizeAcknowledgeTimout"毫秒,也会导致自动进行ACK。     prefetchACK为true,那么prefetch必须大于0;当prefetchACK为false时,你可以指定prefethSize为0以及任意大小的正数 prefethSize(默认1000) prefethSize优化了消息传送的性能   批量获取消息,并“延迟”确认(ACK)。prefethSize表达了“批量获取”消息的语义,broker端主动的批量push多条消息给client端,总比client多次发送PULL指令然后broker返回一条消息的方式要优秀很多,它不仅减少了client端在获取消息时阻塞的次数和阻塞的时间,还能够大大的减少网络开支   prefethSize=0时,表示consumer将使用PULL(拉取)的方式从broker端获取消息,broker端将不会主动push消息给client端,直到client端发送PullCommand时   当prefethSize=>0时,表示consumer将接受broker端PUSh(推送)的方式获取消息,此后只要当client端消费且ACK了一定的消息之后,会立即push给client端多条消息

consumer获取消息的方式   使用receive()方法同步获取消息     prefethSize可以为0和任意正值;当prefethSize=0时,那么receive()方法将会首先发送一个PULL指令并阻塞,直到broker端返回消息为止,这也意味着消息只能逐个获取(类似于Request<->Response),这也是Activemq中PULL消息模式;当prefethSize > 0时,broker端将会批量push给client 一定数量的消息(<= prefethSize),client端会把这些消息(unconsumedMessage)放入到本地的队列中,只要此队列有消息,那么receive方法将会立即返回,当一定量的消息ACK之后,broker端会继续批量push消息给client端

使用MessageListener异步获取消息   这就需要开发设定的prefethSize值必须 >=1,即至少为1;在异步消费消息模式中,设定prefethSize=0,是相悖的,也将获得一个Exception   消息的确认是在onMessage方法返回之后,如果onMessage方法异常,会导致消息不能被ACK,会触发重发

consumer的消费能力   如果consumer端消费速度很慢(对消息的处理是耗时的) 过大的prefetchSize,并不能有效的提升性能,反而不利于consumer端的负载均衡(只针对queue),使用较小的prefetchSize,同时关闭optimizeACK,可以让消息在多个consumer间“负载均衡”   如果较大的prefetchSize,将会导致broker一次性push给client大量的消息,但是这些消息需要很久才能ACK(消息积压),而且在client故障时,还会导致这些消息的重发   如果consumer端消费速度很快,但是producer端生成消息的速率较慢 .开启optimizeACK,但是需要设置较小的prefetchSize;这样可以保证每个consumer都能有"活干",否则将会出现一个consumer非常忙碌,但是其他consumer几乎收不到消息。   如果消息很重要,那么我们需要将optimizeACK=false,prefetchSize=1   总之消费端要对重复消息做幂等控制,在消息被消费之后还没有来得及确认时,client端发生故障,那么这些消息就有可能会被重新发送给其他consumer ACK模式 JMS API中约定了Client端可以使用四种ACK_MODE,在javax.jms.Session接口中: AUTO_ACKNOWLEDGE = 1 自动确认 CLIENT_ACKNOWLEDGE = 2 客户端手动确认  DUPS_OK_ACKNOWLEDGE = 3 自动批量确认 SESSION_TRANSACTED = 0 事务提交并确认 INDIVIDUAL_ACKNOWLEDGE = 4 单条消息确认(AcitveMQ补充了一个自定义的ACK_MODE)

ActiveMQ中定义了如下几种ACK_TYPE(参看MessageAck类):

  • DELIVERED_ACK_TYPE = 0    消息"已接收",但尚未处理结束
  • STANDARD_ACK_TYPE = 2    "标准"类型,通常表示为消息"处理成功",broker端可以删除消息了
  • POSION_ACK_TYPE = 1    消息"错误",通常表示"抛弃"此消息,比如消息重发多次后,都无法正确处理时,消息将会被删除或者DLQ(死信队列)
  • REDELIVERED_ACK_TYPE = 3    消息需"重发",比如consumer处理消息时抛出了异常,broker稍后会重新发送此消息
  • INDIVIDUAL_ACK_TYPE = 4    表示只确认"单条消息",无论在任何ACK_MODE下    
  • UNMATCHED_ACK_TYPE = 5    在Topic中,如果一条消息在转发给“订阅者”时,发现此消息不符合Selector过滤条件,那么此消息将 不会转发给订阅者,消息将会被存储引擎删除(相当于在Broker上确认了消息)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏一个会写诗的程序员的博客

RequireJS极简入门教程RequireJS核心功能:HOW TOmain.js使用 shim

随着网站功能逐渐丰富,网页中的js也变得越来越复杂和臃肿,原有通过script标签来导入一个个的js文件这种方式已经不能满足现在互联网开发模式,我们需要团队协作...

1093
来自专栏我和PYTHON有个约会

爬虫 0030~ requests利刃出鞘

requests第三方封装的模块,通过简化请求和响应数据的处理,简化繁琐的开发步骤和处理逻辑、统一不同请求的编码风格以及高效的数据处理特性等而风靡于爬虫市场。

931
来自专栏后端技术探索

爬虫、代理和Nginx

做过爬虫的人应该都知道,抓的网站和数据多了,如果爬虫抓取速度过快,免不了触发网站的防爬机制,几乎用的同一招就是封IP。解决方案有2个:

2602
来自专栏帘卷西风的专栏

linux的一些运维指令和技巧

转载请注明出处:帘卷西风的专栏(http://blog.csdn.net/ljxfblog)

800
来自专栏小狼的世界

PHP文件上传中的安全问题

在使用PHP进行开发时,经常遇到文件上传的场景。其中会隐藏很多我们平时注意不到的安全问题,我总结了一下,主要有几个方面:

1152
来自专栏别先生

使用shell脚本定时采集日志数据到hdfs分布式文件系统

6077
来自专栏人人都是极客

进程、线程之间的爱恨纠葛...

当一个程序开始执行后,在开始执行到执行完毕退出这段时间内,它在内存中的部分就叫称作一个进程。

1653
来自专栏木子昭的博客

Markdown批量发布到Github

1413
来自专栏决胜机器学习

优化页面访问速度(三) ——服务端优化

服务端的优化,主要可以通过消息队列、减少数据库请求(缓存)、并发处理、页面静态化等方式处理。

1042
来自专栏python3

python爬虫--调用百度翻译进行文本翻译

点网络,会发现很多GET,POST请求,右边消息头那里会有很多信息:请求地址、请求方法、远程地址、状态码、server、等等之类的信息

1511

扫码关注云+社区

领取腾讯云代金券