宁德市建设银行网站,网站网页设计公司有哪些,小语种建站,小程序开发教程 吾爱破解目录 ★ 工作队列介绍代码演示测试注意点1#xff1a;注意点2#xff1a; ★ 工作队列介绍 工作队列#xff1a; 就是让多个消费者竞争消费同一个消息队列的消息#xff0c;相当于多个消费者共享消息队列。 ▲ RabbitMQ可以让多个消费者竞争消费同一个消息队列
▲ 消息队… 目录 ★ 工作队列介绍代码演示测试注意点1注意点2 ★ 工作队列介绍 工作队列 就是让多个消费者竞争消费同一个消息队列的消息相当于多个消费者共享消息队列。 ▲ RabbitMQ可以让多个消费者竞争消费同一个消息队列
▲ 消息队列默认会将消息“均分”给每个消费者但这样做往往并不合适 因为有的消费者需要更多时间处理一条消息有的消费者只要更少时间即可处理一条消息 如果让它们“均分”这些消息就会造成资源浪费。
▲ 比较理想的做法是“能者多劳”让队列将消息多分给需要更少时间的消费者快 将消息少分给需要更多时间的消费者慢。
▲ 调用Channel的basicQos(int prefetchCount)方法可控制消费者在同一时间点最多能得到的消息数量 ——此时应该采用手动确认。 这个就是上一篇写的采用自动确认策略 注意 channel.basicConsume 的第二个参数 autoAcktrue就是表示自动确认消息已经被消费完成了。就是当消费者接收到消息之后就立马返回一个已经确认消费的消息回去给消息队列。 这样容易出现问题就是消费者这边因为一收到消息就会自动确认消息被消费了并返回已经消费消息的结果回去给消息队列但是可能消费者其实还没有把消息消费掉而消息队列那边又以为消费者已经把消息消费了所以就继续发消息给那个消费者。 而消费者一收到消息又自动确认消费并返回就会导致这个消息队列的消息越来越多然后消费者消费不完。
代码演示
在上一篇的代码基础上修改 200、使用默认 Exchange 实现 P2P 消息 之 消息生产者发送消息 和 消息消费者消费消息
思路 1、创建一个消息生产者和两个消息消费者。 2、生产者发送20条消息 3、消费者01 和 消费者 02 都用 channel.basicQos(3); 设置同一时间点只能获取3条消息来处理只有这3条消息处理完才能再次获取3条消息 4、每个消费者都在消息处理完之后添加 channel.basicAck() 这个方法来手动确认消息成功消费并返回确认成功消费的消息给消息队列。 5、消费者01 每次消费完后先睡眠个1秒再手动确认消息已经消费消费者02不需要当消息消费完成后就马上手动确认。用于看两个消费者的消费情况
代码如图 生产者 Producer 生产者代码不变只是设置发送20条消息
消费者01 Consumer01 经过测试同一时间点每次只能消费3条消息只有这3条消息消费完成并手动确认消费完成后才能再获取3条消息进行消费。如果把手动确认消费的代码注释掉那么这个消费者只能消费到3条消息。最后面有演示 消费者02 Consumer02 多个了睡眠1秒再手动确认消息
测试
生产者发送20条消息消费者01 和 消费者02 每次获取3条消息消息消费并手动确认后才能再获取3条消息进行消费。 然后消费者02 因为每次消费完都睡眠一秒而消费者01没有。 这个睡眠 用来演示消费者01的消息处理速度比消费者02 快的情况。 所以那个消费者消费的快哪个消费者处理的消息就越多 这个就是工作队列 工作队列 就是让多个消费者竞争消费同一个消息队列的消息相当于多个消费者共享消息队列。
注意点1
如图这个 multiple 参数设置为false表示 不对之前未确认的的消息进行批量确认。 可以经过测试无论改成true还是false只要消息队列里面有已消费未确认的消息再次启动这个消费者它还是会对之前已消费未确认的消息进行批量确认。 测试流程 1、首先关闭消费者然后生产者发送20条消息。 现在就是消息队列有20条消息未被消费
2、这时候把确认消费的代码注释掉然后如图成功消费3条消息但是未确认还有17条消息待消费。 3、重新启动消费者01这个时候正确应该是消费剩下的17条消息但是那3条消费未确认的消息应该还在。
但是结果却如图 重启消费者01把自动确认的代码放开multiple 为 false但是最终还是把所有消息消费了包括3条已消费未确认的消息。
所以感觉这个 multiple 为 false 没起作用。 注意点2
注释掉手动确认代码的演示 经过测试同一时间点每次只能消费3条消息只有这3条消息消费完成并手动确认消费完成后才能再获取3条消息进行消费。如果把手动确认消费的代码注释掉那么这个消费者只能消费到3条消息
