大神们，你们开发MMO用的是什么服务器？【unity3d吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：78,331贴子：
大神们，你们开发MMO用的是什么服务器？收藏
请教大神指导，本人特想学习MMO开发，找了很多资料像photon服务器和SFS，这些东西又没有多少教程，又怕走弯路，希望大神指点，什么样的服务器与u3d结合比较好，而且易学易用，或者要是开源的就更好了，静静的等待您的指点。先谢谢。
51CTO学院11年行业品牌,1400万用户选择,中国专业IT技能学习平台,unity能做什么.通过在线学习的方式,帮助广大技术人员实现技能提升,高薪就业的职业梦想,unity能做什么.
业余时间学习，真的好辛苦，白天工作，晚上加班学习，努力奋斗
photon 不是很容易使用的么
说起来真是够绕的，多年前，学着玩，我自学了photoshop，后来发现做不了立体的图，我就自学3dmax，后来发现满大街都是3dmax，学网页吧，后来认识了html，md学完了才知道只能做静态的，什么？还要编程，asp？jsp？asp.net？徘徊呀，他大爷的，我学c吧，然后谭浩强的c，学了，做什么用？全她妈是cmd黑框框，那么别停止cpp好嘛，我就吧c++primar啃了，后来入门了qt，奶腿的，诺基亚黄了，感觉不景气，后来我想了想，我到底最爱什么，爱玩游戏，哎呦我去，那研究游戏开发吧，找啊找，我找到了u3d，感觉3dmax一下又用上了，当时幸福值就上来了，复习时又简单学了zb，现在又觉得mmo才是王道，我就又着急了
c# socket自己写一套系统
简单点可以用unity photon插件 (有和unity一样的network系统 官方提供免费服务器 )缺点
直接下载bigworld引擎算了
我们公司是用centos的，C++写的服务器，感觉不错
我觉得还是两步走战略比较好，你现在什么都会，但什么都不精。。
无语。我还是先学U3D，熟练客户端开发。完了进阶的时候再学服务端的。。。
AutoTDS-V1型全自动热解吸仪是一款20位常温二次全自动热解吸仪，气路采....
我一个人在战斗，始终没有停止奔跑，虽然我没有从事自己喜欢的职业，但是我坚持学习自己喜欢的，最近天天学到夜里12点，真的有些累了，那也不愿意浪费时间，梦想招呼我们去战斗，加油吧'累了放慢步子但不可以停下来
客户端先吃透在研究服务端
看样子你是像自己做mmo？牛了，要让你做出来，你还不飞天？
pomeloscutkbenginegonetdistri.luaSurvivegfirefly都是免费开源的，github上不过有学习成本
lz可以一起学习吗我也是刚刚学了些零碎的杂知识 想自己把整个流程走一遍我有学习c#版的socket服务器视频教程 希望一起学习
楼上那位，加我好友哦，
我是个新人
转眼间一年多了，我还是在努力的学习着，这仿佛成为一种乐趣。这一年我的建模水平提高了，对u3d的认识加强很多，一点点的积累，用别人的话讲，一个业余选手达到这种程度也算可以了。下一步或是下一步的下一步，我还要学习很多东西，因为涉及u3d的插件太多，马不停蹄，勇往直前，坚持。建立目标，突破目标。就这样我一步一步的走着。谁愿意来加我的qq6447307。我随时欢迎大家一起学习进步。
欢迎加入我的群码：，虽然活跃度不是很高，不过我期待你的到来。
谢谢大神，问个问题，unity3D下载的项目是需要自己将project里的文件搭建到层次栏目中吗
学KBEngine
scut可以试试，国人做的来源的，还有教程和例子，不过建议还是用socket自己写，现成的服务器为了通用，增加了很多用不上的东西，性能不太好
你看看 rAthena的代碼，是開源的
又一年过去，楼主应该成为大神了吧，顺便问问楼主现在服务端使用是自己写呢还是使用开源的游戏服务端
又一年过去，楼主应该成为大神了吧，顺便问问楼主现在服务端使用是自己写呢还是使用开源的游戏服务端
学习ProudNet
加我qq带我啊
登录百度帐号推荐应用游戏服务器框架 Leaf/go
Leaf/go 详细介绍
Leaf 是一个使用 Go 语言开发的开源游戏服务器框架，注重运行效率并追求极致的开发效率。Leaf 适用于几乎所有的游戏类型。其主要的特性：
良好的使用体验。Leaf 总是尽可能的提供简洁和易用的接口，尽可能的提升开发的效率
稳定性。Leaf 总是尽可能的恢复运行过程中的错误，避免崩溃
多核支持。Leaf 通过模块机制和 leaf/go尽可能的利用多核资源，同时又尽量避免各种副作用
良好的模块支持。
一个 Leaf 开发的游戏服务器由多个模块组成（例如 LeafServer），模块有以下特点：
每个模块运行在一个单独的 goroutine 中
模块间通过一套轻量的 RPC 机制通讯（leaf/chanrpc）
Leaf 不建议在游戏服务器中设计过多的模块。
游戏服务器在启动时进行模块的注册，例如：
game.Module,
gate.Module,
login.Module,
这里按顺序注册了 game、gate、login 三个模块。每个模块都需要实现接口：
type Module interface { OnInit() OnDestroy() Run(closeSig chan bool)
Leaf 首先会在同一个 goroutine 中按模块注册顺序执行模块的 OnInit 方法，等到所有模块 OnInit 方法执行完成后则为每一个模块启动一个 goroutine 并执行模块的 Run 方法。最后，游戏服务器关闭时（Ctrl + C 关闭游戏服务器）将按模块注册相反顺序在同一个 goroutine 中执行模块的 OnDestroy 方法。
Leaf 源码概览
leaf/chanrpc 提供了一套基于 channel 的 RPC 机制，用于游戏服务器模块间通讯
leaf/db 数据库相关，目前支持 MongoDB
leaf/gate 网关模块，负责游戏客户端的接入
leaf/go 用于创建能够被 Leaf 管理的 goroutine
leaf/log 日志相关
leaf/network 网络相关，使用 TCP 协议，可自定义消息格式，目前 Leaf 提供了基于 protobuf和 JSON 的消息格式
leaf/recordfile 用于管理游戏数据
leaf/timer 定时器相关
leaf/util 辅助库
使用 Leaf 开发游戏服务器
LeafServer是一个基于 Leaf 开发的游戏服务器，我们以 LeafServer 作为起点。
获取 LeafServer：
git clone /name5566/leafserver
设置 leafserver 目录到 GOPATH 后获取相关依赖：
go /name5566/leaf
go /golang/protobuf/proto
go get gopkg.in/mgo.v2
编译 LeafServer：
go install server
如果一切顺利，运行 server 你可以获得以下输出：
22:11:27 [release] Leaf starting up
敲击 Ctrl + C 关闭游戏服务器，服务器正常关闭输出：
22:12:30 [release] Leaf closing down (signal: interrupt)
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
今日搜狐热点<span style="color: #、skynet是一个开源的，轻量级的，为在线游戏服务器打造的框架
<span style="color: #、muduo是一个基于 Reactor 模式的 C++ 网络库
<span style="color: #、boost asio&是一个异步的网络框架
第三方教程
<span style="color: #、libevent
<span style="color: #、ACE是一个很成熟的中间件产品，为自适应通讯环境，但它过于宏大，一堆的设计模式，架构是一层又一层，对初学者来说，有点困难。
<span style="color: #、epoll（linux）
epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。
<span style="color: #、iocp(windows)
IOCP全称I/O Completion Port，中文译为I/O完成端口。IOCP是一个异步I/O的API，它可以高效地将I/O事件通知给应用程序。IOCP把一个套接字[socket]与一个完成端口关联了起来，当一个事件发生的时候，此完成端口就将被操作系统加入一个队列中。然后应用程序可以对核心层进行查询以得到此完成端口。
阅读(...) 评论()点击阅读原文
游戏服务器的架构演进(完整版)
7月24日 发布，来源：
这是王者荣耀技术分析系列第三篇，有兴趣请持续关注。
3、游戏服务器的架构演进
?????本文阅读预计需要10分钟，主要技术点来如下，感兴趣请继??续:
游戏服务器特征
短连接游戏服务器架构
长链接游戏服务器架构
分区分服服务器架构
MMOARPG服务器架构
房间服务器架构
1游戏服务器特征游戏服务器端，是一个会长期运行的程序，并且它还要服务于多个不定时，不定点的网络请求。所以这类软件的特点是要非常关注稳定性和性能。这类程序如果需要多个协作来提高承载能力，则还要关注部署和扩容的便利性；同时，还需要考虑如何实现某种程度容灾需求。由于多进程协同工作，也带来了开发的复杂度，这也是需要关注的问题。功能约束，是架构设计决定性因素。基于游戏领域的功能特征，对服务器端系统来说，有以下几个特殊的需求：
对于游戏数据和玩家数据的存储
对玩家数据进行数据广播和同步
把一部分游戏逻辑在服务器上运算，做好验证，防止外挂。
针对以上的需求特征，在服务器端，我们往往会关注对电脑内存和CPU的使用，以求在特定业务代码下，能尽量满足承载量和响应延迟的需求。最基本的做法就是“空间换时间”，用各种缓存的方式来以求得CPU和内存空间上的平衡。
在CPU和内存之上，是另外一个约束因素：网卡。网络带宽直接限制了服务器的处理能力，所以游戏服务器架构也必定要考虑这个因素。
2游戏服务器架构要素
对于游戏服务端架构，最重要的三个部分就是，如何使用CPU、内存、网卡的设计：
内存架构：主要决定服务器如何使用内存，以最大化利用服务器端内存来提高承载量，降低服务延迟。
逻辑架构：设计如何使用进程、线程、协程这些对于CPU调度的方案。选择同步、异步等不同的编程模型，以提高服务器的稳定性和承载量。可以分区分服，也可以采用世界服的方式，将相同功能模块划分到不同的服务器来处理。
通信模式：决定使用何种方式通讯。基于游戏类型不同采用不同的通信模式，比如http,tcp,udp等。
3服务器演化进程
1卡牌等休闲游戏弱交互游戏
服务器基于游戏类型不同，所采用的架构也有所不同，我们先讲一下简单的模型，采用http通信模式架构的服务器:
这种服务器架构和我们常用的web服务器架构差不多，也是采用nginx负载集群支持服务器的水平扩展，memcache做缓存。
唯一不同的地点不同的在于通信层需要对协议再加工和加密，一般每个公司都有自己的一套基于http的协议层框架，很少采用开源框架。
2长链接游戏服务器
长连接游戏和弱联网游戏不同的地方在于，长连接中，玩家是有状态的，服务器可以时时和client交互，数据的传送，不像弱联网一般每次都需要重新创建一个连接，消息传送的频率以及速度上都快于弱联网游戏。
1、第一代网游服务器（单线程无阻塞）最早的游戏服务器是1978年，英国著名的财经学校University of Essex的学生 Roy Trubshaw编写了世界上第一个MUD程序，叫做《MUD1》。
《MUD1》程序的源代码在 ARPANET共享之后，在全世界广泛流行起来。不断完善的 MUD1的基础上产生了开源的 MudOS（1991），成为众多网游的鼻祖。
MUD1 是一款纯文字的世界，没有任何图片，但是不同计算机前的玩家可以在游戏里共同冒险、交流。与以往具有网络联机功能的游戏相比, MUD1是第一款真正意义上的实时多人交互的网络游戏，它最大的特色是能够保证整个虚拟世界和玩家角色的持续发展——无论是玩家退出后重新登录还是服务器重启，游戏中的场景、宝箱、怪物和谜题仍保持不变，玩家的角色也依然是上次的状态。
MUDOS使用单线程无阻塞套接字来服务所有玩家，所有玩家的请求都发到同一个线程去处理，主线程每隔1秒钟更新一次所有对象（网络收发，对象状态，刷新地图，刷新NPC）。
用户使用 Telnet之类的客户端用 Tcp协议连接到 MUDOS上，使用纯文字进行游戏，每条指令用回车进行分割。这样的系统在当时每台服务器承载个4000人同时游戏。从1991年的 MUDOS发布后，全球各地都在为他改进，扩充，推出新版本。
MUDOS中游戏内容通过 LPC脚本进行定制，逻辑处理采用单线程tick轮询，这也是第一款服务端架构模型，后来被应用到不同游戏上。后续很多游戏都是跟《UO》一样，直接在 MUDOS上进行二次开发，直到 如今，一些回合制游戏，以及对运算量小的游戏，依然采用这种服务器架构。
第一代服务器架构图:
2、第二代网游服务器（分区分服）2000年左右，随着图形界面的出现，游戏更多的采用图形界面与用户交互。此时随着在线人数的增加和游戏数据的增加，服务器变得不抗重负。于是就有了分服模型。分服模型结构如下：
分服模型是游戏服务器中最典型，也是历久最悠久的模型。在早期服务器的承载量达到上限的时候，游戏开发者就通过架设更多的服务器来解决。这样提供了很多个游戏的“平行世界”，让游戏中的人人之间的比较，产生了更多的空间。
其特征是游戏服务器是一个个单独的世界。每个服务器的帐号是独立的，每台服务器用户的状态都是不一样的，一个服就是一个世界，大家各部牵扯。
后来游戏玩家呼吁要跨服打架，于是出现了跨服战，再加上随着游戏的运行，单个服务器的游戏活跃玩家越来越少，所以后期就有了服务器的合并以及迁移，慢慢的以服务器的开放、合并形成了一套成熟的运营手段。目前多数游戏还采用分服的结构来架设服务器，多数页游还是采用这种模式。
线程调度分服虽然可以解决服务器扩展的瓶颈，但单台服务器在以前单线程的方式来运行，没办法充分利用服务器资源，于是又演变出了以下2种线程模型。
异步-多线程，基于每个场景（或者房间），分配一个线程。每个场景的玩家同属于一个线程。游戏的场景是固定的，不会很多，如此线程的数量可以保证不会不断增大。每个场景线程，同样采用tick轮询的方式，来定时更新该场景内的（对象状态，刷新地图，刷新NPC）数据状态。玩家如果跨场景的话，就采用投递和通知的方式，告知两个场景线程，以此更新两个场景的玩家数据。
多进程。由于单进程架构下，总会存在承载量的极限，越是复杂的游戏，其单进程承载量就越低，因此一定要突破进程的限制，才能支撑更复杂的游戏。多进程系统的其他一些好处：能够利用上多核CPU能力、更容易进行容灾处理。多进程系统比较经典的模型是“三层架构”，比如，基于之前的场景线程再做改进，把网络部分和数据库部分分离为单独的进程来处理，逻辑进程专心处理逻辑任务，不合IO打交道，网络IO和磁盘IO分别交由网路进程和DB进程处理。
3、第三代网游服务器之前的网游服务器都是分区分服，玩家都被划分在不同的服务器上，每台服务器运行的逻辑相同，玩家不能在不同服务器之间交互。想要更多的玩家在同一世界，保持玩家的活跃度，于是就有了世界服模型了。世界服类型也有以下3种演化:
一类型（三层架构）网关部分分离成单端的gate服务器，DB部分分离为DB服务器，把网络功能单独提取出来，让用户统一去连接一个网关服务器，再有网关服务器转发数据到后端游戏服务器。而游戏服务器之间数据交换也统一连接到网管进行交换。所有有DB交互的，都连接到DB服务器来代理处理。
二类型（cluster）
有了一类型的经验，后续肯定是拆分的越细，性能越好，就类似现在微服务，每个相同的模块分布到一台服务器处理，多组服务器集群共同组成一个游戏服务端。
一般地，我们可以将一个组内的服务器简单地分成两类：场景相关的（如：行走、战斗等）以及场景不相关的（如：公会聊天、不受区域限制的贸易等）。经常可以见到的一种方案是：gate服务器、场景服务器、非场景服务器、聊天管理器、AI服务器以及数据库代理服务器。如下模型:
以上中我们简单的讲下服务器的三种类型功能:
场景服务器：它负责完成主要的游戏逻辑，这些逻辑包括：角色在游戏场景中的进入与退出、角色的行走与跑动、角色战斗（包括打怪）、任务的认领等。场景服务器设计的好坏是整个游戏世界服务器性能差异的主要体现，它的设计难度不仅仅在于通信模型方面，更主要的是整个服务器的体系架构和同步机制的设计。
非场景服务器：它主要负责完成与游戏场景不相关的游戏逻辑，这些逻辑不依靠游戏的地图系统也能正常进行，比如公会聊天或世界聊天，之所以把它从场景服务器中独立出来，是为了节省场景服务器的CPU和带宽资源，让场景服务器能够尽可能快地处理那些对游戏流畅性影响较大的游戏逻辑。
网关服务器: 在类型一种的架构中，玩家在多个地图跳转或者场景切换的时候采用跳转的模式，以此进行跳转不同的服务器。还有一种方式是把这些服务器的节点都通过网关服务器管理，玩家和网关服务器交互，每个场景或者服务器切换的时候，也有网关服务器统一来交换数据，如此玩家操作会比较流畅。通过这种类型服务器架构，因为压力分散了，性能会有明显提升，负载也更大了，包括目前一些大型的 MMORPG游戏就是采用此架构。不过每增加一级服务器，状态机复杂度可能会翻倍，导致研发和找bug的成本上升，这个对开发组挑战比较大，没有经验，很容出错。
三类型（无缝地图）魔兽世界的中无缝地图，想必大家印象深刻,整个世界的移动没有像以往的游戏一样，在切换场景的时候需要loading等待，而是直接行走过去，体验流畅。
现在的游戏大地图采用无缝地图多数采用的是9宫格的样式来处理，由于地图没有魔兽世纪那么大，所以采用单台服务器多进程处理即可，不过类似魔兽世界这种大世界地图，必须考虑2个问题：
1、多个地图节点如何无缝拼接，特别是当地图节点比较多的时候，如何保证无缝拼接
2、如何支持动态分布，有些区域人多，有些区域人少，保证服务器资源利用的最大化为了解决这个问题，比较以往按照地图来切割游戏而言，无缝世界并不存在一块地图上面的人有且只由一台服务器处理了，此时需要一组服务器来处理，每台 Node服务器用来管理一块地图区域，由 NodeMaster（NM）来为他们提供总体管理。更高层次的 World则提供大陆级别的管理服务。
一个 Node所负责的区域，地理上没必要连接在一起，可以统一交给一个Node去管理，而这些区块在地理上并没有联系在一起的必要性。一个 Node到底管理哪些区块，可以根据游戏实时运行的负载情况，定时维护的时候进行更改 NodeMaster 上面的配置。
对象的无缝迁移
玩家A、B、C分别代表3种不同的状态，以及不同的迁移方式，我们分别来看。
玩家A: 玩家A在node1地图服务器上，由node1控制，如果迁移到node2上，需要将其数据复制到node2上，然后从node1移除。
玩家B: 玩家B在node1和node2中间，此时由node1和node2维护，若是从node1行走到node2的过程中，会向1请求，同时向2请求，待全部移动过去了再移除。
玩家C:玩家C在node2地图服务器上，由node2控制，如果迁移到node1上，需要将其数据复制到node1上，然后从node2移除。具体魔兽世界服务器的分析，篇幅过多，我们以后再聊。
3、房间服务器（游戏大厅）房间类玩法和MMORPG有很大的不同，在于其在线广播单元的不确定性和广播数量很小。而且需要匹配一台房间服务器让少数人进入一个服务器。
这一类游戏最重要的是其“游戏大厅”的承载量，每个“游戏房间”受逻辑所限，需要维持和广播的玩家数据是有限的，但是“游戏大厅”需要维持相当高的在线用户数，所以一般来说，这种游戏还是需要做“分服”的。典型的游戏就是《英雄联盟》这一类游戏了。而“游戏大厅”里面最有挑战性的任务，就是“自动匹配”玩家进入一个“游戏房间”，这需要对所有在线玩家做搜索和过滤。
玩家先登录“大厅服务器”，然后选择组队游戏的功能，服务器会通知参与的所有游戏客户端，新开一条连接到房间服务器上，这样所有参与的用户就能在房间服务器里进行游戏交互了。
以上就是目前游戏服务器的演化进程，由于所涉及的内容太多，关于服务器的相关网络IO以及内存模型都没有介绍，以后有机会再具体讲讲这一部分。
end想了解更多有料的游戏技术，扫码关注我的公众号，原创独到。
扫码关注更多
我要该，理由是：
关闭理由：
删除理由：
忽略理由：
推广（招聘、广告、SEO 等）方面的内容
与已有问题重复（请编辑该提问指向已有相同问题）
答非所问，不符合答题要求
宜作评论而非答案
带有人身攻击、辱骂、仇恨等违反条款的内容
无法获得确切结果的问题
非开发直接相关的问题
非技术提问的讨论型问题
其他原因（请补充说明）}