百万用户同时在线游戏服务器架构实现.docx

百万用户同时在线游戏服务器架构实现.docx

《百万用户同时在线游戏服务器架构实现.docx》由会员分享，可在线阅读，更多相关《百万用户同时在线游戏服务器架构实现.docx（15页珍藏版）》请在冰豆网上搜索。

百万用户同时在线游戏服务器架构实现

百万用户同时在线游戏服务器架构实现

一、前言

理想上100万游戏效劳器，在面对少量用户访问、高并发央求方面，基本的处置方案集中在这样几个环节：

运用高功用的效劳器、高效率的编程言语、高功用的数据库、还有高功用的架构模型。

但是除了这几个方面，还没法基本处置面临的高负载和高并发效果。

当然用户不时地追求更高的机器功用，而晋级单一的效劳器系统，往往形成过高的投入和维护本钱，性价比大大低于预期。

同时全天候的可用性的要求也不能满足要求，假设效劳器出现缺点那么该项效劳一定会终止。

所以独自追求高功用的效劳器不能满足要求，目前基本的处置方案是运用集群技术做负载平衡，可以把全体功用不高的效劳器做成高可扩展性，高可用性，高功用的，满足目前的要求。

目前处置客户端和效劳器停止底层通讯的交互的双向I/O模型的效劳器的成熟方案。

1.windows下，比拟成熟的技术是采用IOCP,完成端口的效劳器模型。

2.Linux下，比拟成熟的技术是采用Epoll效劳器模型,Linux 2.6内核中提供的System Epoll为我们提供了一套完美的处置方案。

目前如上效劳器模型是完全可以到达5K到20K的同时在线量的。

但5K这样的数值离百万这样的数值真实相差太大了，所以，百万人的同时在线是单台效劳器一定无法完成的。

而且目前几个比拟成熟的开发框架，比如ICE,ACE等。

这样，当采用一种新的通讯技术来完成通讯底层时，框架自身就不用做任何修正了〔或修正很少〕,而功用很容易完成，功用到达最优。

目前采用的ace框架个不错的选择方案,可以不受操作系统的影响，移植比拟方便。

关于数据库选择可有许多成熟的方案，目前大少数选择的mysqlMaster/slave形式，以及oracleRAC方案。

基本可以满足目前的要求，但详细的瓶颈不是在数据库自身，应该还是硬件磁盘I/O的影响更大些。

建议运用盘阵。

这有其他成熟的方案，比如采用NAS处置散布数据存储。

其实最为关键的是效劳器的架构和完成，数据流量的负载平衡，体系的平安性，关键影响度，共享数据的处置等等多个方面对100万用户的数据处置有影响，所以都要片面的思索。

二、高功用的效劳器

1.网络环境

目前采用Client/Server架构来开发网络游戏，客户端和效劳器普统统过TCP/UDP协议停止通讯,关键瓶颈很明白--游戏效劳器与客户机之间的链路。

目前单机环境比拟好些的是，2块1000M网卡，20K客户端，并发提供每个客户端的带宽是2000/20K=100KB/s，这是实际值，勉强可行。

假设这样完成目前一定有本钱和功用效果。

特别是用户照应时间曾经超越他们的忍受范围。

为了防止瓶颈许多游戏厂家一组限制用户下限为100M/5k~10k。

即用户100KB/s。

而客户的网络状况也要思索。

这就也提出尽能够增加传输数据。

这需求测试评价网络吞吐量和延迟需求，以便对效劳器的用户数和带宽做评价。

网络部署中还要思索网络拓扑状况。

内网和外网要分不同的交流机，防止出现网络瓶颈。

还要思索网络图朴状况的优化。

比如每组几台运用一个交流机做流量分配。

2.CPU和内存的参考

目前要求高处置才干，高带宽，低存储容量。

主要思索的瓶颈效果应该是I/O效果，普通状况时采用双路CPU或多路，而且效劳器公用内存曾经很好的处置了I/O瓶颈。

实践测试假设几千人同时在线的话，CPU和内存需求都很低，目前普通效劳器都可以满足要求。

3.负载平衡

所以必需要采用多台效劳器的架构方式，但出现了平衡负载和散布架构的效果，可以经过下面几种方式处置。

A.硬件负载平衡设备

常用的F5等负载平衡器，很好的处置了负载平衡的效果。

普通这种设备投资比拟高，但部署容易，而且支持散布式架构。

