场景:
用户可以使用账户积分进行 “支付消费”，每一积分等于一元RMB。
当消费的积分不足时，可以通过额外支付金额 ➕上积分进行支付。
例如 一件衣服需要 100块，可以使用50积分+50RMB混合支付进行消费。
问题1:
由于支付是异步操作并回调到业务系统的，所以 使用第三方支付过程中，原来的账户积分已经发生变化了。
就以前面例子来说在 在进行支付过程中，有可能因为其他业务导致 原来的50积分扣掉为10积分，那这样支付完毕以后，必然是积分不足无法完成扣费操作。
解决方法:
讲用户积分进行锁定，并且锁定10分钟后如果无法进行消费操作，则自动解锁(这里可以考虑使用redis的存活时间进行实现)。锁定了10积分以后，其他业务功能再进行相关的消费操作前，就判断得到积分不足从而终止用户消费操作。待 第三方支付成功以后，会将锁定积分 + 支付金额继续事务操作。
问题2:
业务系统有可能经常更新，并且支付系统有可能不是独立运行。
换句话说支付系统有可能因为其他功能更新而更新，从而会有一段时间无法提供服务。
例如 已经发起支付，50积分被锁定时，服务器碰巧正在更新，并且10分钟后才回复正常服务，
10分钟后锁定积分被解锁。
用户在10分钟以内就完成了支付操作，并且第三方尝试回调给业务系统，发现业务系统一直处于更新状态，直到10分钟过后业务系统恢复正常运作。此时由于50积分被解锁了，有可能会出现50积分余额不足的情况。
解决方法:
在更新系统之前一段时间，例如半小时动态设定一个 关闭支付 状态，所有准备发起的支付都会被拒绝，可能提示为“系统维护中，暂时无法提供支付操作”之类的内容。在 关闭支付 以后，就可以开始更新系统了。
注意:关闭支付功能一定是要能动态设置而不需要更新系统，所以在支付上线之前就应该有这个机制了。
问题3:
鉴于问题2的解决方法，如果忘记 关闭支付 功能，那应该怎么处理呢?
解决方法:
待续
网友评论