匹配系統和擴展它的體系結構

我有一個網站，用戶在網站上選擇一個用於在網站上找到另一個用戶的特定標準，然後網站將您與其他人一起配對，該人也在尋找具有相同標準的人。有一組「未配對」（尚未配對）的用戶，每次有人發出請求配對時，程序都會使用匹配的條件檢查下一個可用的收集用戶，並刪除用戶如果不匹配，則從「未配對」集合中刪除，如果不匹配，則會將用戶添加到「未配對」集合中。匹配系統和擴展它的體系結構

我的問題是，根據以下標準處理這種類型的集合的最佳方式是什麼？

匹配過程是實時的，所以我用像 SignalR的東西來處理實時配對
如果系統被關閉，集合不需要保持因爲將沒有用戶的「搜索」未配對的用戶因爲系統關閉
如果我向外擴展的服務器，並有多個實例，它們都具有能夠從同一個集合
處理併發拔出（不知道我是否需要）如果2個用戶在要求的同時

時，我以爲出現過這個人的一些標準問題：

難道我甚至需要一個數據庫，這一點，因爲用戶正在增加和刪除不斷
如果我確實需要某種存儲，像mongodb會是一個不錯的選擇？爲什麼？
如果我將該集合存儲在內存中，那麼如果我向外擴展，則不會在不同實例中工作，對吧？

來源

2012-07-23 anthonypliu

您將需要處理併發 - 一旦你找到了一個用戶來搭配，你會想鎖定用戶，驗證它仍然是不成對，配對起來，然後解鎖。否則，當你第一次看到他們時，你會冒先找到一個不配對的用戶的危險，當你把他們配對起來時，他們已經被拿走了。
目前尚不清楚配對會出現哪些副作用 - 但似乎您並不在乎過去的現狀（即服務器是否關閉 - 配對無關緊要）。這聽起來像是一個內存操作，爲了記錄/分析的目的，可能會堅持數據庫。
關於不同的實例，如果它在內存中，你仍然可以通過服務器來完成它（地圖/減少公式可以在內存中工作，並且可能有很多其他的）。您還可以構建您的解決方案，以將您的用戶分別存儲在服務器1上的不同服務器A-N上，服務器2上的O-Z上（如果這對您的數據有意義）。您還可以將配對所需的數據減少到最低限度，並且只需一臺服務器即可（只要您想要）就可以輕鬆處理配對，無需在配對之後加載任何配對。

對不起有點通用沒有更多的瞭解您的數據/使用案例

來源

2012-07-23 22:24:37 Prescott

匹配系統和擴展它的體系結構

回答

相關問題