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