HTTP服务器的特点

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

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

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

listen函数中的backlog字段

今天在公司无意间又拿redis-benchmark测了一下silly的IO并发性并与redis本身比较了一下。 发现在2000个client同时并发的情况下，性能只是Redis的30%的左右。 直觉上这很不正常，虽然silly所有的数据经过lua层时都需要malloc和memcpy，但最多性能上差个10%~20%就已经很可观了，绝对不可能差70%这么多。 通过不断的调整client的个数，我发现性能并没有明显随着client的数量降低而降低，而是在client个数到达某个值时突然降低的。 比如我自己测的数据是在491个client时，silly的性能与r……

谈谈协议的设计

闲来无事，最近接了个公众号玩玩，当然肯定是基于silly的:) 最初的打算是开一个daemon，在收到微信sdk callback后根据好友发送的消息来做出不同的处理。比如根据输入关键字然后去我的blog上去爬取相关信息，每天定时把最新的blog文章做群发。 在实现http client过程中，需要解析dns。虽然gethostbyname可以用来解析域名，但是整个silly底层是基于异步来实现的，而gethostbyname则是以阻塞方式解析的，因此使用gethostbyname会极大地降低整个框架的吞吐量。 向dns服务器请求解析域名……

silly的一次大规模重构

最近一个月都在重构silly, 包括其工作模式以及一些扩展库的实现基本上都被重写了。 其实coding的时间并没有想象中的那么长，只是在重构过程中碰到很多取舍情况，大部分时间都耗费在了纠结的时间上。 当初实现silly的初衷是首先满足类似gameserver这类业务模型的需求，然后尽可能多的兼顾其他类型的server。 然而以这两年的工作经验来看，master-worker模式由于多worker之间不能进行通信，因此仅仅适用于http这种不带有状态残留的协议模型。 而对于gameserver这类在进程内存内残留状……

内存数据库和进程内cache

上家公司是做TPS游戏的，因此其实对玩家数据的操作其实不是很频繁，而且由于当时服务器的数据库部分是单独剥离开给指定的人维护的。因此对于cache这一块，从来没有仔细的考虑过。新公司的游戏需要与离线玩家进行战斗，因此在写业务逻辑时是需要cache支持的。但是总觉得cache设计之初的定位有些问题，由此引发了一些思考。 最初我一直在纠结于内存数据库，我觉得诸如redis这种内存数据库已经把所有数据内容都常驻内存了。那么设计一个cache真的有必要么？直接随用随取不就行了么。在……

Silly多端口监听支持

前两天在编写一个新服务器程序时才意识到，多台不同类型的服务器相互通信，服务器仅监听一个端口号是非常不方便的，比如服务器集群中的ctrl_server需要接受多种不同的服务器建立链接，让所有链接去涌入同一个端口显然是不明智的，这时候就需要监听多个不同的端口。 让我纠结了两天的问题是到底该以怎么样的方式增加多端口支持。 首先先到的是，去掉配置文件中port的支持，增加一个listen API让lua逻辑自己去指定监听哪几个端口号，但是有一个明显的问题，多个worker现在启动时加载同……

服务器的分布式部署

两周前使用redis-benchmark测了一下silly的并发请求响应速度， 开1000个客户端， 平均大概每秒能响应6W个请求。 但是这些请求仅仅是PING/PONG协议，也就是说这基本上就是纯网络I/O的性能，如果考虑到逻辑处理、数据压缩、加密、解密等时间， 可能一个silly都不一定能够撑得起5000人的访问量。 所以最近两周除了在研究redis之外， 就是在研究怎么给silly增加cluster支持，以便可以将计算分摊到不同的计算机上来降低客户端的请求的响应延迟，silly应该怎么增加对cluster的支持。 直到……

silly的socket模块重构

最初， 我仅仅最只想将silly实现成一个socket异步框架， 每一个socket有数据或事件过来直接将注册的处理函数异步回调即可。 然后， 随着三国杀的一步步实现， 我发现我之前考虑处理时漏掉了数据库环节。 由于所有socket事件均为异步, 当一个client发过来一个请求， 而这个请求需要使用到数据库数据时， 可能就会写出类似下面这样的代码： socket.recv(fd,function(fd, data) --process segment1 db.get(key, function(value) --process segment……

silly中socket犯的错误

silly的socket模块最初是使用epoll实现的， 后来为了在mac上开发就加入了kevent, 然后使用socket_poll.h来封装成了socket_poll。 但是由于对epoll和kevent的不了解，导致了在实现silly_socket.c文件中的_process函数时犯了一些很silly的错误。 直到昨天去实现异步发送时才突然发现epoll和kevent的不同之处。 linux下，在调用epoll_wait函数时将一个struct epoll_event结构体的数组作为参数传入，当epoll_wait函数返回且返回值大于0时， 则会将当前已经发生的事件和发生事件的文件描……