这是一个创建于 1254 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前我们有一个充电桩的项目, 用户存在账户余额体系, 充电是按照每分钟按照电量或者功率计费, 一个用户同时存在多个订单,目前的设计是在用户有订单的情况下,就会在 redis 中创建一个当前账户的缓存,如果存在多个订单,扣费都扣减这个共享的缓存账户, 另外正在进行中的订单也会存在一份 redis 缓存, 用来累计金额,电量等信息,在订单结束后同步相关信息到数据库中, 因为每天同时进行中的订单有好几万,历史订单千万级别, 所以没有使用每次更新数据库的设计, 所有数据都保存在缓存中有时候会出现数据不一致的情况,不知道各位大佬对这种场景有没有好的建议或者方案
 |
1
thunderw 2021-06-18 15:14:07 +08:00
交易信息存缓存里不落地，心有点大啊……
你这个不一致是不是并发造成的？比如大家都读了数据加 1，最后只加了一次 1. |
 |
2
suuln 2021-06-18 15:54:02 +08:00
可以参考一下热点账户
|
 |
3
liprais 2021-06-18 15:59:27 +08:00
用户的余额应该永远是算出来的
玩钱的用 redis 胆子真大 |
 |
4
zaczhou OP |
 |
5
xiangyuecn 2021-06-18 16:36:53 +08:00
1 万单同时充 1 小时，数据库绝逼不会成为瓶颈，提前优化又可以多搞好多钱🐶🐶🐶
|
 |
6
pjntt 2021-06-19 11:44:49 +08:00
一点想法供参考：
最小单位生成扣费记录，通过消息队列形成订单记录。订单结束后通过充值总额－消费总额＝当前余额。定时核对／校验充值／扣费记录，生成差异记录。 |
|
7
zaczhou OP @pjntt 这样也是可以 但是这里面还有一个问题 就是如果不是每次上报充电信息的时候去检查余额 就不知道他的余额是否能够完成下一分钟的充电，因为现在有很多模式 有的是充电前直接扣费，还有的是按照每一分钟进行扣钱
|
|
9
pjntt 2021-06-20 13:09:07 +08:00
从纯技术角度说，扣费失败就中断充电操作，只要保证在最小单位时间内要把产生的扣费记录全处理掉。是否支持下一分钟扣费这个说法也就不存在的。
实际应用操作上，这个处理时间会受种因素影响到，没有时候办法在最小单位内处理掉所有扣费记录，那么就会产负值费用。那么这个就需要增加额外的保障措施。比如增加足够计算冗余，增加负值告警、括帐户余额最小可使用值等等手段提前预警。 |
Select Language