QQ宠物产品总体技术方案.docx

QQ宠物产品总体技术方案.docx

《QQ宠物产品总体技术方案.docx》由会员分享，可在线阅读，更多相关《QQ宠物产品总体技术方案.docx（12页珍藏版）》请在冰豆网上搜索。

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备选方案

[描述本产品的备选方案，可略]