第一部分 服务器逻辑

服务器这边简单的分为三个部分，客户端的连接首先到达网关服务器，网关这里有个线程用来监听来自与客户端的连接，然后在将这些数据发送到游戏逻辑服务器上，这个逻辑游戏服务器上，数据的交互就是通过与数据服务器进行交互。RecordServer专门用来处理与数据库的连接，查询这些事情。当然为了游戏服务器能够最大程度的不卡，肯定就得规定好网关服务器上的连接数量，免得像我们号称流畅的铁道部订票网络一样做个卡B，想想玩一局dota被卡的悲剧吧。当我们要做一个大型网游时，这三个服务器显然不够。当然在自己写的小游戏的时候就无所谓了，几个服务器全部架设在自己的破笔记本上，不就是启动几个程序而已。

这个感觉写得就差不多了，到细节吧。

第二部分 实现细节

这个就比较乱了，零零散散的，随便写了。这里很多都是对各种工具的封装，以便于自己 在项目的使用

1.make

项目这么多目录，这么多子目录，肯定得用工具去编译了，使用aclocal,automake,autoconf,make,就把我们的程序编译好了，编写自己configure.in文件，定义编译选项、链接库等等一系列乱七八糟的东西，然后对每个需要编译的子项目编写Makefile.am,有的需要要编译成库的，比如base等基类这些，其他的都编译成可执行文件了，GatewayServer,LogicalServer,RecordServer。

2.套接字封装，epoll使用

linux里，我们使用socket来读写网络上的数据，这个很简单了，gateway上一个客户端连接过来，我们就为它分配一个socket 描述符了，在网关上，一个线程用来accept,一个线程用来做数据的处理，当accept一个连接请求后，放到数据处理的线程，接受到一个数据，然后直接转发到logical server上，我们使用epoll_wait，来处理套接上的读写处理。每n ms处理一次循环，每次循环中使用一次epoll_wait，一次把这些有事件的socket取出来。

3.数据加密解密，压缩解压

对网络上的数据，为了保证安全性，必须对它们进行加密解密处理，这个简单了，网上各种内容，这里就不说了（全部写完了，有时间再写）。对数据进行压缩，能减少带宽吞吐，就是简单的调用几个zlib函数的调用，不细说，在前面转发的《zlib使用》中有讲，发现自己太懒，实在是懒得打字了。

4.线程封装，互斥量，读写锁

这些都是简单的使用RAII或其他方式，对这些东西进行一次本地封装。（应该得写一个线程池去管理这些线程，todo）

5.数据库封装

使用mysql,使用mysql的C API函数，这个必须得封装一下，不是每次数据的处理，都得去做很多事情，实现一个本地的数据的Field(列),Record（记录）,Table（表）,DataBase（数据库）,RecordSet(查询结果集)。制作一个数据库连接句柄MysqlHandle，处理对数据库的连接，处理等，实现一个HandlerPool,，每次从Pool中取出一个句柄来对数据库进行查询，免得每次都去重新连接，什么的。

6.自己的内存池

在之前分享的文章中《内存池技术详解》《编写自己的内存分配器》，自己的《内存池应用》，已经很详细的说明了，内存池的制作，当然我在这里还是有一些改动的，但是大概思路就是这些了。

7.有一个状态机的实现

这个也在自己之前写的那个状态机相关的文章里，也做记录了。哈哈，实在是不想继续码字了，但是还是坚持下去。

8.lua与c++交互框架

这个暂时写了一半，等全部完成了，再来弄，反正就是像npc处理这些，脚本处理这些，使用tolua++。

9.tinyxml封装，正则表达式封装

tinyxml一个轻量级的xml解析器，很简单，反正是把这些现成的东西拿来自己用。正则表达式没有进入c++标准，但是还是很多现成的正则表达式的处理，直接用linux库下的regex.h,就是编译正则表达式，匹配结果这些，

10.log系统

一个项目怎么能没有自己的日志系统呢，反正就是打日志，往文件里面写东西，用std::fstream轻松搞定，定义好日志级别:error / debug / fatel / info这些

11.时间封装

这个必须有，否则自己还每次去调用get_clocktime,gmtime,time各种函数呀。

12.使用boost库里的，Noncopyable,Singleton这些设计方法，来写我们的代码

13.定义好各种信号句柄，信号发生时采用什么策略，如SIGPIPE，做忽略处理

待续。。。。。。。。（睡觉了）

游戏服务器技术应该算来已经很成熟了，相比客户端，它的技术更新速度很慢了。客户端这边，技术很多，各种游戏引擎比如3D的虚幻这些，什么粒子引擎，声音这些，页游的flash, html5,utility,，太多了，搞不过来呀。我先把服务器这边好好专专，其他的等以后再说吧。

之前有过一篇介绍游戏服务器端的博文

