竞猜系统整体架构设计

项目说明

竞猜业务逻辑很简单、普遍用于各种赛事中、篮球赛、足球赛、包括最近兴起的游戏电竞赛事，对于社区产品来说；竞猜无疑是一个很好的润滑剂，可以更好地凝聚用户；

 

核心逻辑说明

用户下注逻辑

赛事为多个队伍PK，用户可以选择一个队伍进行押注；每个队伍的赔率都会随着用户的下注而改变；

举例：

赛事名称：英雄联盟LPL春季赛EDG对WE

EDG队伍胜利 赔率：1 下注金额：0

WE队伍胜利  赔率：1 下注金额：0

当下注人数较少时，赔率默认为1，不变化；当下注金额变得可计算时，每次下注触发修改下注赔率，如：

EDG队伍胜利 赔率：1.5 下注金额：1000

WE队伍胜利  赔率：3.0 下注金额：500

 

算法为：

A队伍赔率 = （A队伍金额+B队伍金额）/A队伍金额

B队伍赔率 = （A队伍金额+B队伍金额）/B队伍金额

以此类推

EDG队伍赔率 = （1000+500）/ 1000

WE队伍赔率 = （1000+500）/ 500

 

结果揭晓逻辑

结果揭晓为后台管理逻辑，管理人员根据赛事真实结果，揭晓正确选项；揭晓后竞猜成功的用户将会得到下注金额*赔率的货币返还，竞猜失败的用户货币直接吞掉；最后用消息通知赛事揭晓情况；

*揭晓结果时，可以分批处理，成功的分一批、失败的分一批；

*用户可能对多个项进行下注，可能同时收到成功和失败的消息，这是正常的；

 

 

数据结构设计

 

 

赛事信息表：gc_comp

记录赛事的基本信息、标题、起止时间等等

 

参赛队伍表：gc_team

记录了参数队伍的一些信息，队伍信息是可以复用的，可以挂靠在不同的赛事中

 

赛事队伍关联表：gc_comp_team

用于关联赛事和参赛队伍的，主要作用在于前端展示

 

 

竞猜结果项：gc_comp_result

配置竞猜的结果项目，如：A队胜利，B队胜利，AB平手，等等…

为什么这里要增加这个项、主要是为了后期的扩展性，用户竞猜是猜选项，而不是猜队伍；换句话说：队伍只是展现数据，而选项才是真正竞猜结算选项；

*以下teamId可以为空，只是预留项目；也可以去除

 

 

用户的竞猜记录：gc_comp_record

记录了用户每个选项投注的情况。

*一个项只会有一条数据，多次下注结果累加在beans里面

*整个设计缺少详细的下注历史，你们可以自行加上；

 

 

有任何问题或者好的建议，都可以和我聊一天：18365918