顺着 @
sujin190 的思路,我捋捋
简化的思路,设计两张表,具体做不做 sharding 这里且不讨论
表 1:user_balance ( uid, balance )
表 2:user_transaction (uid, amount , type, create_time)
假定业务接受 T+1 结算余额,那么意味着每日零点会对历史流水做一个汇总计算,汇总结果写入 user_balance 表字段 balance 。
user_balance 表 balance 字段存的是截止至今日的余额,那么意味着今日的支出无论如何都不能大于 balance (用户只能使用当日 0 点以前的余额,接受 T+1 意味着当日一切进账皆被冻结)
接下来收入和支出具体逻辑就是这样的:
收入:
1 、无脑写表 user_transaction
支出:
1 、检查 balance 是否和支出金额相匹配,支出金额不能超过 balance ;
2 、如果支出金额没有超过 balance ,则原子扣减 balance ,扣减后 balance 如果是大于等于 0 ,则写支出流水,以上,扣减和写流水再同一个事务里;
简化思路是这样,但是如果遇到大并发量如何考虑优化方向?
1 、首先支持事务性高性能的 db ,可以首先排除 mysql ,有条件可以往分布式数据库方向选型;
2 、条件有限,考虑将 balance 抽离到 redis ?事务性如何保障?这些细节可以后面考虑