计费系统的 金额结算怎么做？

[kikione]

单应用，单数据库

业务是这样的： 用户请求我们 API 查询，先在账户充值金额。

每请求一次 API 会有一次计费，请求成功计费，余额减； 失败不计费； 余额不足请求失败；

余额结算怎么做比较好？业界都是什么方案？

[securityCoding]

请求前检查费用（商户锁） -》请求成功-》消息队列-》扣费

[securityCoding]

没有消息队列可以使用 redis stream

[moult]

请求 API 肯定有写记录吧。根据请求记录表，十分钟或一小时统一扣费一次。云服务那些按量计费很多都是一小时甚至一天计费在。实时扣费的话真的太浪费资源了。

[kikione]

@moult 谢谢

[kikione]

@securityCoding 谢谢

[wangbenjun5]

像这种单应用单数据库太简单了，一个锁就解决了并发问题，保证 1 毛钱不亏

[wangbenjun5]

当然如果考虑到锁的性能影响接口速度的话就不要使用数据库锁，可以使用内存锁，redis 锁。如果使用队列做成异步模式的话可能会导致超额，假设并发量大的话。

[kikione]

@wangbenjun5 给数据库加一个 乐观锁就可了是吧

[kingwrcy]

金额弄成 可用余额 ,冻结金额.

余额是否足够判断,用 可用金额 来判断.

每一次调用 api,冻结金额 增加,可用金额 减少.
调用 api 成功,冻结金额 减少,可用金额 不变.
调用 api 失败,冻结金额 减少,可用金额 增加.

然后按天对账,及时发现有问题的数据.

另外变更金额一定得用乐观锁.

[Dabaicong]

如果实时计费，最好是悲观锁。select for update 。记得 where 条件中要有索引，要不然就会退化成表锁

[brucefu]

如何定义“请求一次”，为请求一次做一个唯一键，异步插表就好，要保成功。将来计费系统单独出去的话，就发消息出去

[dengkj]

MySQL RR RC 级别的话不用显式加锁，只需要判断用户余额是否大于等于零即可，数据库会自动加锁

[kikione]

@dengkj 感谢