消息的可靠性

1、消息丢失   

        1）消息发送出去，由于网络问题没有抵达服务器

                *做好容错方法（try-catch），发送消息可能会网课失败，失败后要有重试机制，可记录到数据库。采用定期扫描重发的方式

                *做好日志记录，每个消息状态是否都被服务器收到都应该记录

                *做好定期重发。如果消息没有发送成功，定期去数据扫描未成功的消息进行重发

        

 //发送给MQ一个
            try{
                //TODO 保证消息一定会发送出去，没一个消息都可以做好日志记录（给数据库保持没一个消息的详细信息）。
                //TODO 定期扫描数据库将失败的消息再发送一遍。
                rabbitTemplate.convertAndSend("order-event-exchange","order.release.other",orderTo);
            }catch (Exception e){
                //TODO 将没发送成功的消息进行重试发送。
            }

        2）消息抵达Broker(代理服务器),Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成。宕机

        publisher也必须加入确认回调机制。确认成功的消息。修改数据库信息状态

 

 3）自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机

        一定开启手动ACK,消费成功才移除。失败或者没来的级处理就noACK重新入队

2、消息重复  ----接口幂等性解决 

        消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息 重新由unack变为ready，并发送给其他消费者

        消息消费失败，由于重试机制，自动又将消息发送出去
        成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送

                消费者的业务消费接口应该设计为幂等性的。比如扣库存有 工作单的状态标志
                使用防重表（redis/mysql），发送消息每一个都有业务的唯 一标识，处理过就不用处理                 rabbitMQ的每一个消息都有redelivered字段，可以获取是否 是被重新投递过来的，而不是第一次投递过来的 

3、消息积压

        1）消费者宕机积压

        2）消费者能力不足积压（消费者宕机，消费者变少了）

        3）发送者发送流量太大

                解决：

                上线更多的消费者，进行正常消费

                上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理