B.集群系统

集群系统增长了系统可用性（availability）和冗余（redundancy），也提供了容错（faulttolerance）。

运用集群,可以散布央求以便多个效劳器可以共享负载，一些效劳器也能够提供确定哪台效劳器应用的不充沛以便平衡负载的复杂处置。

Linux平台上很多收费开源的集群软件，如LVS〔LinuxVirtualServer〕是Linux平台下的一个集群软件工具。

经过LVS，你可以快捷方便的组建一个带有第四层负载平衡功用的集群系统。

并且，借助第三方的工具包，还可以完成对LVS集群停止可用性支持的功用扩展。

他提供了基于心跳线heartbeat的实时灾难应对处置方案，提高系统的鲁棒性，同时可供了灵敏的虚拟VIP配置和管理功用，可以同时满足多种运用需求，这关于散布式的系统来说必不可少。

而且还有如下几点特点：

∙处置网络拥塞效果，效劳就近提供，完成天文位置有关性。

∙为用户提供更好的访问质量。

∙提高效劳器照应速度。

∙提高效劳器及其他资源的应用效率。

∙防止了网络关键部位出现单点失效。

缺陷：

∙配置比拟复杂，而且需求修正内核来支持这种结构，提高了实施的和运维的任务量。

∙普通需求添加两台效劳器做主，备也添加了本钱。

C.软件自身完成逻辑负载平衡

依据运用效劳器的许多需求，负载平衡也有一些不能满足我们的自身的需求的东西，比如平衡的条件，普通集群是依照ip分配，处置包的速度，支持的衔接数等。

而运用效劳器可以依据自己的需求定制自己的负载规那么。

比多么多游戏效劳器采用依据区域做用户限制，这样管理起来比拟方便灵敏，而且效率高。

4.操作系统的优化

建议运用linux2.6.x内核64位系统。

而且要对局部参数的修正。

A.文件系统

在fstab里参与noatime，如

#cat/etc/fstab

/dev/sda1/homeext3noatime,defaults12

reboot或许重新mount失效

B.Tcp优化

在/etc/sysctl.conf里参与

filter.ip_conntrack_tcp_timeout_syn_recv=3

#启用syncookies

net.ipv4.tcp_syncookies=1

#定义backlog队列容纳的最大半衔接数

net.ipv4.tcp_max_syn_backlog=8192

net.ipv4.tcp_fin_timeout=30

net.ipv4.tcp_keepalive_time=1800

net.ipv4.tcp_window_scaling=0

net.ipv4.tcp_sack=0

net.ipv4.tcp_timestamps=0

这些需求内核支持。

假设不支持不用修正。

C.虚拟内存优化

/etc/sysctl.conf

vm.lower_zone_protection=100

D.I/O调度器

在grub.conf的相应启动选项里参与elevator=deadline，如：

kernel/vmlinuz-2.6.6roroot=/dev/sda6elevator=deadline

这里用了Deadline的I/O调度器,它比系统默许的AnticipatoryI/O调度器更为小巧,在数据吞吐量十分大的数据库系统中表现得更有优势。

E.网络协议方面优化

Iproutecache需求修正，否那么容易丢包。

echo1>/proc/sys/net/ipv4/route/gc_interval

echo150>/proc/sys/net/ipv4/route/gc_timeout

echo2>/proc/sys/net/ipv4/route/gc_elasticity

运用hugeTLB

echoxxx>/proc/sys/vm/nr_hugepages

Tunetcp:

echo"409649152131072">/proc/sys/net/ipv4/tcp_wmem

echoxxxx>/proc/sys/net/ipv4/tcp_max_syn_backlog

echoxxxx>/proc/sys/net/core/somaxconn

echo1200000>/proc/sys/net/ipv4/tcp_max_tw_buckets

echo7>/proc/sys/net/ipv4/tcp_retries2

echo"600000650000700000">/proc/sys/net/ipv4/tcp_mem

echo0>/proc/sys/net/ipv4/tcp_timestamps

echo0>/proc/sys/net/ipv4/tcp_window_scaling

echo0>/proc/sys/net/ipv4/tcp_sack

echo330000>/proc/sys/net/ipv4/tcp_max_orphans

echo"1000062000">/proc/sys/net/ipv4/ip_local_port_range

epoll模型需求修正的参数:

echo1300000>/proc/sys/fs/file-max

