微信提现流程图

本文分享了一次微信提现功能的设计过程,包括用户发起提现、校验、余额操作、数据库乐观锁等环节,并提出了可能的优化点和并发处理策略。在流程中,对可能出现的异常情况进行了考虑,如余额不足、脏读预防、多线程更新问题。同时,作者对事务设计和异常处理提出了疑问,期待业界同行的讨论和建议,以提升提现流程的安全性和效率。
摘要由CSDN通过智能技术生成

第一次在项目中遇到需要做一个微信提现功能.做了一个简单设计图,不知道能不能满足大部分业务场景.贴出来希望和大家一起讨论讨论.继续优化.

这里不牵扯提现的前期准备.比如企业账户,公众号,用户绑定等.

简单对整个流程图做一个文字说明:

1,用户发起提现申请  这里没有什么可以说的.无非就是输入提现金额之类的操作.

2,做一些校验,主要校验用户余额是否满足提现的要求.

3,余额都不足就不要提现了撒   (想P呢..)

4,如果有钱的话,就直接进入提现的下一个流程,对用户的金额进行加减,记录明细等

5,这里重新获取一次用户余额,主要想法就是万一脏读了呢.(其实后面的乐观锁也能避免这种情况),但感觉再读一次数据,会减少乐观锁更新失败的几率

6,想的是先提前扣除用户金额.免得提现之间有其他操作.导致最后金额不正确

7,数据库做了一个乐观锁,尝试几次更新后直接抛异常.也是防止多线程更新数据

8,生成提现明细记录

9,调用微信支付api完成支付

10,微信接口如果返回状态不是明确表示成功或失败.还需要再重新调用微信支付查询接口api查询订单支付状态

11,调用微信支付查询接口返回是成功支付,则更新明细记录状态为完成

12,调用微信支付接口直接返回成功支付的话,也可以直接更新明细记录状态为完成

13,如果微信支付接口或查询接口都标识支付失败,修改微信明细状态为失败

 

补充想法: 

1,在步骤13的时候,大家会发现步骤6扣除了用户金额.这里有本来想添加一个步骤,就是将用户多余扣除的金额再补回去.但又觉得,这种特殊情况应该人工介入来处理了.不知道大家如何看待.

2,这个里面只把步骤6和步骤8放在一个事物里面.我的想法是,这个流程还是很长的.如果都在一个事物里面是不是性能不会太好呢.这里有没有大佬出来讲解一下改如何设计才正确呢.

 

 

最后: 这个设计方法也肯定有很多不足,如果大家有什么建议欢迎留言讨论.   希望能做出一个又安全有高效的提现流程.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值