1. 程式人生 > >大規模IM線上使用者的計算和資料儲存方案

大規模IM線上使用者的計算和資料儲存方案

使用者模型以及概念

線上訊息使用者模型
月活量:基本上是總使用者量,一個月不活動的使用者基本上是死使用者
日活量:一天中大於一定活躍時間的使用者
峰值使用者:一天中使用者線上最高峰的使用者總量
峰值併發使用者:峰值使用者可以同時在一秒鐘發出一條訊息的使用者

業務訊息的計算模型

當前假設為簡單的單一業務,實際情況會更復雜
1、如果一秒鐘處理1000筆請求(每條都進行儲存),那麼一天的資料量是:24*60*60*1000=8640萬;如果每秒1萬筆的話,資料大概是8.64億
2、行業裡一般的統計方法是峰值是日活量的五分之一,日活是總使用者的8%,峰值使用者產生併發的轉化率為:0.5%到1%就不錯(網路遊戲可能有點不一樣,會高一點)
3、峰值使用者: 1萬/0.01=100萬
4、日活躍使用者:100萬*5=500萬
4、月活躍使用者:500萬/0.08=6250萬
5、付費使用者一般是月活躍數的5%來進行計算

業務保活訊息計算模型

資料儲存方案

這部分的資料儲存主要是實時訊息的的儲存,針對線上的實時處理方案,當前流行的是使用redis,個人認為比較成功的方案有:
1、 redis快取,資料庫持久儲存
方案參考:http://blog.codingnow.com/2014/03/mmzb_redis.html
  在資料伺服器的物理機上啟動一個監護服務。當遊戲伺服器向資料服務推送資料並確認成功後,再把這組資料的 ID 同時傳送給這個監護服務。它再從 Redis 中把資料讀回來,並儲存在本地。
  因為這個監護服務和 Redis 1 比 1 配置在同一臺機器上,而硬碟寫速度是大於網路頻寬的,它一定不會過載。至於 Redis ,就成了一個純粹的記憶體資料庫,不再執行 BGSAVE
2、redis快取,levelDB儲存
參考:

http://bbs.chinaunix.net/thread-3777230-1-1.html
  RedisStorage 是基於 redis 2.6.2基礎上,加上 leveldb儲存引擎。 這個專案是源於 公司專案的passport 使用者認證改造。
總結:單純使用redis做快取和資料儲存是個坑

redis相關的資料

redis二種資料儲存方法
  SAVE 和 BGSAVE 兩個命令都會呼叫 rdbSave 函式,但它們呼叫的方式各有不同:• SAVE 直接呼叫 rdbSave ,阻塞 Redis 主程序,直到儲存完成為止。在主程序阻塞期間,伺服器不能處理客戶端的任何請求。BGSAVE 則 fork 出一個子程序,子程序負責呼叫 rdbSave ,並在儲存完成之後向主程序傳送訊號,通知儲存已完成。因為 rdbSave 在子程序被呼叫,所以 Redis 伺服器在BGSAVE 執行期間仍然可以繼續處理客戶端的請求。