游戏服务器-架构分类

这应该是这个系列的第一篇文章，呵呵~~！也不知道是哪根线搭错了，就想着要写个系列的东西，也许就是为了装B吧，希望能坚持下去，废话不说了，下面进入正题

在游戏服务器领域，没有一成不变的框架，都是针对性的根据不同游戏类型来进行架构，有时可能几种类型架构的服务器同时存在，下面我讲解一下，我个人认为的几种服务器架构模式，以下观点纯属个人观点，欢迎你我他来吐槽

模式a

名称：分区模式

定义：

1.人为的把服务器分离，一个区代表一个逻缉上独立的服务器，区与区的玩家不存在交互（逻缉上的服务器：完成游戏需求逻缉的一组物理服务器，或单台物理服务器）

2.每个区中的用户或角色都是独立的

3.交互多在服务器内部的在线玩家中进行

4.即时性要求较高

5.玩家数据独立于每个区，不存在统一的数据中心（统一的数据中心是相对于sns模式的而说的）

6.网络连接多为长连接

7.在线玩家状态变更较为频繁,而不在线玩家的状态大部分不存在变化

8.玩家状态的变更，大部分是要求玩家在线交互而产生的，很难存在在线玩家操作修改不在线玩家的状态数据

9.存在严格意义上的上下线关系（多为上线加载数据，下线回写数据等，[当然这里会涉及到了各种回写数据的策略,这些策略不在模式分类中讨论]）

模式b

名称：房间模式

定义：

1.房间为独立的游戏逻缉执行单元，起到一个在线人员分流的作用

2.房间一但创建，就归属于一个线程或一个进程，房间内的游戏逻缉是不能跨越归属线程或进程执行的

3.在房间之上可以存在大厅（非必要），管理房间以及房间与房间之间的逻缉交互（也许在某些架构中不叫大厅）

4.房间内部的人员都为在线玩家

5.交互大部分存在于在线玩家之间，很难存在在线玩家修改不在线玩家的状态数据。

6.不存在统一的数据中心（此统一的数据中心是相对于sns模式而说的）

7.玩家在进入房间之前不存在执行游戏的核心逻缉，交互相对没有较高的即时性，对玩家状态的变更不太多。

8.进入房间后，对于即时性的要求较高，玩家状态的变更变得很频繁

9.网络连接多为长连接.

10.存在严格意义上的上下线关系（多为上线加载数据，下线回写数据等）

模式c

名称：类sns模式

定义：

1.大世界，所有玩家存在于一个世界（相对分区而言）

2.统一的数据中心（相对分区而言，不再设立每个区的独立数据）

3.网络连接多为短连接（常见的为http协议，当然你也可以用自已的规范）

4.对即时性的要求不高

5.不存在严格意义上的上下线关系（即在线玩家随时可以操作不在线玩家的数据）

6.对不在线人的数据操作较为频繁，对数据IO读写性能要求较高

7.经常发生在线玩家操作不在线玩家的状态数据

8.对时间的敏感度，可以低至1-5秒内或更长

以上模式都是单一的，现在的游戏多为混合在使用以上架构模式，接下来的文章会从最后sns模式开始，逐一分析各种架构，并给出自已使用的案例。