<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>中文 &#187; zhanghefu</title>
	<atom:link href="http://software.intel.com/zh-cn/blogs/author/zhanghefu/feed/" rel="self" type="application/rss+xml" />
	<link>http://software.intel.com/zh-cn/blogs</link>
	<description></description>
	<lastBuildDate>Mon, 28 May 2012 14:23:20 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
		<item>
		<title>游戏服务器架构设计中的一些思考</title>
		<link>http://software.intel.com/zh-cn/blogs/2010/11/30/400006472/</link>
		<comments>http://software.intel.com/zh-cn/blogs/2010/11/30/400006472/#comments</comments>
		<pubDate>Tue, 30 Nov 2010 08:06:54 +0000</pubDate>
		<dc:creator>zhanghefu</dc:creator>
				<category><![CDATA[博客征文专栏]]></category>
		<category><![CDATA[服务器]]></category>
		<category><![CDATA[游戏]]></category>

		<guid isPermaLink="false">http://software.intel.com/zh-cn/blogs/2010/11/30/400006472/</guid>
		<description><![CDATA[游戏服务器架构设计中的一些思考 1、 游戏世界由很多个游戏对象组成（游戏角色、物品、NPC、技能等）； 2、 一个游戏对象的有效数据主要存放在客户端、游戏服务器和持久性数据库中； 3、 游戏对象的处理可划分为与位置有关的和与位置无关的，如公会处理、物品处理等主要行为可以看作是与位置无关的处理，而NPC（AI）、战斗、移动这类的主要行为可以看成是与位置有关的。 4、 从客户端的角度来看，游戏行为可分为四类动作： a) 来自服务器端的动作，如另外一个玩家跳起来。 b) 本地动作。仅仅发生在本地客户端的动作，不需要与服务器端或其他客户端通讯。 c) 先执行后验证的可撤销的动作。客户端先执行，再提交服务器端验证，验证不成功通知客户端将执行的动作撤销。比如玩家控制的游戏角色执行移动处理。 d) 严格服务器端验证的动作。客户端执行动作前必须经过服务器端验证后才能执行。如交易行为、攻击其他玩家/NPC。 5、 客户端和服务器，服务器进程之间的相互的通信从逻辑上看就是就是向RemoteObject 发起的远程过程调用（RPC），RPC主要有两种类型： a) 通知(Notify)。只通知对方，而不关心和需要对方返回结果。 b) 请求(Request)。向对方发起请求，对方处理请求后返回结果，发起请求和返回结果这个过程可以是同步或异步。游戏服务器中绝大部分RPC请求都是异步的。 6、 响应延迟主要是由于网络带宽和服务器处理效率引起的。应尽可能的通过一些技巧来隐藏和减少玩家的响应延迟。但不是所有的最新消息都能立刻发送出去（或接收处理到），因此，要在服务器端采用优先队列来减少重要消息的响应时间。延迟也会由客户端产生，如收到消息后的对消息的处理速度。 7、 服务器负载，除了升级硬件设备外，可以通过一些方式来提高服务器负载。 a) 保证足够的网络带宽。 b) 分布式运算，合理的集群式架构。 c) 游戏策划从游戏内容上避免设计高并发，高消耗的游戏行为。 8、 从服务器的可伸缩性，稳定性和高效率方面来考虑，要试着避免所有事情都在一个地方处理，尽量让系统分布式运行，但是过多的划分功能到不同的进程/机器上运行，又会带来数据的大量同步的问题。因此可以将游戏对象的处理主要划分为与位置无关和有关两种。像公会，玩家信息，物品信息，组队，拍卖等等这类与位置无关的但是占用CPU资源较少的处理可以尽可能的放在一个进程中，避免进程间对象同步，而像NPC，寻路，AOI运算，战斗处理等与位置有关的，处理过程中特别关心对象坐标位置的、运算量特别大的，但是进程间对象同步较少的，都可以单独划分成多个进程。 每类进程服务的功能尽量单一。负责路由的就尽量只负责网络包转发，而不再承担其他繁重的任务，负责游戏处理的就尽量让网络包流向简单。]]></description>
			<content:encoded><![CDATA[<p>游戏服务器架构设计中的一些思考</p>
<p>1、 游戏世界由很多个游戏对象组成（游戏角色、物品、NPC、技能等）；</p>
<p>2、 一个游戏对象的有效数据主要存放在客户端、游戏服务器和持久性数据库中；</p>
<p>3、 游戏对象的处理可划分为与位置有关的和与位置无关的，如公会处理、物品处理等主要行为可以看作是与位置无关的处理，而NPC（AI）、战斗、移动这类的主要行为可以看成是与位置有关的。</p>
<p>4、 从客户端的角度来看，游戏行为可分为四类动作：</p>
<p>a)         来自服务器端的动作，如另外一个玩家跳起来。</p>
<p>b)        本地动作。仅仅发生在本地客户端的动作，不需要与服务器端或其他客户端通讯。</p>
<p>c)         先执行后验证的可撤销的动作。客户端先执行，再提交服务器端验证，验证不成功通知客户端将执行的动作撤销。比如玩家控制的游戏角色执行移动处理。</p>
<p>d)        严格服务器端验证的动作。客户端执行动作前必须经过服务器端验证后才能执行。如交易行为、攻击其他玩家/NPC。</p>
<p>5、 客户端和服务器，服务器进程之间的相互的通信从逻辑上看就是就是向RemoteObject 发起的远程过程调用（RPC），RPC主要有两种类型：</p>
<p>a)         通知(Notify)。只通知对方，而不关心和需要对方返回结果。</p>
<p>b)        请求(Request)。向对方发起请求，对方处理请求后返回结果，发起请求和返回结果这个过程可以是同步或异步。游戏服务器中绝大部分RPC请求都是异步的。</p>
<p>6、 响应延迟主要是由于网络带宽和服务器处理效率引起的。应尽可能的通过一些技巧来隐藏和减少玩家的响应延迟。但不是所有的最新消息都能立刻发送出去（或接收处理到），因此，要在服务器端采用优先队列来减少重要消息的响应时间。延迟也会由客户端产生，如收到消息后的对消息的处理速度。</p>
<p>7、 服务器负载，除了升级硬件设备外，可以通过一些方式来提高服务器负载。</p>
<p>a)         保证足够的网络带宽。</p>
<p>b)        分布式运算，合理的集群式架构。</p>
<p>c)         游戏策划从游戏内容上避免设计高并发，高消耗的游戏行为。</p>
<p>8、 从服务器的可伸缩性，稳定性和高效率方面来考虑，要试着避免所有事情都在一个地方处理，尽量让系统分布式运行，但是过多的划分功能到不同的进程/机器上运行，又会带来数据的大量同步的问题。因此可以将游戏对象的处理主要划分为与位置无关和有关两种。像公会，玩家信息，物品信息，组队，拍卖等等这类与位置无关的但是占用CPU资源较少的处理可以尽可能的放在一个进程中，避免进程间对象同步，而像NPC，寻路，AOI运算，战斗处理等与位置有关的，处理过程中特别关心对象坐标位置的、运算量特别大的，但是进程间对象同步较少的，都可以单独划分成多个进程。</p>
<p>每类进程服务的功能尽量单一。负责路由的就尽量只负责网络包转发，而不再承担其他繁重的任务，负责游戏处理的就尽量让网络包流向简单。</p>
]]></content:encoded>
			<wfw:commentRss>http://software.intel.com/zh-cn/blogs/2010/11/30/400006472/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

