. 消息可靠性. 生产者确认机制 . 消息持久化（默认就是持久化，了解代码） . 消费者消息确认 .. none模式 .. auto模式 . 消费者重试机制.. 本地重试（默认的RejectAndDontRequeueRecoverer策略）基于..的auto模式，发送失败的消息会重新放入队列queue中，导致mq反复处理失败的消息，带来过多的压力。因此通过本地重试的方式，将失败的队列进行retry处理（spring），而不是反复放入队列。 在消费者的application.yml文件中配置启动失败重试开关、以及重复的次数： .. 三个失败策略（RepublishMessageRecoverer实例）在springAMQP中的失败策略有三个，..中是默认的处理方式。对于废弃的消息，如果不希望消息的丢失，可以采用RepublishMessageRecoverer策略。流程图： 消费者中绑定error交换机后（重写失败策略实现），由交换机根据rountingkey（例子中keyD;error）转发到error.queue ...

同步通信与异步通信feign 无法解决的问题假设有一个场景： 客户端发起请求购买商品，此时使用feign的时候，调用链应该如下 客户端 -> 支付服务 -> 订单服务 -> 支付服务 -> 仓储服务 -> 后续服务 -> 支付服务 -> 客户端 可以看到，这条链还是非常长的，而且引发了以下问题： 代码耦合度非常高： 假设在需要加入新的业务需求，那么就需要在支付服务（见下图）中改代码，来一个新需求加一个，非常麻烦。 再来就是业务之间是一个调用一个的链式调用，如果中途有个服务挂了，那么整个项目也就一起挂了。 同步调用非耗时间： 每当有客户发送支付服务的请求，就需要等待订单服务反馈回支付服务后才能继续发送仓储服务的请求，如此反复的把所有业务跑完，非常耗时间。假设回到支付服务再反馈到客户所需时间需要毫秒，也就等于秒中只能处理两个客户，效率非常低。这种接口等待引发的问题甚至导致资源利用率下降，每个接口都需要等待其他业务响应结束才能执行。 资源浪费： 同步调用的时候，调用链中的每个服务都在等待响应，不能释放请求的资源，高并发的场景下会极度的浪费资 ...