检查实际的业务端代码

再看我们业务系统消费端代码消费端各种不规范写法都有以下例举几个典型1、手动签收有ACK但是没有try-catch-finally结构消费端业务代码如下2、有try-catch-finally结构但是deliverTag是一个固定值0一样的会出问题。3、自动签收确认的大量消息的时候容易搞死消费端应用。6、总结生产环境不建议使用自动ack模式这样会使QOS无法生效。在使用手动ack的时候需要非常注意消息签收业务代码使用try-catch-finally处理结构防止业务代码异常时无法签收。规范约束mq客户端代码正确的使用Rabbitmq配置。不同业务项目设置不同的vhost可以隔离一些影响提升rabbitmq资源使用。考虑设置dead-letter-exchange当设置了requeuefalse时可以放入dead-letter-exchange可以快速排查定位问题。Exchange和队列的最大长度限制可以是限制消息的数量参数x-max-length或者是消息的总字节数总字节数表示的是所有的消息体的字节数忽略消息的属性和任何头部信息又或者两者都进行了限制两者取小值生效只有处于ready状态的消息被计数未被确认的消息不会被计数受到limit的限制。最大队列设置可以限制生产端但会造成消息丢失风险最大消息数量限制不能完全解决队列阻塞问题。尽量使用Direct-exchangeDirect 类型的 Exchange 投递消息是最快的。Direct处理路由键需要将一个队列绑定到交换机上要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键为“A”则只有路由键为“A”的消息才被转发不会转发路由键为B只会转发路由键为“A”Topic将路由键和某模式进行匹配。此时队列需要绑定要一个模式上。符号“#”匹配一个或多个词符号“*”只能匹配一个词Fanout不处理路由键。只需要简单的将队列绑定到交换机上。一个发送到该类型交换机的消息都会被广播到与该交换机绑定的所有队列上Headers不处理路由键而是根据发送的消息内容中的 headers 属性进行匹配。在绑定 Queue 与 Exchange 时指定一组键值对当消息发送到 RabbitMQ 时会取到该消息的 headers 与 Exchange 绑定时指定的键值对进行匹配如果完全匹配则消息会路由到该队列否则不会路由到该队列。