F.内核源代码参数修正

可以依据部署运用效劳器的要求，或许需求部署集群的要求需求对内核作局部修正。

详细参考文档，下面只是复杂的例子。

修正/usr/src/linux/include/linux/posix_types.h

#define__FD_SETSIZE1024为65536

设置fd_set支持的最大数量

修正/usr/src/linux/include/linux/fs.h

#defineINR_OPEN1024为65536

#defineNR_FILE8192为65536

#defineNR_RESERVED_FILES10为128

设置最大翻开文件数量〔TCP衔接数量〕

修正/usr/src/linux/include/net/tcp.h

#defineTCP_TIMEWAIT_LEN（60*HZ）为1*HZ

#defineTCP_SYNACK_RETRIES5为3

设置在backlog队列里的半衔接的重试次数，每次都会花相应的时间，实质上也是增减轻试时间

makemenuconfig中，去掉没用的选项，翻开以下选项的开关：

HighMemorySupport（支持4GB以上内存）

Symmetricmulti-processingsupport（支持多CPU）

TCPsyncookiesupport（可以防DOS）

设置文件翻开数等的其他方法（益处就是可以不重新编译内核）

在/etc/init.d/sshd里参与（一致加在./etc/rc.d/init.d/functions行前面）

ulimit-n65535>/dev/null2>&1

ulimit-u16384>/dev/null2>&1

三、高效率的编程言语

1.平台言语选择

不同平台的详细完成差异也很大。

例如仅在Windwos平台下就有基于Windwows音讯机制的、基于事情机制的、也有基于完成端口I/O模型的完成等等，而linux平台也有Epoll效劳器模型，Linux 2.6内核中提供的System Epoll为我们提供了一套完美的处置方案。

可以依据不同的平台和效率，目前多采用C/C++。

2.成熟的开发框架

目前处置客户端和效劳器停止底层通讯的交互的双向I/O模型的效劳器的成熟方案。

1.windows下，比拟成熟的技术是采用IOCP,完成端口的效劳器模型。

2.Linux下，比拟成熟的技术是采用Epoll效劳器模型,Linux 2.6内核中提供的System Epoll为我们提供了一套完美的处置方案。

当然也有利于应用其它一些成熟的开发框架，比如ICE,ACE等。

这样，当采用一种新的通讯技术来完成通讯底层时，框架自身就不用做任何修正了〔或修正很少〕。

目前采用ACE框架完成，是完全可以到达5K到20K的同时在线量的，而且消耗系统资源小。

但5K这样的数值离百万这样的数值真实相差太大了，所以，百万人的同时在线是单台效劳器一定无法完成的。

所以只能采用多台效劳器负载分摊100万用户的流量数据。

3.顺序架构

通讯机制，通讯协议，线程池，memorycache,数据库

四、高功用的数据库

1.采用散布集群

百万用户同时在线关于数据库选择可有许多成熟的方案，目前大少数选择的mysqlMaster/slave形式，以及oracleRAC方案。

基本可以满足目前的要求，但详细的瓶颈不是在数据库自身，应该还是硬件磁盘I/O的影响更大些。

建议运用盘阵。

这些市场上有很成熟的方案可以参考。

目前选择oracle，应该依据详细估量出并发玩家数量和同时在线人数，就可以估量每秒事务量。

找到了可以满足事务需求的CPU和内存配置，假设可以最少只需购置两台这样的效劳器，并将它们配置为active-active集群就可以了，这样保证两台效劳器同时负载，并实时同步数据。

但是假设实践100万在线的状况，这样双机很难到达这种满足，那么要思索运用多台的散布式集群方案也可以有很好扩展性。

这需求有阅历的DBA做一个评价。

2.部署Oracle优化

最好操作系统做优化，oracle采用64位的linux版本，大约是8000元钱。

数据库数据文件，控制文件和详细系统初始参数的优化。

目前可复杂参考需求修正的几个参数：

〔依据详细的硬件设备停止优化。

〕

SGA3500M

log_buffer10M/10485760

larg_pool_size30M/31457280

java_pool_size10M/10485760

shared_pool_size250M/262144000

db_16k_cache_size2000M/2097152000

db_cache_size1000M/1048576000

db_keep_cache_size50M/52428800

sort_area_size20M/20971520

sga_max_size3670016000

数据库表空间和回滚文件的设置。

数据库表空间可以设置自动扩展。

