简单的计算模型
1、如果一秒钟处理1000笔请求(每条都进行存储)，那么一天的数据量是:24*60*60*1000=8640万；如果每秒1万笔的话，数据大概是8.64亿
2、行业里一般的统计方法是峰值是日活量的五分之一，日活是总用户的8%。按照，按照峰值1万来进行计算的话，总的用户数是： 1万*5/0.08=62.5万,另外付费用户占总用户一般在5%左右，具体看运营情况。
3、日活跃用户产生峰值的计算：一般的消息类的，大概能到0.5%到1%就不错（一秒钟同时发出，网络游戏可能有点不一样，会高一点），基于2的假设，大概总的用户量为：62.5万/0.01=6250万
4、游戏本身的频率比较高，在步骤3的计算方法可能不同
数据存储方案
这部分的数据存储主要是实时消息的的存储，针对在线的实时处理方案，当前流行的是使用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/