目录

一、待优化场景

二、初步优化方案

三、继续优化方案

四、死信

专栏链接：IT老齐架构300讲笔记专栏

一、待优化场景

每天上午10点，全国2万多名客户经理集中录入上一日JK单据到BorrowSale系统，峰值能达到500单/s。但信审系统任务重，最多只支持到60单/s，每日会导致大量消息积压

二、初步优化方案

最简单办法：RabbitMQ改为工作队列模式，将消息送给9个信审系统实例并行完成。但信审系统不愿配合，以预算不足为由拒绝，作为BS前台就得自己想办法解决消息积压问题

三、继续优化方案

 BS前台解决办法：依赖RabbitMQ的“死信队列”特性，将死信消息自动送达死信队列中，BS前台接收到死信消息，1小时后重新发送，等待闲时由信审系统进行处理。这样便实现了在不增加资源的前提下，对信审系统资源进行“削峰填谷”。

四、死信

即过期或无法处理的消息

死信是怎么产生的

消费者拒绝接受，且没有重新入列的消息

队列满了，无法入列的消息

消息设置了TTL过期时间，超过有效时间后的消息

队列设置了TTL过期时间，超过有效时间后的消息