http://blog.csdn.net/liuxialong/archive/2011/06/12/6539762.aspx

但是篇幅太长，而且过于关注细节，适合深读。

这里给出一种宏观把握MMORPG服务器设计的文章，适合入门，读完后对服务器端的设计能有大概的掌握，方便对感兴趣的部分进行深入了解。

1、首先是常见的服务器端结构，其中包括：登陆服务器、网关服务器、数据库服务器（账号数据库、角色数据库、地图数据库等）、聊天服务器、地图服务器、日志服务器等。下图为一个游戏大区的服务器群架构。所谓大区的意思，就是在打开客户端，进入游戏后，需要先选择大区，如：华南一区、华东电信等，进入大区后，再挑选服务器。下图的设计可以作为一个大区的架构使用。

2.登陆服务器

相应的工作流程为：

3. 网关服务器

工作流：

4. 地图服务器

工作流：

sessionStorage.varName = “生成新变量”;
sessionStorage.varName = “变量操作”;
delete sessionStorage.varName;  //删除变量

另外一种是本地存储，当网页下次被打开的时候，你仍然可以访问上次打开该网页时存储的数据，比如本地存储的网站用户名就可以使用这种方式。
用法和基于会话的存储一样，只是前缀名改成了localStorage

localStorage.varName = “生成新变量”;
localStorage.varName = “变量操作”;
delete localStorage.varName;  //删除变量

从上面可以看出web storage其实也只是解决了轻量级的数据存储问题，如果是大量的数据查询，比如商品列表，还是得靠数据库,HTML5中有Web Database来支持这一操作，基本操作和SQL一致。
注1：现在的浏览器基本都支持多窗口了，一个窗口对应一个网页
注2：官方参考

游戏服务器的设计是一项颇有挑战性的工作，游戏服务器的发展也由以前的单服结构转变为多服机构，甚至出现了bigworld引擎的分布式解决方案，最近了解到Unreal的服务器解决方案atlas也是基于集群的方式。

负载均衡是一个很复杂的课题，这里暂不谈bigworld和atlas的这类服务器的设计，更多的是基于功能和场景划分服务器结构。

首先说一下思路，服务器划分基于以下原则：
1：分离游戏中占用系统资源（cpu，内存，IO等）较多的功能，独立成服务器
2：在同一服务器架构下的不同游戏，应尽可能的复用某些服务器（进程级别的复用）
3：以多线程并发的编程方式适应多核处理器。
4：宁可在服务器之间多复制数据，也要保持清晰的数据流向
5：主要按照场景划分进程，若需按功能划分，必须保持整个逻辑足够的简单，并满足以上1，2点

服务器结构图：

各个服务器的简要说明：

Gateway：应用网关，主要用于保持和client的连接，该服务器需要2种IO，对client采用高并发连接，低吞吐量的网络模型，如IOCP等，对服务器采用高吞吐量连接，如阻塞或异步IO。

网关主要有以下用途：
1：分担了网络IO资源
2：同时，也分担了网络消息包的加解密，压缩解压等cpu密集的操作。
3：隔离了client和内部服务器组，对client来说，它只需要知道网关的相关信息即可（ip和port）。
4：client由于一直和网关保持常连接，所以切换场景服务器等操作对client来说是透明的。
5：维护玩家登录状态

World Server 是一个控制中心，它负责把各种计算资源分布到各个服务器
它具有以下职责：
1：管理和维护多个Scene Server
2：管理和维护多个功能服务器，主要是同步数据到功能服务器
3：复杂转发其他服务器和Gateway之间的数据
4：实现其他需要跨场景的功能，如组队，聊天，帮派等

Phys Server 主要用于玩家移动，碰撞等检测
所有玩家的移动类操作都在该服务器上做检查，所以该服务器本身具备所有地图的地形等相关信息。具体检查过程是这样的：首先，Worldserver收到一个移动信息，WorldServer收到后向Phys Server请求检查，Phys Server检查成功后再返回给world Server，然后world server传递给相应的Scene Server.

Scene Server 场景服务器，按场景划分，每个服务器负责的场景应该是可以配置的。理想情况下是可以动态调节的。

ItemMgr Server 物品管理服务器，负责所有物品的生产过程。在该服务器上存储一个物品掉落数据库，服务器初始化的时候载入到内存。任何需要产生物品的服务器均与该服务器直接通信

AIServer 又一个功能服务器，负责管理所有NPC的AI。AI服务器通常有2个输入，一个是Scene Server发送过来的玩家相关操作信息，另一个时钟Timer驱动，在这个设计中，对其他服务器来说，AIServer就是一个拥有很多个NPC的客户端。AIserver需要同步所有与AI相关的数据，包括很多玩家数据。由于AIServer的Timer驱动特性，可在很大程度上使用TBB程序库来发挥多核的性能。

