消息队列学习

_config.yml
_config.yml
_config.yml
_config.yml
_config.ymlexchange:一个应用对应一个exchange
Routing key:exchange根据routing key的配置,决定将消息路由到哪个队列
_config.yml为了确保消息不会丢失,RabbitMQ支持消息确认机制。客户端在接受到消息并处理完后,可以发送一个ack消息给RabbitMQ,告诉它该消息可以安全的删除了。假如客户端在发送ack之前意外死掉了,那么RabbitMQ会将消息投递到下一个consumer客户端。如果有多个consumer客户端,RabbitMQ在投递消息时是轮询的。
RabbitMQ如何判断客户端死掉了?唯一根据是客户端连接是否断开。这里没有超时机制,也就是说客户端可以处理一个消息很长时间,只要没断开连接,RabbitMQ就一直等待ack消息。
消息确认机制默认是打开的,除非你设置no_ack=True标记来手工关闭它。消息消费者1. 消费者配置并发消费者个数如果消费者对消息的时序不是特别敏感,建议配置合适的并发消费者,增加消费能力,防止只有一个消费者阻塞时造成消息积压。2. 消费者配置每次读取消费个数跟上面的场景类似,配置prefetchCount,决定每次读取消息时,获取消息的个数,可以减少网络的传输次数,提高消费能力,但是会降低消息的时序性。3. 消费者消费消息时不抛出异常如果消费消息时抛出异常,则消息无法正常的ack,会重新放回队列,重新发送此消息,如果还无法消费,会一直重发,相当于死循环状态,影响后续的消息处理和整个MQ server的性能。4. 评估消费能力有一个基本原则是消费能力应该大于生产能力,否则就会造成消息的积压
MQ允许少量的消息积压,消息积压会降低MQserver的性能
大量的消费积压会触发报警,而且大量积压会触发内存流控,影响整个集群消息生产者1. 生产者实现消息发送失败重发应用系统发送时,建议如果出错的话可以存储到本地数据库或文件系统,然后实现定时重发或手动重发。参考文章如何用消息系统避免分布式事务
消息队列设计精要
使用消息队列的 10 个理由我的github博客

相关内容推荐