【不靠谱程序员】接收到回调通知的异步处理
支付系统中，像资金下发这种业务，通常是在我们系统发给第三方支付通道后，第三方支付通道会进行资金业务处理。然后，付款完成后，会主动发起回调，即，调用我们系统API，将付款结果通知给我们系统。假定我们的支付系统对三方通道回调通知的处理逻辑包括：① 修改本地付款单的付款状态；② 将付款结果调用商户系统API，通知给商户。见下方示意图。用伪代码来表示，大概是下面这样子：
public void payNotify(Order order) {
// ① 修改付款单状态
orderRepository.updatePayResult(order.getId(), "PAY_SUCCESS");
// ② 将付款结果调用商户系统API，通知商户
Merchant merchant = merchantRepository.getById(order.getMerId());
String reqMsg = encrypt("orderNo="+order.getOrderId()+"&state=PAY_SUCCESS");
HttpClient.sendPost(merchant.getNotifyUrl(), reqMsg);
}
为了提高程序性能，开发人使用了异步线程，出现了下面的不靠谱代码：
public void payNotify(Order order) {
// ① 修改付款单状态
new Thread(()->{
orderRepository.updatePayResult(order.getId(), "PAY_SUCCESS");
}).start();
// ② 将付款结果调用商户系统API，通知商户
new Thread(()->{
Merchant merchant = merchantRepository.getById(order.getMerId());
String reqMsg = encrypt("orderNo="+order.getOrderId()+"&state=PAY_SUCCESS");
HttpClient.sendPost(merchant.getNotifyUrl(), reqMsg);
}).start();
}
结果呢，出现了一种情况，当前系统里订单的付款状态没能修改，可是通知商户却成功了。。
我们作为支付服务提供方，我们系统里的付款单不是终态，而商户系统里却是终态。在支付系统中，这样的程序是很要命的。尤其是当我们系统里的付款单是“付款中”而商户系统里是“付款失败”的情况。这时，商户系统可能会因为付款失败而重新发起付款。如果原单实际是付款成功的话，这就出现了资金风险，即，一笔订单付款了两次。就问你怕不怕？
所以，本案中，修改付款单状态的逻辑，必须在主线程执行，确保当前支付系统的付款单状态变更完成后，才可以做后续业务处理。通知商户则可以异步处理，即使通知失败也可以用相关方式来补偿。
这个案例告诉我们，代码中在使用JUC、消息队列、回调函数、消息中间件等提高程序性能的方式进行异步处理时，一定要分清主次，哪些逻辑必须在主线程执行，哪些逻辑可以异步处理。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ 喜欢鼓捣这些软件，现在用得少，谢谢分享！ 感谢，下载保存了 感谢发布原创作品，程序园因你更精彩 感谢分享，下载保存了，貌似很强大 这个有用。 用心讨论，共获提升！ 用心讨论，共获提升！ 很好很强大我过来先占个楼 待编辑 这个有用。 这个有用。 前排留名，哈哈哈 感谢，下载保存了 鼓励转贴优秀软件安全工具和文档！ 谢谢分享，试用一下 谢谢分享，试用一下 不错，里面软件多更新就更好了 东西不错很实用谢谢分享 这个有用。 感谢，下载保存了
页:
[1]
2