网络游戏用户分流设计浅淡(一)--新手村分流方案
来源:互联网 发布:mysql 查询最近的数据 编辑:程序博客网 时间:2024/04/28 15:04
中国有一群蝗虫一样的游戏玩家。在一个新游戏出来时候,一窝蜂的涌上去玩儿,在线人数哗哗往上涨。游戏厂商在很兴奋的时候又不免担心,这么多人同时来了,服务器能抗得住么?应该如何把这种情形带来的风险降到最低呢?两个核心问题因此而引发出来,分流及扩容。今天我们讨论分流。
一般网络游戏为了避免在开服初期大量玩家涌入都会考虑到分流及扩容,针对这部分内容我做一个简单的归纳分析。
以之前所从事的一款MMOG为例,它的设计方式是新手村以副本的形式存在,在服务器启动时先创建固定数量的副本,用户在进入时优先使用这些创建好的副本;如果不够,根据用户数和服务器承受能力不断的创建副本实例,总体遵循以下分配原则:
1、副本实例如果达到人数上限,则跳过。
每个副本实例都会有人数限制,如果达到人数限制,则将排队进入的用户放入下个副本中;如果下个副本满了,再到下一个,依次类推。
2、副本实例如果达到分配限制,则跳过。
只根据第一条,会导致所有人数都直接先往第一个副本中塞,塞满了再到下一个副本。这种设计其实不能做到负载平衡,实际上没有发挥出副本分流的优势。因此,引入分配限制数量。
分配限制的概念是,一次只往一个副本实例中加入固定数据的用户。假如同一时间有60个用户登录,那么每个副本实例的分配限制为20,则这60个会分成三批,分别给3个副本实例。这样基本保证每个副本实例中的用户数是差不多一样的多的。
3、满足上面2个限制的服务器,选择人数最少的服务器
如果上面两个条件同时满足,则选择人数最少的服务器。
因为每次分流人数都不会是绝对一样的整数。如果上例中,假如人数不是60,是55,那么第三个副本中就进入了50-(20*2)=15个人。
这样再来新用户时,优先放入第三个副本实例中。
4、优先选择上次选中的服务器,只要不满足2个限制,就不会重新选择服务器
这条就容易懂了。两个限制未满足时,就不再选择新的,往上次选中的副本实例中塞。满足限制条件以后再找新的实例。
通过这种方式能够比较好的以副本的方式进行用户分流,减少大量用户集中在新手村,能有效的减少消息广播,减轻网络通信服务器与消息广播服务器的压力。但也有缺点:
1.对于结伴的玩家,可能两个人在创建用户后都在游戏里,却无法见面,需要手动切换副本。
2.大号带小号的时候,很可能无法方便找到小号。
因此,对于以上两种及类似情形,我们可能还要考虑一些细节设定,比如,在组队状态的玩家,优先放入同一副本实例;组队后,自动切换到队长所在副本实例等。看具体情况而定了。
版权声明,阅读者可以无须授权就可以自由的转载这个文档,但你转载需要保留本文出处和文档的完整性。
- 网络游戏用户分流设计浅淡(一)--新手村分流方案
- 门户网站分流(一)
- HAProxy,智能分流的负载均衡方案
- nginx 的几种分流方案
- i8服务器虚拟盘和对比更新分离双网卡分流方案(一只乌鸦)
- 锁分流
- HAProxy---HAProxy,智能分流的负载均衡方案
- Debian 7+ 一键部署anyconnect&&pac智能分流
- 门户网站分流(二)
- nginx根据cookie分流
- Mac VPN 分流
- 【Storm 入门】 Blot分流
- vpn访问国内外分流
- 二进制分流法
- nginx根据URL分流
- shunt resistor 分流电阻
- 巧妙使用ADSL分流技术
- 实体抽象和信息分流
- stl::map( constructor,insert,iterator) 1
- flex垃圾回收机制
- 子窗口控件——列表框(List Box)
- 如何成为Linux平台C语言程序员
- 晒几张为igoogle设计的banner
- 网络游戏用户分流设计浅淡(一)--新手村分流方案
- 外网用户如何访问内网FTP服务器
- 星际2 "测试" 结束. 终于准备写点东西了
- diff and patch学习笔记
- 岔路口的抉择
- 关于SQL组合查询问题的一个思考
- 【小阅读^大脑袋】0811 NO.399
- 使用JPA+Struts2+Spring 在 google Appengine开发应用
- 使用JPA+Struts2+Spring 在 google Appengine开发应用