要理解并行编程，首先要从并行的理解开始。

（1）从Wiki中并行编程的解释说起

Wiki是个好东西，包含了很多专业术语的解释，关键的是，除了解释，wiki还是一个好文档。

Paralle Programming（并行编程/并行计算）Wiki：http://en.wikipedia.org/wiki/Parallel_programming
Parallel computing is a form of computation in which many calculations are carried out simultaneously,[1] operating on the principle that large problems can often be divided into smaller ones, which are then solved concurrently ("in parallel"). There are several different forms of parallel computing: bit-level, instruction level, data, and task parallelism. Parallelism has been employed for many years, mainly in high-performance computing.

这里要讨论的就是上面的这句话中加粗的部分的内容。要理解好并行编程，首先需要理解并行编程的形式。并行编程的形式包括：

bit-level parallelism：位级别的并行，是基于处理器的字长不断增加的基础上，就比较容易理解了。处理器的字长不断增加，并行度自然增加。（http://en.wikipedia.org/wiki/Bit-level_parallelism）

instruction level parallelism（ILP）：指令级并行，是指处理器能同时处理多条指令。

data level parallelism（DLP）：数据集并行，是指处理器能同时处理多条数据。

task level parallelism（TLP）：任务级并行，我见过更多的是称为Thread-level parallelism（TLP），即线程级并行。

下面就这些并行的概念进行进一步分析，这些并行的方式，特别是BLP、ILP和DLP本身都是和处理器微架构有关的内容，从微架构的角度，才能更理解并行。线程级并行可以是软件也可以有硬件支持。

（2）并行的两大分类

既然提到了微架构，就不得提一下并行的两大分类，微架构中经常将并行分为两大类：时间并行和空间并行。时间并行指的是流水线并行，空间并行包括指令并行、数据并行和线程并行。

更多关于以微架构的角度讨论这几个并行，参考相关的书籍，入门推荐《大话处理器》。

（3）指令级并行

所谓指令级并行，是指处理器能同时运行多条指令。

一般而言，如果程序中相邻的一组指令是相互独立的，即不竞争同一个功能部件、不相互等待对方的运算结果、不访问同一个存储单元，那么它们就可以在处理器内部并行地执行。

超标量（Superscalar）技术 和 超长指令字（Very Long Instruction Word, VLIW）技术是目前最基本的两类指令级并行技术。前者的特点是采用普通的指令，设置多条并行工作的指令流水线；后者的特点是：将若干条普通指令组装在一起，形成一条“超级指令”。这条“超级指令”包含多个不同操作码，这些操作码分别处理不同的操作数。对应这些操作码，一一对应地设置相应的功能部件。这样，只要取指令一次、分析指令一次，VLIW 技术就可以实现对多个不同的操作数，同时进行不同的处理/计算。目前，主流的微处理器都采用了超标量技术。

当然，现代处理器有很多能帮助其进行指令并行的设计，比如乱序执行、寄存器重命名等技术。指令级命令，需要依赖于具体的硬件支持，以及编译器支持。通常，我们需要依赖编译器的优化来生成指令级并行的代码，当然，对于有些情况，编译器需要我们的帮助，更容易生成指令级并行的代码，具体需要根据编译器的实现。

参考http://www.docin.com/p-148703990.html介绍用软件方法开发指令级并行代码，其实，其分析的正是编译器生成指令级并行的例子（流水线调度和循环展开等）。

（3）数据级并行

所谓数据级并行，是指处理器能同时运行多条数据。数据并行需要从SIMD、MMX、SSE等谈起了。

SIMD：single instruction multiple data，单指令多数据，即同一操作会重复处理多个数据，一条语句处理多个数据的指令，就是SIMD指令。SIMD指令的出现是从多媒体时代开始的，由于多媒体中很多数据的处理就是SIMD的模型，所以，诞生了SIMD指令。现在的高性能处理器都支持SIMD指令，Intel从1996年开始增加MMX（MultiMedia eXtensions）指令集（也即SIMD指令），后来逐步增加了SSE（Streaming SIMD Extensions）、SSE2、SSE3、SSSE3、SSE4.1、SSE4.2、AVX（Advanced Vector Extensions）指令集。所以说，数据级并行，也是依靠处理器的指令集完成了。数据并行的模型包括垂直计算形式、水平计算形式、标量计算模式，图解可参考《大话处理器》的相关内容。

简单的理解，向量a[N],b[N],c[N]，那么

1. 垂直计算模式：a[i] op b[i] = c[i]

2. 水平计算模式：a[i] op a[i+1] = c[i] (前半部分) b[i] op b[i+1] = c[i] (后边部分)，这里的前半部分后半部分并不是严格的，得看指令会如何处理，总是，垂直计算方式，操作数来自于不同的源，水平计算方式，操作数可以来自于同一个源。

