关于一个扣费设计问题,请教一下 v 站的各位大佬

[zaczhou]

目前我们有一个充电桩的项目, 用户存在账户余额体系, 充电是按照每分钟按照电量或者功率计费, 一个用户同时存在多个订单,目前的设计是在用户有订单的情况下,就会在 redis 中创建一个当前账户的缓存,如果存在多个订单,扣费都扣减这个共享的缓存账户, 另外正在进行中的订单也会存在一份 redis 缓存, 用来累计金额,电量等信息,在订单结束后同步相关信息到数据库中, 因为每天同时进行中的订单有好几万,历史订单千万级别, 所以没有使用每次更新数据库的设计, 所有数据都保存在缓存中有时候会出现数据不一致的情况,不知道各位大佬对这种场景有没有好的建议或者方案

[thunderw]

交易信息存缓存里不落地，心有点大啊……
你这个不一致是不是并发造成的？比如大家都读了数据加 1，最后只加了一次 1.

[suuln]

可以参考一下热点账户

[liprais]

用户的余额应该永远是算出来的
玩钱的用 redis 胆子真大

[zaczhou]

@thunderw 是的 @suuln 看了一下 确实在这个场景下 热点账户这个方案确实蛮好的 很感谢 @liprais 是的 之前的设计很心大 还好没有出现太大的问题 目前也是在解决🤣

[xiangyuecn]

1 万单同时充 1 小时，数据库绝逼不会成为瓶颈，提前优化又可以多搞好多钱🐶🐶🐶

[pjntt]

一点想法供参考：

最小单位生成扣费记录，通过消息队列形成订单记录。订单结束后通过充值总额－消费总额＝当前余额。定时核对／校验充值／扣费记录，生成差异记录。

[zaczhou]

@pjntt 这样也是可以 但是这里面还有一个问题 就是如果不是每次上报充电信息的时候去检查余额 就不知道他的余额是否能够完成下一分钟的充电，因为现在有很多模式 有的是充电前直接扣费，还有的是按照每一分钟进行扣钱

[zaczhou]

@pjntt 很感谢你提供的思路 不知道你对余额是否支持下一分钟的扣费这个问题怎么看呢

[pjntt]

从纯技术角度说，扣费失败就中断充电操作，只要保证在最小单位时间内要把产生的扣费记录全处理掉。是否支持下一分钟扣费这个说法也就不存在的。

实际应用操作上，这个处理时间会受种因素影响到，没有时候办法在最小单位内处理掉所有扣费记录，那么就会产负值费用。那么这个就需要增加额外的保障措施。比如增加足够计算冗余，增加负值告警、括帐户余额最小可使用值等等手段提前预警。