專案回憶一虛擬房間系統

需求：

1.硬體環境:所有伺服器都是web容器，有統一的快取memcached，由於一些原因，不允許用**控**務器

2.實現乙個虛擬房間系統，即包括房間內的資料可見並共享（資料競爭性），房間有超時檢測，房間外部還有乙個統一排程（即不是自由進入房間，由系統分派），房間有人數限制，也要求人數多的盡快分配滿，人數少的盡快清空

實現思路

開始是乙個很簡單的思考模式：

超時檢測與房間排程必然是兩個服務，房間資料必然是儲存在統一的快取裡面，超時檢測必然是檢查使用者上次登入的時間戳，超時了執行使用者退出房間邏輯，而房間排程則需要所有房間的資訊。而使用者操作，每次操作，會更新該使用者的房間內的時間戳

由於房間資料是高爭用資料，所以想到是把使用者資料從房間資料分離，然後房間資料只保留使用者索引，但使用者的頻繁退出進入或者超時，也就造就了房間資料有不低的爭用頻率，但用一些cas之類的衝突解決方案，也能基本解決問題

而超時檢測，需要遍歷所有房間內使用者的資料，我們的使用者資料量很大，最高能達到近1000w，所以即使頻率很低（1分鐘），高峰期每秒鐘也達到了16w的資料訪問量，這是不能接受的

根據需求的進一步細化，引出了第二次設計（準確說是第三次，中間的忘了）：不精確模型

需求其實不明確要求人數限制要限制很死，比如說10個人，即使達到了100個人，問題也不大，所以我們的初始方案有了很大的優化餘地，我們將本來的精確模型改為了不精確模型

首先，採用了租約的模型，也就是乙個使用者進入房間，會給他乙個租約，也就是上述的時間戳，然後將每次操作更新租約改為了由客戶端採集使用者操作，定時更新租約（時間較長）。

第三，超時檢測多做一件事情，除了檢查租約（其實也就是遍歷所有房間的租約，每個房間乙個list），讓使用者退出之外，再由超時檢測服務來維持乙個房間人數，set操作，無視衝突

第四，房間分派服務每次只需遍歷所有的房間的人數，就可以得出乙個全域性的狀況，然後進行排程

第五，排程服務採用預排程模式，即每次查詢全域性資訊，會預排程一批房間號，當使用者請求分派時，只會從預排程佇列裡面去拿乙個房間號，然後新建租約，這樣，又極大的降低了排程的頻率，注意，這時候會更新房間人數，即會與第三步的動作有衝突，解決方案是無視衝突

第六，由於極大地降低了排程的頻率，我們完全可以將排程演算法做得很複雜，我們提供了多種解決方案

1.預排程模型，也就是根據增長率等狀況，計算每次排程人數

2.簡單排程，只根據當前房間數來決定增長率和排程人數

而房間的增長方案，我們採用的是優先順序排程方案，高於某個閾值，則優先排程，目標是快速填滿，低於某個閾值，則極少排程或者不排程

第七，由於是分布式的，即每個伺服器都會有乙個排程服務跟乙個超時檢測伺服器，排程服務還好說，可以人數/伺服器數就可以得到每個伺服器的排程人數，不需要協作，超時檢測伺服器是需要協作的，因為每個伺服器做的工作是一樣的，所以我們還是用了memcached做同步，cas解決衝突

第八，細節

雖然超時檢測需要訪問統一快取的資料量已經降為極低，但是我們還是希望進一步優化，所以制定了在房間的上一層劃分乙個層次，然後在超時檢測週期內均勻分布所有的檢測，讓資料庫訪問更平緩

在排程服務中進一步優化，當訪問次數很多的時候，會將排程頻率提高，比如說當預排程佇列中少於某個閾值時，會額外新增排程執行緒來提高排程頻率

總結其中，由精確模型向不精確模型的轉化是很關鍵的一步，這也告訴我們，業務系統的設計永遠是立足於需求的，高精確性，高一致性，不一定是最好的解決方案

第二，租約概念的提出給整個概念模型的建立給了很大的助力，在思考上和概念上的思路變得清晰而有條理

開始的設計是每秒10w以上的訪問量，到最後降低為每秒不超過10次，這不能不說是乙個質的飛躍

專案回憶 一 虛擬房間系統