登录
首页 >  数据库 >  MySQL

一个游戏拨账系统的数据库结算设计

来源:SegmentFault

时间:2023-01-23 16:31:30 206浏览 收藏

来到golang学习网的大家,相信都是编程学习爱好者,希望在这里学习数据库相关编程知识。下面本篇文章就来带大家聊聊《一个游戏拨账系统的数据库结算设计》,介绍一下MySQL、锁、死锁、浮点数、乐观锁,希望对大家的知识积累有所帮助,助力实战开发!

假设现存在一个简单的猜大小游戏,由用户下注大或者小,扣除手续费3%后的钱全部放入奖池中,赢的一方按投注比例平分整个奖池。使用mysql作为数据库,系统精度精确到1位小数。
本文将会讲解其中会出现的业务结算导致的数据问题,以及解决方法。


数据库逻辑设计

系统内应该存在一个用户钱包表,其中指定两条记录为系统收入账户和系统拨出账户。这样可以将投注的时候,对系统账户余额增加操作,和发奖的时候,对系统账户余额的减去操作分离。

可以避免上一期游戏的结算,对下一期游戏的投注发生锁等待的问题。

业务加锁

考虑到高并发的情况下,推荐使用mysql自带的排他锁,不推荐乐观锁,因为乐观锁需要重试机制,而队列结算暂时不考虑。
当一名用户发起投注的时候,检查顺序应该如下

  1. 检查系统游戏开关
  2. (冗余) 查询一次用户余额是否大于这次下注金额
  3. 开启事务
  4. 对系统收入账户加排他锁
  5. 对用户收入账户加排他锁
  6. 检查用户余额是否足够
  7. 对用户进行扣款
  8. 对系统进行收款
  9. 为奖池加入97%的投注额度
  10. 事务提交

这里之所以要冗余检查用户的额度,是否了避免开启事务的消耗,防止恶意攻击消耗系统资源,用来开启无意义事务。

奖池额度的97%这里计算需要保持一位精度,如果用户投注是98,按照计算得到的值应该是95.06,我们应该取95.0而不是95.1,否则你最后存到奖池里面的数就会大于97%,这样系统抽取就不会达到3%,用户少分点没关系,要保证系统一定能分到3%。

简单一句话就是:精度位后都舍弃

发奖过程设计

假设按照投注比例,瓜分出的奖金总数是22.1,A用户的份额是55.5%,A用户拿到12.2655,B用户的份额是45%,B用户拿到9.8345

这种情况下,你会发现,按照舍弃,原则,分别是12.29.8,结果是只发放了22,如果你按照四舍五入原则,才能发放到22.1

那为什么还要坚持舍弃原则呢?因为,假设出一个极端情况,当你碰到A的值是12.05,B的值是9.05,按照舍弃原则,总数的确还是22.1。但是按照四舍五入原则,发放的总值就是22.2了。

结语

在计算机系统内,浮点数的计算本身就是不可靠的,在业务内应该用整形去避免,当设计到百分比操作的时候,请尽量使用舍弃原则,保证不多发。按照舍弃原则,给用户少发0.05这种精度外的值,对业务来说无关紧要。如果超发了,会导致系统内账目混乱,后果将不堪设想。

以上就是《一个游戏拨账系统的数据库结算设计》的详细内容,更多关于mysql的资料请关注golang学习网公众号!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表