QQ宠物产品总体技术方案.docx
《QQ宠物产品总体技术方案.docx》由会员分享,可在线阅读,更多相关《QQ宠物产品总体技术方案.docx(14页珍藏版)》请在冰豆网上搜索。
QQ宠物产品总体技术方案
QQ宠物总体技术方案
拟制:
日期:
审核:
日期:
版本号:
XXXV1.0
腾讯科技(深圳)有限公司
修订日期
修订内容
协议版本
修订人
1背景
QQ宠物是公司当前给以重大盈利期望的拳头产品之一。
目标是建立成全球第一的在线虚拟宠物养成类休闲游戏,成为公司主要的盈利点之一。
2概述
2.1范围
该文档主要描述QQ宠物系统的技术架构,作为架构评审的基础。
2.2引用标准
2.3术语和定义
名词
解释
2.4符号和缩略语
缩写
英文描述
中文描述
3总体架构设计
3.1设计原则
3.1.1产品关联性设计
●与OI_DB扩展标志位的同步
用户注册宠物,宠物系统将主动通知oi_db设置标志位。
3.1.2产品依赖性设计
●使用server-bench作为serverframework,分离业务逻辑和通信,进程调度等基础设施
●使用cplib,qslog,tlib库
3.2设计目标
3.2.1路标规划
阶段
开始时间
完成时间
阶段目标和工作进度指标
2.0
2005.3-2005.6
2005.6
完成基本功能
2.1
2005.6-2005.7
2005.7
增加了宠物结婚功能
3.3系统需求
3.3.1系统软件需求
●slackwarelinuxkernel2.4.x
●mysql4.0
3.3.2系统硬件需求
Web服务器/PetOnline服务器/PetInfo服务器/领养关系服务器/宠物炫图片/客户端安装包/资源下载服务器:
●LENOVOR510-5112
●标配:
CPUP42.4G×2
●内存:
4GDDRRAM
●硬盘:
36G×1NORAID
DB服务器:
●DL380G3
●标配:
CPUP42.8G×2
●内存:
1GHPDDRRAM×2
●硬盘:
140GRAID5(140G)
3.3.3系统功能需求
●宠物领养:
用户初始得到宠物。
记录QQ号码的领养关系,同步标志位到oidb
●宠物在线:
server维持宠物在线状态,自动根据卫生值,饥饿值决定宠物生病,根据宠物心情值和在线时间增长宠物的成长值。
●基本养成:
提供给用户通过PetClient和PetServer的交互,给虚拟宠物喂食、洗澡、吃药,属性查看的功能。
宠物如果养育不当会死亡,死亡后可以抛弃。
●宠物社区:
宠物社区是一个web应用,用户通过嵌入宠物客户端的ie控件来访问,在社区上购买药品,食品和日常用品,以及装扮用的房屋等道具和学习宠物炫。
社区还是结婚,打工等功能的入口。
在社区上还提供用户查询、修改宠物信息的功能,查看宠物元宝帐户的功能和查看元宝消费记录的功能。
●宠物打工:
打工是一个相对独立的子系统,目前只在社区上有入口。
宠物打工是宠物的一种状态,这种状态持续指定的时间,并且给用户提供指定数量的元宝以及增加指定属性的值。
用户通过社区上的入口进行打工,打工入口为一个CGI程序,负责检查是否符合打工的条件。
打工时要求宠物的消耗比正常状态多。
●宠物结婚:
符合一定条件的宠物双方可以结为夫妻关系。
结婚后的宠物可以生蛋,蛋必须赠送给自己的好友。
相当于给好友开通宠物。
●宠物装扮:
宠物使用买来的房屋作为桌面上宠物的背景s
●宠物炫:
宠物炫是QQ聊天时有宠物的一方可以向好友发送由宠物表现的丰富表情,动作和语言。
用户可以定制语言。
●宠物在QQ上的资料查询:
在QQ客户端,用户可以通过查询对方的资料看到对方的宠物信息,包括对方是否有宠物,宠物的级别,宠物的名字,性别,婚否等等。
●宠物在QQ上的表现:
用户在AllInOne聊天窗口中和宠物资料界面上都可以看到对方和自己的宠物图片。
s
3.3.4系统性能需求
●最小化容量:
一台OnlineServer服务器上同时支持50000个在线宠物
一台DB能够支持50万只宠物注册数
一台WebServer能够支持25000只在线宠物
一台AdoptMapServer能够支持1.5亿只注册用户数
一台Middled能够支持5万只在线宠物数
一台PetInfoServer能够支持100万只注册宠物
一台宠物炫图片server能够支持100万只注册宠物
一台资源下载server能够支持每天新增2万只宠物
一台客户端下载server能够支持每天新增10万只宠物
●最大化容量
支持3000万只宠物注册用户数
最高在线400万只宠物
●响应速度要求
用户登陆时间<5s
用户操作的响应时间应该小于1秒
宠物状态不一致时延不超过5秒
宠物炫发送响应时间不超过5秒
3.4系统总体架构
3.4.1系统物理架构
3.4.2系统逻辑架构
4关键技术分析
4.1业务模型分析
4.1.1目标用户
●针对QQ用户群中细分的青少年人群低年龄层用户群
4.1.2用户入口
●桌面QQ面板上的宠物图标
4.1.3消费系统策略
●宠物元宝和元宝帐户
宠物元宝由用户打工或者进行某些任务后得到,相当于免费赠给用户的货币。
用户可以使用元宝购买宠物系统中的物品
●宠物元宝和QB的关系
当用户的元宝数量不足时,可以直接使用个人帐户中的Q币来支付购买所需的金额。
这种情况下,1QB相当于100元宝。
由于宠物系统中的物品定价使用元宝,大多数都不超过100元宝,因此,相当于非常小额的QB交易。
这就体现出了宠物系统的消费特点:
小金额,大交易量。
4.1.4产品依赖关系
●QQ上的入口和表现形式
●其他业务使用的开通宠物的接口
4.1.5典型业务过程
●典型操作
1.通过QQ面板打开宠物客户端
2.宠物客户端检查是否需要升级,取得领养关系,取得是否需要升级资源包,完成必要的下载升级,登录
3.登陆后显示宠物目前的状态,如果饥饿提示用户要喂食,疾病和清洁状况都有类似的提醒。
4.用户使用快速喂食界面或者进入社区,在储藏室里选出食物等物品给宠物使用(或食用)
5.用户进入社区给宠物看病
6.用户进入社区购买宠物使用的物品
7.用户在社区中更换宠物的房屋
8.用户在社区中学习宠物炫
9.用户在社区中打工挣取宠物元宝
10.用户在社区中查看排名
11.用户在社区中查看其他宠物的资料
12.用户在社区中管理自己的物品
13.用户在社区中管理自己的元宝帐户
14.用户在社区中求婚,查看求婚和被求婚记录,结婚。
15.用户查看自己的宠物蛋信息,赠送宠物蛋给好友。
4.2用户模型分析
4.2.1用户基础信息
按照每台机器承受5万只宠物同时在线,承受20万只宠物的资料查询请求来计算。
大约600次交互/秒
喂养:
Hello包200次/秒(每用户5分钟一次)
喂食,洗澡和吃药:
30次/秒(每用户每小时/2次)
通过Web的交互:
20次/秒
客户端刷新:
50次/秒(每用户每小时3-4次)
登录:
10次/秒
push消息:
50次/秒(饿,脏,病,成长等等都会下发push消息)
Info查看:
120次/秒(每台机器5万在线x8=40万)x100好友/每人x1/10一小时内会查看一次
CGI请求:
150次/万人/秒,使用6台机器,一台WebServer可以支撑2.5万在线,大约每秒250次cgi请求。
•DB数据量
每个用户的数据包括:
1.宠物的基本信息表(每个宠物一条记录)
2.宠物的成长信息表(每个宠物一条记录)
3.喂养物品表(每种物品一条记录)
4.装扮物品表(每种物品一条记录)
5.打工信息表(每次打工一条记录)
字典表:
喂养物品,打工场景,宠物炫,装扮物品,处方,规则等等
•10万新用户在一小时以内使用宠物客户端大约每秒60次请求。
•宠物客户端250K大小,资源包2M左右。
在控制总量而不是放开领养请求的情况下,每天增加2万新用户,最多每天增加10万新用户。
4.2.2用户操作信息
●登录和维持在线/喂养流程:
1.客户端向领养关系server请求uin对应的petid,每个请求大小100byte,返回包150byte
2.客户端向OnlineServer发送登录请求包,每个包100bytes
3.OnlineServer向DB请求load数据,数据包300bytes
4.OnlineServer将登陆后的状态信息返回客户端,数据包大小也是300byte
5.客户端向OnlineServer发送hello包,数据大小80byte
6.OnlineServer向客户端回应hello包,数据大小300byte
7.状态机server向QQ发送宠物状态改变的push消息,数据大小200byte
8.客户端向OnlineServer发送喂食、洗澡、吃药请求,数据大小100byte
9.OnlineServer返回消耗物品后的结果,数据包大小300bytes
需要访问Online服务器:
85次/(用户*天),
●web操作:
web操作是用户访问宠物社区所进行的操作,包括查看和管理属性,查看和管理物品道具技能,查看元宝帐户,购买物品,学习技能,装扮,打工,结婚等等。
需要访问WebServer:
100次/(用户*天)
需要访问WebOnline:
10次/(用户*天)
由于web上的静态对象不通过宠物系统,而是分布在专门的图片server上,因此web访问产生的流量可以忽略不计
4.2.3用户流量信息
主要产生流量的是资源下载和客户端下载。
峰值每小时新增1万用户,资源包大小为3M,平均每个下载耗时3分钟,观察到的流量峰值达到250Mbp
4.3系统模型分析
一个典型的登录交互时序如下:
状态改变流程
4.4性能容量分析
公式
计算结果
备注
存储要求
(每人的item和合成图片的个数)*每个文件平均大小*注册用户数
20K*1.2*10M=420G
在线server要求
每5w人内存使用
4CPUloading
200M
1
带宽要求(内网)
(server间交互次数*平均数据包大小*2)
18K*1K*2*8=300mbps
计算的峰值时的出带宽
带宽要求(外网)
下载带宽
200mbps
计算每天放出10w的峰值时的出带宽
机器要求
关键负荷分析
在线server计算量
4.4.1总计
每增加20w免费用户需要:
DB+Middled+NFS一台
Online一台
Web两台
4.5负载均衡分析
4.5.1负载均衡策略
PetInfo,接入服务器,DB,Middle按照QQ号码取模散列
PetAdoptMap按照QQ号码段散列
WebServer,资源下载Server,宠物炫图片Server通过DNS轮换进行负载均衡
4.5.2异地分布策略
先暂时不支持异地分布。
4.6容灾备份分析
5部署方案
目前的大部分机器都部署在深圳枢纽和南山机房。
6风险分析及规避措施
总的来讲,运营的风险可以分成硬件故障和软件故障两大类。
硬件的故障包括机器的故障、磁盘故障、IDC线路故障,黑客攻击等。
软件的故障包括数据库失效、程序失效等等。
6.1硬件故障
6.1.1机器、磁盘故障
对于磁盘故障,DB数据采用每天夜间进行增量备份,bitmap文件每天备份。
6.1.2IDC线路故障和黑客攻击
对于IDC线路故障和黑客攻击,这个没有方法完全避免问题,只能是尽量减少损失。
以后将会支持OnlineServer的跨地域分布,当一地的机房遭受攻击,可以暂时将用户配置到另一地区登录。
6.2软件故障
对于软件故障我们现在依靠端口监控、日志监控,定时重起,nagios告警等方法规避。
7备选方案
[描述本产品的备选方案,可略]