消息队列应⽤场景ActiveMQ消息发送失败的处理⽅案，先收藏！ 核桃杨今天我们来介绍⼀下ActiveMQ消息队列消息发送失败的处理⽅案。
在介绍今天的内容之前，⾸先我们来探讨⼀下为什么要⽤MQ。 企业中系统为什么要⽤消息队列那？其实要从消息中间件的常见使⽤场景来讲，然后结合⾃⾝系统对应的使⽤场景，说明系统中引⼊消息中间件解决了什么问题。 使⽤消息队列MQ,⼤致解决三类问题：
（1）系统解耦
假设你有个系统 A，这个系统 A 会产出⼀个核⼼数据，现在下游有系统 B 和系统 C 需要这个数据。那简单，系统 A 就是直接调⽤系统 B 和系统 C 的接⼝发送数据给他们就好了。 整个过程，如下图所⽰：
但是现在要是来了系统 D、系统 E、系统 F、系统 G，等等，⼗来个其他系统慢慢的都需要这份核⼼数据呢？如下图所⽰：
家用水处理器⼀个⼤规模系统，往往会拆分为⼏⼗个甚⾄上百个⼦系统，每个⼦系统⼜对应 N 多个服务，这些系统与系统之间有着错综复杂的关系⽹络。此时如果你要是采取上⾯那种模式来设计系统架构，那么绝对你负责系统 A 的同学要被烦死了。
造纸助留助滤剂两个问题：
要修改系统之间的调⽤关系，A系统就需要修改代码！
某个下游系统突然宕机了，系统 A 的调⽤代码就会抛异常！
所有，某些场景下，这种架构师绝对不合适的，系统耦合度太严重。因此在上述系统架构中，就可以采⽤ MQ 中间件来实现系统解耦。系统 A 就把⾃⼰的⼀份核⼼数据发到 MQ ⾥，下游哪个系统感兴趣⾃⼰去消费即可，不需要了就取消数据的消费，如下图所⽰： （2）异步调⽤
假设你有⼀个系统调⽤链路，是系统 A 调⽤系统 B，⼀般耗时 20ms；系统 B 调⽤系统 C，⼀般耗时 200ms；系统 C 调⽤系统 D，⼀般耗时 2s，如下图所⽰：
现在最⼤的问题就是：⽤户⼀个请求过来巨慢⽆⽐，因为⾛完⼀个链路，需要耗费 20ms + 200ms +
2000ms（2s） = 2220ms，也就是 2 秒多的时间。但是实际上，链路中的系统 A 调⽤系统 B，系统 B 调⽤系统 C，这两个步骤起来也就 220ms。就因为引⼊了系统 C 调⽤系统 D 这个步骤，导致最终链路执⾏时间是 2 秒多，直接将链路调⽤性能降低了 10 倍，这就是导致链路执⾏过慢的罪魁祸⾸。
那此时我们可以思考⼀下，是不是可以 将系统 D 从链路中抽离出去做成异步调⽤ 呢？其实很多的业务场景是可以允许异步调⽤的。 所以， 最终的解决⽅案就是可以考虑把系统 C 对系统 D 的调⽤抽离出去做成异步化的 ，不要放在链路中同步依次调⽤。这样，实现思路就是系统 A→系统 B→系统 C，直接就耗费 220ms 后直接成功了。然后系统 C 就是发送个消息到 MQ 中间件⾥，由系统 D 消费到消息之后慢慢的异步来执⾏这个耗时 2s 的业务处理。通过这种⽅式直接将核⼼链路的执⾏性能提升了 10 倍。
（3）流量消峰 假设你有⼀个系统，平时正常的时候每秒可能就⼏百个请求，系统部署在 8 核 16G 的机器的上，正常处理都是 ok 的，每秒⼏百请求是可以轻松抗住的。但是如果在⾼峰期⼀下⼦来了每
秒钟⼏千请求，瞬时出现了流量⾼峰，此时你可以搞 10 台机器，抗住每秒⼏千请求的瞬时⾼峰。但是如果瞬时⾼峰每天就那么半个⼩时，半⼩时过后直接就降低为了每秒就⼏百请求，如果你线上部署了很多台机器，那么每台机器就处理每秒⼏⼗个请求就可以了，造成了资源的浪费。
此时我们就可以⽤ MQ 中间件来进⾏流量削峰。所有机器前⾯部署⼀层 MQ，平时每秒⼏百请求⼤家都可以轻松接收消息。 ⼀旦到了瞬时⾼峰期，⼀下涌⼊每秒⼏千的请求，就可以积压在 MQ ⾥⾯，然后那⼀台机器慢慢的处理和消费。等⾼峰期过了，再消费⼀段时间，MQ
⾥积压的数据就消费完毕了。
这个就是很典型的⼀个 MQ 的⽤法， ⽤有限的机器资源承载⾼并发请求 。如果业务场景允许异步削峰，⾼峰期积压⼀些请求在 MQ ⾥，然后⾼峰期过了，后台系统在⼀定时间内消费完毕不再积压的话，
那就很适合⽤这种技术⽅案。
接下来，我们探讨⼀下ActiveMQ消息队列消息发送失败的处理⽅案这个问题与其讨论MQ消息队列消息发送失败的解决⽅案，等同于探讨中间件如何保证消息的⼀致性的问题？怎么保证两个服务器的通信同步更新成功，⽹络不好，造成的数据丢失问题。
解决⽅案：⾸先主动⽅（消息发送⽅）有个预处理的动作，就是发送消息的同时插⼊⼀条数据到数据库的表中， 这条 数据的关键字段：状态的值为 待确认. (可以单独抽离出来⼀个服务器安装数据库，任何主动⽅都是通过数据源连接这个数据库，给数据源⼀个IP地址就可以连接这个数据库)
槐木可以做防腐木吗>发热器然后执⾏⽣产者的业务代码时: ——–>如果失败: 就回滚，捕捉异常，把预处理的这条数据给删除了，数据库就没有数据了，消费⽅就不会有消息执⾏。双⽅数据⼀致。 ——–>如果成功: 修改数据的状态，把 待确认 改为 待发送 ，再把信息发给MQ,
第⼀种情况： 在MQ发送信息到消费⽅有可能导致数据丢失 , 消费⽅⽆法接收信息，那么之前插⼊数据库中那条数据还是处于待发送状态 ，如果数据丢失，消费⽅⽆法接收信息, ⽣产者有个定时任务，会不断去数据库状态为待发送的那条记录, 如果到待发送这条数据就再次把信息发到MQ，因为不会⽆限次数发送，因此如果发送6次均为失败就会转⼈⼯客服 ,⽐如通知客服，客服去排查哪条消息再告诉运维，在排查消费端为什么接收不到，这样就可以保证数据的最终⼀致性。
第⼆种情况： 正常情况下消费⽅如果能接收数据 , 处理完消费⽅就会链接到数据库把待发送那条信息删除，删除成功就说明主动⽅跟消费⽅都执⾏成功。 直接删除，不做逻辑删除，原因：数据量会越来越多。导致服务器的查询速度变慢。
⽅案总结： 缺点：少实时性。只能确保消息的最终⼀致性。
合成皮革
