标签归档:服务器

RSS feed of 服务器

最后更新于 .

一. 前言

2016年6月17日凌晨5点钟,我们完成了服务器端V3版本的重构,切换的过程十分平滑且没有对线上用户产生任何影响。

这也正式标志着,我们的游戏服务器进入了一个全新的阶段。

我们上一次的重构是在 2014年12月23日,现在看看,时间过的真快啊。

而熟悉我的人应该知道,我特意为上一次重构写过一篇《游戏服务器端架构升级之路》,其中详细的讲述了我们游戏服务器从农业时代跨越到工业时代的历程。

而这次V3版本的重构,我将其定义为第二次工业革命。也许它没有那么的强大和完美,但是他切实的解决了现存的大部分问题。

二. 背景

之前的文章已经说过,V2版本的服务器的几个优点:

  1. 支持服务器代码热更新而不影响外网服务
  2. 架构模式足够简单:push-pull

但是,其简单的架构也存在一些缺点:

  1. 业务模块之间容易互相影响

    比如两个游戏玩法 A 和 B,内部使用的逻辑、存储服务器都完全不同,但是在worker层却是共用的。

    所以一旦玩法A的服务器出现问题导致处理变慢,那么worker就会被堵住,而玩法B也会跟着遭殃。

    同时,即时在一个业务模块内,也存在请求处理优先级的问题,比如拉取牌局记录和跟注,要尽量避免跟注这种核心逻辑受到影响。

  2. 限制了游戏逻辑的实现方式

    V2的多worker的模式,导致worker必须限制为无状态的,因为worker可能处理任何一个请求,而一个请求也可能被分配到任何一个worker上。

    这一点是之前解决服务器热重启的关键,但同时也限制了我们代码逻辑多样性的实现。

    比如我们的游戏桌子数据是存储在redis中,所有人对桌子的写操作可能同时分配到多个worker上,而为了避免写冲突,我们不得不通过redis来实现分布式锁 ...

最后更新于 .

这几天的心情非常好,主要原因是我们把服务器端的架构升级到了 2.0,这样最大的一个好处就是:

Server重启完全不会影响外网服务

所以,也是想趁此机会,服务器端整个发展的历程,跟大家分享一下,干货比较多,框架代码也会全部开源:)

 

一. 农业时代

创业最重要的就是一个“快”字,所以最开始的时候,所有的架构都以快速出模型为前提。

而常看我博客的朋友应该知道我对python情有独钟,所以自然的,python成为了我开发服务端框架的语言。

python自带的多线程tcp服务器框架非常简单:ThreadingTCPServer,即每个链接一个线程的模式:

import SocketServer

class RequestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        f = self.request.makefile('r')

        while True:
            message = f.readline()
            if not message:
                print 'client closed'
                break
            print "message, len: %s, content ...

最后更新于 .

一、Linux服务器上11种网络连接状态:
4036295646_eb2b2b957d
                                          图:TCP的状态机

通常情况下:一个正常的TCP连接,都会有三个阶段:1、TCP三次握手;2、数据传送;3、TCP四次挥手

注:以下说明最好能结合”图:TCP的状态机”来理解。

SYN: (同步序列编号,Synchronize Sequence Numbers)该标志仅在三次握手建立TCP连接时有效。表示一个新的TCP连接请求。

ACK: (确认编号,Acknowledgement Number)是对TCP请求的确认标志,同时提示对端系统已经成功接收所有数据。

FIN: (结束标志,FINish)用来结束一个TCP回话.但对应端口仍处于开放状态,准备接收后续数据。

1)、LISTEN:首先服务端需要打开一个socket进行监听,状态为LISTEN. /* The socket is listening for incoming connections. 侦听来自远方TCP端口的连接请求 */
2)、SYN_SENT:客户端通过应用程序调用connect进行active open.于是客户端tcp发送一个SYN以请求建立一个连接.之后状态置为SYN_SENT ...

最后更新于 .

在工作中,我们可能经常会用到压力测试等循环执行执行发包的机制,为了防止目标机压力过大,必然需要一个限速逻辑来进行控制,之前在网上看了看,发现基本没有这方面的介绍,于是自己写了一个。 这段代码使用了已经大半年,基本能够满足各种限速的要求,其中的动态调整逻辑也能够保证对限速本身对cpu的消耗不会太大,希望对大家有所帮助。(ps:这段代码是在linux下使用的,当然只需要将获取时间的函数改一下,那么在windows下也可以使用的,如果有朋友改了记得通知我一下哦~~)

#include <sys/time.h>
#include <stdio.h>
#include <math.h>
#include <iostream>
struct timeval tpstart,tpend;
int timeuse;
gettimeofday(&tpstart,NULL);
int countPerSec=0;//计算请求数
int statCount;//统计用
int iMaxReqPerSec=100;//最大限速
int trueMaxReq=iMaxReqPerSec;//动态调整的判定大小
while(1)
{
    //业务要做的事情 ...