項目說明
競猜業務邏輯很簡單、普遍用於各種賽事中、籃球賽、足球賽、包括最近興起的遊戲電競賽事，對於社區產品來說；競猜無疑是一個很好的潤滑劑，可以更好地凝聚用戶；
核心邏輯說明
用戶下注邏輯
賽事爲多個隊伍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