2014-01-07 37 views
0

我有一個應用程序,允許人們對足球比賽的結果進行賭注。 每個單注(=實體)的得分是通過比較下注的投注得分和遊戲中的實際結果(=實體)來計算的。賭注在Betrounds內下注。有條件的組織是團體在遊戲組中進行投注的組織(例如單組比賽)。單個用戶組可以有幾個betrounds。如何緩存複雜的計算的臨時數據

總結關係模型: 用戶組1:N BetRounds 1:N投注N:1個遊戲

在我創建了一個resulttable,我展示他們的結果分和位置每個用戶每個betround。 爲了計算一個用戶的位置,我需要計算每個用戶在一個回合內的點數。 這些來自單一的betrounds的點被聚合成組,並且在組內還有一個結果表。

  • 一個用戶組的用:20個用戶
  • 一個季節有34個比賽日
  • 一個比賽日有9個遊戲

爲了計算這個點usergroup我需要計算從20 * 34 * 9 = 6120賭注點。

由於這是很多計算,我不想每次都顯示結果表。 我目前看到爲了節省一些計算時間兩個選項:

  1. 緩存
  2. 保存中間結果(例如對賭實體)在數據庫
  3. 也許兩者的混合。
  1. 緩存

如果緩存是正確的做法我不知道哪個級別以及如何失效。 有幾個選項需要緩存的內容: - 一個betround的整個結果表(分&位置) - - 用戶組 內單個用戶的pointresult - 全resulttable一個betround 內的單個用戶的pointresults - 單項投注 的pointresult用戶組

我不確定如何緩存這些數據: - 只爲位置的整數值和點 - 整個實體(例如投注) - 暫時不持久的實體(例如代表的resulttables) - 在html表格的輸出

然後依賴格式如何緩存它: - html視圖可以通過反向代理緩存 - 值/實體可能通過redis/memcache等。

在未來,我們可能會更改爲單頁應用程序,數據只通過restapi提供,然後緩存html輸出不是一種選擇。

取決於緩存策略,問題出現在如何使緩存失效並有選擇地加熱緩存,以便結果永遠不會在應用程序內計算,而只會在緩存失效並立即被新結果替換時重新計算。

我已經經常閱讀緩存失效是邪惡的。我不確定這是否適用於我的用例,因爲所有的積分/結果/表格等僅在我的界面更新遊戲結果時發生變化。這是積分變化的唯一時間。在數據庫

2.Save中期業績(例如對賭實體)我不知道,如果這種情況適用於所有級別。我首先想到的是將實際結果保存在下注中,而不是總是將投注分數與實際分數進行比較。這將使我的數據模型有點重複,如果我的界面獲取了錯誤的結果,並且後來正確進來並且我的點沒有重新計算,我就增加了複雜性。

在所有其他級別上,我需要創建新的臨時實體來永久存儲表結果。

兩個

3.Mix我不知道如何混合兩種會是什麼樣子,如果它是有道理的,但是我認爲它可能是一種選擇。

任何意見,輸入或經驗將不勝感激。

回答

1

我只是輕度理解博彩,所以希望這有助於。

這聽起來像你問兩個問題:

  1. 當我計算的結果嗎?
  2. 我應該使用多少緩存?

對我來說,這聽起來像是有非常明確的事件發生,之後你可以成功計算出你的結果。你的設計應該利用這一點,並在本質上是平衡的。你應該擁有能夠檢測遊戲完成的後臺進程。應該寫下游戲的結果,並且應該觸發額外的背景作業來計算依賴於該遊戲的任何投注的結果。

這也將成爲任何涉及該遊戲的緩存,該遊戲的結果或該遊戲的任何投注的結果應該失效和/或刷新的點。

你應該緩存多少應該根據你需要緩存多少。緩存應該與計算結果分開考慮。這不是緩存。這是計算結果並存儲它們。在頁面查看請求期間,您絕對不應該計算結果,並且應該在相應事件(遊戲結束)觸發計算時提前完成。

你的數據庫幾乎總是代表你擁有的最新信息。如果可能的話,你應該避免做任何計算。

我會先獲取所有事件和背景,然後看看你得到了什麼樣的表現。在那時,你的應用程序應該做的不過是將結果放到每個頁面視圖的視圖中。如果那部分速度太慢,那麼你應該開始尋找緩存views/templates/html。如前所述,當您的後臺工作人員遇到新的結果時,這些緩存可能會失效。

+0

嗨,所以對我來說,這意味着如果底層遊戲發生變化,則可以將該betpoint結果保存在數據庫中並更新該值。所有的表不應該被存儲,但只有輸出應該被緩存(所以只有局部視圖,而不是原始數據,然後重新渲染)。這意味着我可以使用像https://github.com/asm89/twig-cache-extension這樣的東西,或者使用包含邊緣的Varnish。不幸的是,我的雲提供商尚未提供清漆。所以,我可能會用小枝博客緩存。 – m0c