但也要思索数据量规划好最优的大小。

回滚段大小由于并发数据量比拟大，需求依据详细的数据量思索其大小。

五、高功用的游戏效劳器架构模型

目前主流游戏效劳器架构普通采用RunGate层次化形式，，但假设到达100万用户的效劳器还有许多需求优化和思索的中央。

最复杂的效劳器负载平衡如何处置，共享数据如何处置都在层次化的效劳器结构中出现。

特别是负载平衡也存在着效果，假设其中一台效劳器到达效劳下限而瘫痪，那么很容易发生连锁反响，出现集群的效劳器依次宕掉。

所以在设计时分要做冗余和条件限制的思索。

1.目前可以参考以后的架构设计

关于100万用户同时在线效劳器架构和完成，应该从多方面思索。

比如体系的平安性，数据存储和逻辑，流量的负载平衡分配，逻辑数据关键影响度，共享数据的处置等。

客户端和效劳器端普统统过不同的协议来完成不同的数据流的交互。

而关于协议处置的模块尽能够的放到外部处置，防止其与客户端直接打交道，保证了平安性。

而中间的衔接效劳器就起到了一个代理的功用，衔接效劳器只担任在客户端和外部处置效劳器之间做包的转发功用。

而登陆〔网关〕效劳器控制着用户的认证和负载平衡的。

目前比拟常用的千兆硬件防火墙，而且同时在游戏运用效劳需求软件防火墙。

至于平安方面不作为主要思索中。

其他模块的思索是功用划分和运用效劳器的功用上。

主要是数据和逻辑的处置怎样提高效率上，当然一些内存池的运用也是提高运用效劳器常用的手腕。

在不修正目前效劳器层次，思索的架构图如下：

2.登陆效劳器

A.登陆效劳器的功用

登陆效劳器主要功用：

一个是对客户的密码做验证。

另一个是网关功用，该客户端假设经过验证那么把经过查询选择一个负载低衔接效劳器的ip和端口信息反应个给客户端，然后客户端就可以直接跟衔接效劳器通讯。

防止衔接效劳器直接对外，可以有效维护效劳器的平安。

中心思想是：

尽快地提供用户登陆的速度，尽能够方便地让玩家进入游戏中。

复杂登陆效劳器处置图：

B.登陆效劳器负载平衡

目前思索的支持大用户量的登陆效劳器，也是必需运用多台效劳器的群平衡负载。

效劳器群的部署可以运用硬件负载平衡器〔f5等，可以设定很多规那么，比如限制防止DOS攻击〕，软件集群也能能益处置，或许思索运用静态DNS〔许多网站处置双网互通时分采用这种战略也是不错处置方案〕。

但他们还是有一些效果的。

比如采用dns出现一个节点宕机由于缓存的效果招致一局部客户端很长时间不能访问的情。

而负载平衡的由于在本地更新快假设出现宕机马上知道，一定效率高。

从低本钱高效率思索建议采用软件负载平衡技术，并且对单一的登陆效劳器登陆用户数量逻辑上做一个限制〔比如5k<>20K,魔兽听说采用逻辑循环队列，应对并发用户状况，但大用户时照应时间太慢不可取〕这样可以很益处置并发和冗余的效果，并可以方便扩容。

保证大用户量的状况下用户照应时间能满足要求。

C.部署登陆效劳器思索

思索到同时并发登陆的用户数量，依据效劳器的照应时间和带宽做一下预算，由于登陆效劳器用户协议完成发送的数据量很小，依据并发用户同时登陆的状况2~4台〔QQ的目前是宣称并发登陆20k,假设这样单台处置5k,依照设计并发处置数量应该满足要求〕。

目前可以思索散布式架构构建登陆效劳器，如上硬件负载平衡器的思索基天分满足散布架构。

这样对效劳器维护和扩展比拟容易。

目前登陆效劳器后台数据库处置作为一个散布式集群，一定满足要求。

3.衔接效劳器

A.衔接效劳器功用

衔接效劳器也是跟客户端直接衔接的，主要起了数据包转发的功用。

衔接效劳器依据不同的协议把客户端的央求转发到外部不同的运用效劳器去，比如逻辑效劳器，使比拟复杂的和耗资源的逻辑处置等都放到前面运用效劳器处置，提高了效率。

而衔接效劳器也是可以完成负载平衡，依据不同的运用效劳器的负载状况，选择衔接到资源消耗小的运用效劳器上。

