月活量：基本上是总用户量，一个月不活动的用户基本上是死用户 日活量：一天中大于一定活跃时间的用户 峰值用户：一天中用户在线最高峰的用户总量 峰值并发用户：峰值用户可以同时在一秒钟发出一条消息的用户
当前假设为简单的单一业务，实际情况会更复杂 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二种数据存储方法 SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：• SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave 在子进程被调用，所以 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。
redis重要参数回顾 http://blog.itpub.net/29254281/viewspace-2099173/
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/everlasting_188/article/details/51456156