考虑到用线程或者定时任务，不知道有没有人做过这个

类似的异步处理通知接口基本上都需要做这种处理的，因为异步的回调通知总会因为网络或者处理延时造成没有进行回调通知。
具体的做法就是首先在调用异步接口前，需要先生成一个待处理的订单，然后调用支付宝接口进行支付，支付完成后正常情况支付宝会主动请求你的回调接口，如果没有请求的话，你的订单状态将会保持待处理的状态。
然后再做一个定时任务，每隔一段时间，查询一下待处理的订单，根据支付宝返回的订单状态来更新对应的状态就可以了，需要注意的是控制订单查询的时间，不建议把所有的订单找出来去更新，根据你的数据量来处理，一般的话远程请求支付宝接口同步处理的话也比较耗时，未处理的订单太多了就根本处理不过来，建议的做法是直接把查询请求发送到MQ上，然后根据数据量大小开多个消费者服务，来处理查询请求。
另外还有一种简单粗暴的方式也可以，直接对待处理的订单不做处理，但是给用户提供一个功能，让用户主动发起请求，用户点击重试按钮后直接调用支付宝查询接口查询订单支付状态。

 

订单的几个状态： 待支付，已支付到支付宝，支付宝支付完成。
主要应对的是：已支付到支付宝。
考虑的几个点： 实时性，幂等性

实时性：根据你具体的业务场景，单进程多线程，多进程处理。多进程的话需要分区段处理数据，保证数据的不重复
幂等：每个订单必须有唯一的标识，每个环节处理的时候，保证这个订单已经被处理过了。