第三方支付平台提现原子性问题解决方案原子性

在业务逻辑中，经常会碰到提现需求。提现的实现一般分为两个步骤：

扣除余额
调用第三方支付接口进行提现（比如微信支付：企业付款到零钱）

假设我们这样写(伪代码):

money -= $withdrawMoney; $member->save(); $wechat->payment->pay($openid, $withdrawMoney); DB::commit(); } catch (\Exception $e) { DB::rollback(); Log::error($e->getMessage()); }

这样写会有什么问题？当执行commit的时候，由于网络原因，数据库突然连不上了或者数据库挂了，怎么办？会导致什么后果？
会导致钱付出去了，但是余额没扣。

还有同学可能会有其它疑问，如果数据库操作成功，接口调用因为网络原因失败了，会怎么样？就我们上面这段代码而言，如果接口调用失败，并且调用失败后会抛出异常的话，那就会被catch到，try里面甚至都走不到commit，直接rollback了。所以接口调用失败时，不会有原子性问题。

怎么样保证提现操作是原子性的，要么扣余额和调接口同时成功，要么同时失败？
把调微信接口的操作，转化成一个异步任务。

payment->pay($openid, $money); if ($result->return_msg == 'SUCCESS') { return true; }return false; } }

money -= $withdrawMoney; $member->save(); $task = new Task; $task->callback = json_encode([WechatWithdrawJob::class, 'withdraw']); $task->params = json_encode([$openid, $withdrawMoney]); $task->add_time = time(); $task->save(); DB::commit(); } catch (\Exception $e) { DB::rollback(); Log::error($e->getMessage()); }

起一个异步任务消费进程，不停地轮询消费。

where('retries', '<', self::MAX_RETRIES)->get(); foreach ($tasks as $task) { if ($task->retries == self::MAX_RETRIES - 1) { //notify administrator} $callback = json_decode($task->callback, true); $params = json_decode($task->params, true); if ($result = call_user_func_array($callback, $params)) { $task->finish_time = time(); } else { $task->retries += 1; }$task->save(); }

这样就把分布式的事务转化成了本地事务，保证了提现的原子性。
除了提现，这种编程方法还可以用在所有需要调用外部接口的业务上，保证业务的原子性。
【第三方支付平台提现原子性问题解决方案】基于这种方法，还有一些优化的思路。

如果异步任务比较多，有些任务可能会比较耗时，有必要多起几个消费者进程，每个进程负责不同类型的异步任务。
也可以参照GO的GPM模型，给异步任务加个type，不同进程消费不同的type，未完成的同一个type的任务量设置一个上限，比如说100。达到上限后，再入库的异步任务就把type设置成global，type为global时，任意一个消费者进程都可以消费。消费type为global的任务时，记得加个分布式锁，避免并发问题。