大规模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%来进行计算

业务保活消息计算模型

参考：微信Android客户端后台保活经验分享

https://mp.weixin.qq.com/s?__biz=MzA3ODg4MDk0Ng==&mid=403254393&idx=1&sn=8dc0e3a03031177777b5a5876cb210cc&utm_source=tuicool&utm_medium=referral

运营商NAT超时时间如下



1、按照微信4.5分钟做一次心跳，100万峰值用户的心跳消息量：100万/(4.5*60)=0.37万

2、假设每台机器长连接处理能力为：10万/台，需要对应的接入的计算机为10台，不考虑冗余

数据存储方案

这部分的数据存储主要是实时消息的的存储，针对在线的实时处理方案，当前流行的是使用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 执行期间仍然可以继续处理客户端的请求。

redis重要参数回顾

http://blog.itpub.net/29254281/viewspace-2099173/