衔接效劳器处置图：

B.衔接效劳器部署的思索

由于思索到效劳器许多逻辑上的要求〔比如保证一个客户端和一个衔接效劳器的一个延续的会话〕，衔接效劳器经过登陆效劳器的直接负载平衡。

关于散布也都满足要求，更灵敏。

假设单台处置5k那么100万用户量最少需求是200台效劳器才干满足要求。

把这200

台部署成一组衔接效劳器的完成负载平衡功用，可以处置大用户量的效果。

4.其他运用效劳器组

A.逻辑效劳器组

处置客户端一些逻辑处置的央求，并维护在线用户表。

采用散布式结构的益处是可以有效分摊整个系统的压力，但是，缺乏点就是关于全局信息的索引将会变得比拟困难，由于每个独自的底层逻辑效劳器上都只是寄存了自己这一个效劳器上的用户数据，它没有方法查找到其它效劳器上的用户数据。

处置这个效果，复杂一点的作法，就是在集群外部，由一个中介者，提供一个全局的玩家列表。

这个全局列表，依据需求，可以直接放在〝管理效劳器〞上，也可以寄存在数据库中。

但是独自管理效劳器处置在线用户还是由于运用效劳器自身的缘由用户数量的限制，这也需求采用群集，并采用哈希算法把用户信息区分保管到不同的效劳器以便于索引。

而这样效率不高，最后确定直接写数据库的方式更合理。

可以独自树立一个库存缩小量的在线用户索引，可以提高效率，处置目前大用户量的效果。

在数据库中只保管在线用户的索引,比如用户ID,用户信息保管到那个逻辑效劳器上，其他逻辑效劳器可以经过索引直接在对应的逻辑效劳器查找到该用户的其他在线信息。

能很益处置效劳器间的互动数据的交互。

B.地图效劳器组

担任地图相关的信息的处置。

C.模型效劳器组

主要担任处置用户地块上物品的上传，下载，更新。

而且关键处置用户自造物品的的上传下载等。

依据本游戏的需求这个效劳器处置的数据量会很大。

D.买卖效劳器

处置一切物品买卖的逻辑和买卖处置，或许经过第三方的买卖平台停止现金流处置。

E.聊天效劳器组

目前采用的是jarbberd的效劳器，由于目前jarbberd的最大在线用户数50k的数量，所以也要思索集群处置大用户量的效果。

集群能很益处置了这个效果。

5.数据库集群

主要担任处置游戏需求的数据的存储，查询。

保证数据的实时性平安性。

集群环境下完成多机共享数据库，以保证运用的高可用性。

同时可以自动完成并行处置及均分负载，还能完成数据库在缺点时的容错和无断点恢复。

可以共享数据库文件，防止同步的影响。

同时可以散布跨区域的部署，添加了灵敏的部署方案。

部署方案：

一种是基于数据库引擎的形式，ORACLERAC是共享磁盘的体系结构，用户只需复杂地添加一个效劳器节点，RAC就能自动地将这节点参与到它的集群效劳中去，RAC会自动地将数据分配到这节点上，并且会将接上去的数据库访问自动散布到适宜的物理效劳器上，而不用修正运用顺序；要求数据库引擎自身具有集群功用〔普通只要企业版的数据库才具有这功用〕。

而另一种是基于数据库网关的结构，需求手工修正数据分区。

ICX是一种基于中间件的数据库集群技术，对客户端和数据库效劳器都是透明的。

可以用来集群几个数据库集群。

但本钱高，维护难度大。

所以目前建议采用第一种，oracelRAC〔OracleRealApplicationClusters〕方案，曾经基本处置了这些效果。

6.管理效劳器

A.一切运用效劳器管理

经过管理效劳器，可以对其他的效劳器一些数据的查询，比如目前形状，处置数据流量，在线用户数，以及通知各个效劳器更新配置，时间同步。

B.时间同步效果

应效劳器可以经过一个全局变量来修正运用效劳器的时间

多台效劳器会发生时间不同步的效果，为了保证各个效劳器时间坚持同步。

可以经过在管理效劳器设置为时间效劳器，各个运用效劳器跟管理效劳器停止同步保证系统时间的同步。

而应效劳器可以经过一个全局变量来修正运用效劳器的时间。

C.其他全局变量的管理

对效劳器最大支持的用户数量，客户端的时间管理等。