大规模IM在线用户的计算和数据存储方案

xiaoxiao2021-02-28  7

用户模型以及概念

 月活量:基本上是总用户量,一个月不活动的用户基本上是死用户 日活量:一天中大于一定活跃时间的用户 峰值用户:一天中用户在线最高峰的用户总量 峰值并发用户:峰值用户可以同时在一秒钟发出一条消息的用户

业务消息的计算模型

当前假设为简单的单一业务,实际情况会更复杂 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/

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/everlasting_188/article/details/51456156
转载请注明原文地址: https://www.6miu.com/read-1750112.html

最新回复(0)