消息的消费确认流程中,
任何一个环节均可能会出问题!网络
方法:对于未确认的消息,采用按规则从新投递的方式进行处理。
问题:消息的重复发送会致使业务处理接口出现重复调用的问题。spa
一、被动方应用接收到消息,业务处理完成后应用出问题,消息中间件不知道消息处理结果,会从新投递消息。设计
二、被动方应用接收到消息,业务处理完成后网络出问题,消息中间件收不到消息处理结果,会从新投递消息。中间件
三、被动方应用接收到消息,业务处理时间过长,消息中间件因消息超时未确认,会再次投递消息。接口
四、被动方应用接收到消息,业务处理完成,消息中间件问题致使收不到消息处理结果,消息会从新投递。循环
五、被动方应用接收到消息,业务处理完成,消息中间件收到了消息处理结果,但因为消息存储故障致使消息没能成功确认,消息会再次投递。请求
总结: 消息消费过程当中产生消息重复发送主要是由于消息接收者成功处理完消息后,消息中间件没能及时更新消息投递状态(也就是消息没能及时ACK确认)致使的。方法
约束:被动方应用对于消息的业务处理要实现幂等。im
对于存在同一请求数据会发生重复调用的业务接口,接口的业务逻辑要实现幂等性设计。支付
在实际的业务应用场景中,业务接口的幂等性设计,常结合可查询操做一块儿使用。
场景举例
•支付订单建立:商户编号+ 商户订单号+ 订单状态
•订单更新处理:平台订单号+ 订单状态
•会计系统记帐:系统来源+ 请求号
极端状况:消息重发也得有次数限制,要否则就变成了死循环。
对于超太重发次限制的消息,进入DLQ,等待人工干预或延后按期处理。