3. 标量计算模式：a[0] op b[0] = c[0]，其余不变。

对于多媒体的计算和科学计算，存在大量类似的计算，所以说SIMD能极大的提高计算性能。

当然，数据并行，比如垂直计算模式，最常见的情况，就是一个for循环了。

for(int i = 0;i< N;i ++) c[i] = a[i] + b[i];

这样的代码就能生成SIMD指令，那么是不是这么一个循环，直接一条指令搞定！当然不是，并行是有限制的，能接受的N不可能无限大！对于不同的指令集，一次数据并行能接受的数据长度是一定的，对于AVX指令集，能接受的长度为256字节。所以，可以对这样的循环进行优化，比如：

for(int i = 0;i < N;i +=4) { c[i] = a[i] + b[i]; c[i+1] = a[i+1] + b[i+1]; c[i+2] = a[i+2] + b[i+2]; c[i+3] = a[i+3] + b[i+3]; }

这样编译器就能很容易的生成SIMD指令（具体需要依赖编译器的实现，这里的4也是一个例子，前提是数组a/b/c的数据元素乘以4为SIMD指令集能接受一次运算的长度）

（4）线程级并行

线程并行是一种更高层的数据并行，是一种分时复用的思想。线程级并行可以依靠操作系统（软件）来完成，但是现在的处理器，硬件也会为线程并行提供帮助，从而提高线程并行的效率。

更多内容，参考《大话处理器》或者其他关于微架构的资料。

只有了解和理解了并行的这些概念，才能更好的理解编译器优化的工作，也就能更好的让我们写出更容易让编译器生成并行化代码的代码。

之前上海建了云计算中心，在近日推出的重庆“重庆市工业转型升级“十二五”规划”中，云计算也成了重点之一：重庆计划在十二五中，建成智能云端集群，同时使电子信息成为重庆的重要支柱产业。

据网上介绍，其智能云端集群是通过聚集移动运营商，金融客户，高端制造业客户，互联网客户等来做大数据处理业务。其中国内客户的在岸业务主要是商家对客户的B2C，而国外客户的离岸业务主要是商家对商家的B2B。

云计算中心就好比是信息的梧桐树，而其上的应用就是金凤凰了。看来国内除了公路机场的基建以外，信息化的基建也是热火朝天，云计算正当其时！

从事高性能后台服务的开发2年，做大的支持是17w/s的访问100%cpu。这个数据是前几天在一个Server终极测试中得出的。其实后台服务器的反映快慢取决于其服务的类型。几个数据是这样的。

内存访问：300w/s.即us级别。访问一次300ns。

sock访问us级别。

磁盘访问ms级别。包括数据库。

如果只靠访问内存，你的Server应该处理30W/s的访问才能算达到要求。这个后续主要受限于fd的通知机制和高并发能力的epoll框架。当在网络层做到内核级优化，并且尽可能去掉内核中的锁，应该提高到40w/s甚至50w/s的访问。

高性能接入的关键是网络接入的性能和高效的通知机制。高性能对的网络处理必须的借个原则：

1.绝不能在网络处理部分加锁。

2.采用单进程的比共享的所效率提升3倍，加锁使网络吞吐能力大幅下降。

3.使用内存暂存数据，内存的管理必需预先分配好，寻找任一块的内存做到O（0）.内存管理算法，这里大家去研究。我所处理的是分布式系统的高并发接入机，其中还涉及到后端的cache服务器的路由等。这个业务是server的逻辑，这个一块路由的设计也是有讲究的。要想最短的路由时间，必须设计可靠的内存访问和O（0）的路由查找算法。这一方面相信大家也应该懂了。

4.共享内存的访问跟内存访问一样。不过实际生产环境中往往需要对共享内存加锁。加锁使用信号量来实现。现在知道posix那一套多么牛X了。进程之间的通信，优选posix。经过测试表明，system V的接口比posix接口慢50%以上。显然现代的更先进。

5.去掉代码中的STL的链表，vector等操作，采用代替方案。对性能有非常大的提升，对减轻CPU消耗贡献巨大。良好的程序架构是减少bug的最好途径。代码需要反复检查。在分布式系统的访问都是多状态的。状态机的各部分处理是核心。需要对每一次请求做出最少的代价，需要很多脑筋可动的；包括代码的减少和函数的调用。很多系统调用代码，自己采用简单的方法实现。

6.减少时间函数的待用。缓存系统时间是一个非常好的优化，将时间用于整个处理的流程中几倍可以将cpu降低10个百分点。减少了系统空间和用户空间的调用。有兴趣可以看看内核代码。linux取的时间是不准确的，取时间需要加锁。进入内核空间，去读取cmos的时钟数据。每次更新系统时间都是原子性的操作。