项目说明

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

核心逻辑说明

用户下注逻辑

赛事为多个队伍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