消息重复发送问题与业务接口的幂等性设计
消息消费流程的异常点
消息的消费确认流程中，任何一个环节都可能会出问题！
方法：对于未确认的消息，采用按规则重新投递的方式进行处理。
问题：消息的重复发送会导致业务处理接口出现重复调用的问题。
消息重复发送的原因
被动方应用接收到消息，业务处理完成后应用出问题，消息中间件不知道消息处理结果，会重新投递消息。
被动方应用接收到消息，业务处理完成后网络出问题，消息中间件收不到消息处理结果，会重新投递消息。
被动方应用接收到消息，业务处理时间过长，消息中间件因消息超时未确认，会再次投递消息。
被动方应用接收到消息，业务处理完成，消息中间件问题导致收不到消息处理结果，消息会重新投递。
被动方应用接收到消息，业务处理完成，消息中间件收到了消息处理结果，但由于消息存储故障导致消息没能成功确认，消息会再次投递。
总结
消息消费过程中产生消息重复发送主要是因为消息接收者成功处理完消息后，消息中间件没能及时更新消息投递状态（也就是消息没能及时ACK确认）导致的。
约束：被动方应用对于消息的业务处理要实现幂等
业务接口的幂等性设计
对于存在同一请求数据会发生重复调用的业务接口，接口的业务逻辑要实现幂等性设计。 在实际的业务应用场景中，业务接口的幂等性设计，常结合可查询操作一起使用。 场景举例
支付订单创建：商户编号 + 商户订单号 + 订单状态
订单更新处理：平台订单号 + 订单状态
会计系统记账：系统来源 + 请求号
极端情况：消息重发也得有次数限制，要不然就变成了死循环。
对于超过重发次限制的消息，进入DLQ，等待人工干预或延后定期处理
方式
根据业务来实现幂等
增加消息表来实现幂等
————————————————
版权声明：本文为CSDN博主「chenshiying007」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_27384769/article/details/79307340