HTTP服务器的特点

最近一个月在学习关系性数据库mysql, 顺便看了一下http服务器的编写。写了这么久的游戏服务器,数据库也一直使用nosql。因此在初次尝试使用mysql编写http服务器程序时，产生了强烈的反差。 在使用APP的验证过程中，经常会遇到短信验证码问题。 下面就以‘如何实现短信验证码服务’来对比一下http服务器和游戏服务器（mysql和nosql)解决此类问题的不同之处。主要涉及数据结构定义、优化、及逻辑代码的更新问题。 先来明确一下‘业务流程’，最简单的‘短信验证码服务’至少要提供3个操……

一次性能优化经历

自从上次修改backlog之后, Silly的IO能力，就一直以少量（约4~6K)的差距落后于redis，却一直找不到原因。 这次打算从头做一次profile来问题到底出在哪。 先用GNU提供的gprof分析一下C代码是否有值得优化的地方，结果发现CPU使用率最高的地方是luaVM内部和malloc/free。 我们所有的业务逻辑全在lua层做的，而IO线程与worker(lua)线程进行交互时是通过malloc来实现的。这几乎表明C代码几乎已经没有优化的余地了。 但是有个好消息，就是gprof不去profile系统调用和so，也许还有机会。 ……

关于CPU分支预测

由于很偶然的原因，这两天瞄了几眼”ZeroMQ”项目，发现项目中使用了’likely/unlikely’这种暗示编译器做分支预测优化的宏（这些宏只是gcc内建函数__builtin_expect的别名)。 其实早在看linux kernel源码时，就不止一次看到这组宏。但是，对此并没有放在心上。仅仅粗略搜了一下，得知‘likely/unlikely这组宏可以向编译器提供分支预测信息，以便编译器可以更好的安排指令顺序来提高效率’就没有再深入下去了。 因为我觉得，这种级别的优化估计能提高个千分之几就……

C程序中让两个不同版本的库共存

今天有同学提出，如何在一个C程序中让两个不同版本的库共存。 首先想到的方案是，把其中一个版本的库函数全部重命名，比如把每一个函数名都加一个_v2的后缀。 人工替换到没什么，但是如果函数个数超过10个，就有点不拿人当人使了。 而使有工具去替换就会遇到一些棘手的问题，如何识别哪些是函数，哪些是系统函数（系统函数不需要添加后缀)等。 随后想到的另一个解决方案是C++的方案，为其中一个版本库中的所有文件添加命名空间。然后使用g++将这部分代码编译成.o文件，之后再使用gcc……

实现了一个AOI模块

在场景服务中，如果有一个人A的行为想要被其他人看得到，就必须将A的数据包进行转发给其他人。 最KISS的办法，就是直接把A的数据包直接在场景服务内组播。 但是在一个场景服务中可能有成百上千个人，如果直接在服务进程内进行广播，数据流量会大到一个很夸张的地步，至少以目前的网速来讲是不现实的。 因此，往往场景服务都为人物设计一个视野半径，即只将数据包转发给在我视野内的人，这样可以极大的降低数据的转发流量。 而AOI(Area Of Interest)正这样一个可以帮我们快速确定视野……

一个高可伸缩的游戏服务器架构

设计完socket通讯协议后，就面临着服务器架构设计了。我希望他是一个去中心化且具有高可伸缩性的集群架构。 水平扩展是高可伸缩的首要条件，因此，在设计之初就必须考虑好水平扩展考方案。事实上这一部分几乎花了我1整个月的时间来设计，在此期间我重写了3版才总算确定下来我认为可用的方案。 第一版设计方案如下： 将服务器分为3类，分别是GateServer, LoginServer, LogicServer。 GateServer管理客户端链接，数据包的加密、解密、广播、转发等与业务逻辑无关的操作。当压力过大时……

关于网络协议封装的一些新想法

最近业余时间在写一个小游戏。在为客户端封装socket层时头脑一热，有了一些新的想法, 在这里记录一下。 客户端使用的是Unity3d引擎。而在Unity3d中，基础的socket库只提供两种模式，一种是阻塞模式，一种是异步callback模式。 一般都需要基于这两种模式下进一步封装，才可以更方便的使用。 咨询了几个做客户端的并搜了一下，发现大家的惯用手法都是开一个线程去使用socket阻塞去读，然后把读到的数据通过队列传回主线程进行处理。 但是也许是单线程的思维模式已经深入我心了，所以我……

给silly增加热更新

最新抽了点时间给silly增加了一个silly.patch模块，用于对热更新提供一些有限的支持。 热更新最麻烦之处莫过于“数据迁移”， 即怎么使新函数（要更新的函数）以“运行时数据”的状态运行。 其实http这类无状态协议是最为简单的，因为他们不需要“数据迁移”的过程。http的这种架构，使得所有的函数都是无副作用的，所有的数据在请求结束给出Response的同时, 数据就已经存入了数据库。当需要热更新函数时，根本就不需要考虑数据的问题，直接替换就可以完美解决。 与此相对的是，通常的服务……

使用缓存优化数据请求

继上一篇场景之后，事情还没有完。 我有一堆struct obj对象（数量级可能为千级), 客户端需要频繁拉取这些信息中的一部分去显示（比如，当切换标签页时）。 由于这一操作可能会很频繁，而struct obj对象并不算小，如果每一次都重新拉取全部数据，有点让人不舒服，而且对流量也是一种很大的浪费。因此就琢磨着怎么去优化整个过程，以使在此过程中使数据传输量最小。 第一反应，肯定就是对整个列表加一个version字段，每当有obj对象改变时，version加1，当客户端进行拉取时，拿着他本地……

如何恢复全局INDEX

一般来说，当需要分配全局惟一id时，一般都会有一个变量来记录当前最新的id值，比如叫INDEX变量。 每次需要分配id时，只要简单的自增一下INDEX变量，然后INDEX的值即为当前分配出去的ID的值。 为了最大可能的延迟复用已经分配过的id，一般来说不会去特殊处理INDEX变量，即每次自增INDEX，并允许回绕情况的发生。 但是最近碰到问题就是，我有一堆分配过的id，如何重新恢复出INDEX的值。具体场景如下： struct obj { unsigned int id; time_t createtime; ……

更多