31-尚硅谷-支付宝支付-支付成功异步通知-处理重复通知

在刚才的这段业务描述当中呢，我们发现其实还有这样一句话，就是正确的进行不同的业务处理，并且过滤重复的通知结果数据，那么为什么要过滤重复的通知结果数据呢？也就意味着我们这个通知呢有可能重复，那通知为什么重复呢？在上面的服务器异步通知页面特性当中呢，这里面提到。程序执行完成后，必须打印出success，如果商户反馈给支付宝的字符不是success这七个字符，那么支付宝会不断的重发通知，直到超过24小时22分钟，一般情况下25小时以内完成八次通知，通知的间隔频率一般是四分钟，十分钟啊，一小时两小时等等啊，这样的话呢，也就是说明我们的支付宝，比如说这面呢，是我们的支付宝端，然后这面呢是我们的业务服务器端，我们的支付宝端呢，会给业务服务器呢去发送这个结果通知，而我们的业务服务器呢，会给支付宝端呢去反馈一个success，对不对啊，就是这个success，那四分钟之内支付宝端没有收到我们的业务服务器的这个通知，反馈的话呢，那么支付宝呢，就会重复的给我们的业务服务器呢，去发送这个通知，但是假设说我们的业务服务器。

已经给支付宝发送了这个通知反馈，但是由于某些情况下网络原因哈，我们的业务服务器呢，没有成功的将这个通知反馈。传递到支付宝这一端，或者是支付宝这一端呢，他没有成功的接收到我们的这个通知反馈，那么支付宝就会重复的发送这个通知，但是我们刚才说到了，并不是我们没有正确的处理这个通知，也就是说我们的支付状态也改变了，支付日志也记录了，但是呢，我们的这个反馈没有成功的发送啊，所以呢，支付宝呢，就又一次发送了通知，那支付宝如果又一次发送了通知的话，那么你会发现我们的支付日志呢，就会。

记录第二次，我们的支付状态呢，就会修改第二次，那么支付状态修改第二次呢，对我们的应用程序呢，不会产生任何影响，但是呢，支付日志记录了两次的话呢，我们的应用程序当中呢，就会有多条支付日志记录下来，那么这个和我们的实际的支付情况就不一样了，因为我们支付了一次，他很有可能记录了两次甚至更多次的支付日志，对不对？所以呢，我们就需要去解决啊这个重复通知的问题啊，需要去过滤这个重复的通知。那么在我们业务的服务器没有成功的接收到这个支付宝的通知的情况下，我们才希望支付宝给我们发送重复的通知，但是我们已经成功的接收到了这个回调通知，只是我们没有成功的反馈消息的时候，其实我们知不希望接收到这个重复的通知的，那接下来我们来看一下如何去过滤这个重复的通知，我们在我们的应用程序当中找到我们处理订单process order这个方法，那么在更新订单状态和记录支付日志之前，我们来处理重复的通知好。

不论。接口位调用多少次啊，以下有指执行一次啊，避免我们重复的进行这个订单状态的更新和支付日志的记录，那么这个无论接口被调多少次，业务只执行一次，这个呢，其实我们管它叫接口调用的B等。

性是吧，之前在微信支付的过程当中，我们也提到过这个概念，好我们之前在微信支付的过程当中呢，曾经写过一个方法叫order info service，第2GET order status，把order member传进去，我们对order status呢进行一个判断，如果这个order status哈，它有一个状态叫no啊。要get paid，好，我们跟这个no pay进行比较好，我们获取出来的这个order thes，如果它不等于no pay，也就是说它不等于未支付，什么叫不等于未支付，只有未支付的情况下，我们才进行更新订单状态和支付日志的这样的一个记录，那么如果他不是未支付，那除了未支付还有什么，比如说支付成功呀，比如说超时已关闭呀，比如说用户已取消啊，比如说退款中啊，啊，如果是这些状态的话，包括已退款哈，好，那么呢，我们呢，就不再重新的去更新订单状态，进入支付日志了，只有在未支付的时候，我们才做下面的这些工作，所以如果他不等未支付，那么我们就直接退出，好，这个呢，就是我们处理重复通知的这样的一个过程。