基本概念

• Golang的热更新采用什么机制?

  使用go1.8提供的plugin包机制实现

• plugin包本身设计的目的是热更新么?

  plugin包其实只是支持将代码分别编译为多个动态库,动态加载后运行 并不能完全支持类似C/C++的动态库方式处理代码

• 带状态的进程热更新的基本概念及范围是什么?

  数据部分(model)不更新, 只更新逻辑部分(函数)

• 表格和配置更新算热更新么?

  算, 但不是本文描述范围

• 热更新能在windows上使用么?

  不支持

代码及结构

• 我能将原来一个exe的代码编译为so提供给plugin使用么?

  可以, 但是必须仍然保留main包作为插件入口, 并在main包内添加提供给plugin调用入口.

• 如果动态库中没有main包, 编译出的so能用么?

  不能, 包必须包含main, 否则输出的是.a的文件, plugin包加载会报错

• 动态库中, 非main包的的代码修改能做热更新么?

  不能!(崩溃了吧, 我提了一个issue: https://github.com/golang/go/issues/20554)

  如果确实做了修改, 底层会报错: plugin was built with a different version of package

  解决方法: 修改plugin包底层实现并重新编译 打开runtime/plugin.go, 注释以下代码 for _, pkghash := range md.pkghashes { if pkghash.linktimehash != *pkghash.runtimehash { return "", nil, pkghash.modulename } } 执行/usr/local/go/run.bash 重编译+测试

• 代码中哪些可以被更新? 方法可以被更新么? 闭包呢?

  只能更新拥有静态地址的结构.例如: 包级别函数(类似于静态函数)

  例如: svc_0.so里有一个Foo函数, svc_1.so修改了Foo函数实现, 热更新可实现

  闭包=函数+捕获变量, 实际上是一个动态结构, 没有静态地址, 无法被更新

  各种包级别变量, 结构体变量, 结构体方法, 局部变量均不能被热更新, 但是变量值不会被影响

  新增结构可以被运行

• 使用结构体方法调用了包级别函数, 包级别函数能被更新么?

  可以, 虽然方法不能被更新, 但方法被调用的包级别函数的地址是固定的, 所以可以被热更新

• init包初始化函数能用么? 能被热更新么?

  官方这样描述:

  When a plugin is first opened, the init functions of all packages not already part of the program are called. The main function is not run. A plugin is only initialized once, and cannot be closed

  插件第一次被打开时, 其关联的, 没有成为程序的一部分的所有的包的init函数将被调用. 插件的main函数不会被调用. 插件只会被初始化一次, 不能被关闭

  因此, 需要手动将init函数改成自己的函数, 统一在so的main包里调用

编译

• 如何编译获得plugin包支持的动态库

  SVCNAME=$1 SVCVER=$2 TIMESTAMP=`date '+%Y%m%d_%H%M%S'` go build -v -buildmode=plugin --ldflags="-pluginpath=${SVCNAME}_${TIMESTAMP}" -o ${SVCNAME}_${SVCVER}.so ${SVCNAME}

  -buildmode=plugin是重要参数

  --ldflags里的-pluginpath的作用是: 每次编译的内部识别路径都是不同的, 避免重复加载的警告

  参考: https://github.com/golang/go/issues/19004

相位技术大规模出现在魔兽世界WLK版本, 现在应用已经广泛应用在各种MMORPG游戏中. 下面对相位技术的做法进行简单归纳汇总

表现分类

副本相位

早期副本的出现, 避免抢怪问题. 所以, 副本其实本身就是一种相位技术. 只不过实现时, 我们一般会将小队和怪物直接预分配在独立的一个副本实例中(所以副本原文也是实例的意思)

分线相位

相位技术还没有正式命名时, 同一个场景, 玩家进到不同的分线看到的玩家不一样, 也是属于相位的一种. 当然, 如果是组队玩家, 服务器默认会分配所有队伍玩家在同一个线(位面)

真相位

副本相位和分线相位其实都是静态相位, 一旦进入, 中途不会有切换或者混合查看的过程. 真相位可以在一个场景中,动态切换相位, 相位内和相位外所以不同

我们常见的真相位表现为: 相位中的角色+玩家+队伍成员

在护送任务时, 还会在上面所见角色中叠加世界中的所有角色, 也就是说, 你和队伍成员可以看到的角色, 其他人看不到, 其他人也看不到你和你的队伍成员

为了清晰的简单的描述, 我为相位创建如下概念与名词

相位客体

表现为除玩家外的角色(怪物,交互物体与相位可见场景)

私有客体

这是最常见的一种相位内角色

• 持有变量

  取PhasingID时,为PhasingTargetID

• 生成规则

  当玩家开启相位后, 在玩家相位内生成的角色为私有客体.

  此时, 将 PhasingTargetID设置为相位生成者的实例ID

• 删除规则

  如果玩家退出相位, 私有客体会存在一段时间或按照需求删除

公共客体

一般指提前放置在场景中, 世界内不可见, 但是能被同相位玩家可见,且同相位玩家都可以互相可见 比如: 只要接了同一个任务的玩家, 都可以看到的NPC

• 持有变量

  取PhasingID时,为PublicPhasingID

• 生成规则

  通过场景编辑器, 放置角色时, 设置其可被观察到的任务ID

  角色被加载后, 将任务ID设置到StaticPhasingID

• 删除规则

  场景删除, 角色删除

相位主体

包含玩家与同队伍玩家

• 开启相位后, 可见私有客体+公有客体

• 队长视为相位主体, 单人时, 自己为队长

• 队伍其他成员共享队长的私有相位客体

• 队伍其他成员根据自己的PublicPhasingID匹配目标对象的PublicPhasingID时可互相可见

• 持有变量

相位开启时, 取PhasingID时, 为角色实例ID

相位关闭时, 取PhasingID时, 为0

PublicPhasingID

可见规则

当两个角色的PhasingID相等时, 主体与私有客体互相可见

当两个角色的PublicPhasingID相等时, 主体与公有客体互相可见

可以通过开关设置, 是否在可见的相位客体基础上, 叠加世界角色(护送任务)

约束

• 玩家同时只能看见1个相位

我们对Golang的结构体变量赋值, 以及单参数函数调用进行反射和native操作的测试

 
package main
 
import (
    "reflect"
    "testing"
)
 
type data struct {
    Hp int
}
 
const AssignTimes = 100000000
 
func TestNativeAssign(t *testing.T) {
 
    v := data{Hp: 2}
 
    for i := 0; i < AssignTimes; i++ {
        v.Hp = 3
    }
 
}
 
func TestReflectAssign(t *testing.T) {
 
    v := data{Hp: 2}
 
    vv := reflect.ValueOf(&v).Elem()
 
    f := vv.FieldByName("Hp")
 
    for i := 0; i < AssignTimes; i++ {
 
        f.SetInt(3)
    }
 
}
 
func TestReflectFindFieldAndAssign(t *testing.T) {
 
    v := data{Hp: 2}
 
    vv := reflect.ValueOf(&v).Elem()
 
    for i := 0; i < AssignTimes; i++ {
 
        vv.FieldByName("Hp").SetInt(3)
    }
 
}
 
func foo(v int) {
 
}
 
const CallTimes = 100000000
 
func TestNativeCall(t *testing.T) {
    for i := 0; i < CallTimes; i++ {
 
        foo(i)
    }
}
 
func TestReflectCall(t *testing.T) {
 
    v := reflect.ValueOf(foo)
 
    for i := 0; i < CallTimes; i++ {
 
        v.Call([]reflect.Value{reflect.ValueOf(2)})
    }
}

性能测试数据

=== RUN TestNativeAssign
— PASS: TestNativeAssign (0.03s)
=== RUN TestReflectAssign
— PASS: TestReflectAssign (0.41s)
=== RUN TestReflectFindFieldAndAssign
— PASS: TestReflectFindFieldAndAssign (9.86s)
=== RUN TestNativeCall
— PASS: TestNativeCall (0.03s)
=== RUN TestReflectCall
— PASS: TestReflectCall (21.46s)

测试评测

• 在结构体变量赋值测试用例中, 我们发现TestReflectFindFieldAndAssign赋值格外的耗时. 分析性能点在FieldByName这个函数上, 我们查了下底层如何实现的:

// FieldByName returns the struct field with the given name
// and a boolean to indicate if the field was found.
func (t *structType) FieldByName(name string) (f StructField, present bool) {
    // Quick check for top-level name, or struct without anonymous fields.
    hasAnon := false
    if name != "" {
        for i := range t.fields {
            tf := &t.fields[i]
            if tf.name == nil {
                hasAnon = true
                continue
            }
            if *tf.name == name {
                return t.Field(i), true
            }
        }
    }
    if !hasAnon {
        return
    }
    return t.FieldByNameFunc(func(s string) bool { return s == name })
}

各位看官必须吐槽用for来遍历获取数据, 但冷静下来分析. 这样做无可厚非.
试想如果reflect包在我们使用ValueOf时使用map缓冲好一个结构体所有字段的访问数据后, 肯定访问指定字段速度会很快
但是, 以空间换速度的需求其实最多满足了1%的需求.
同样的例子是图形API里访问Shader变量的方法, 总是默认使用字符串获取, 速度很慢. 当你想快速访问时, 请提前按需缓存字段
那么, Golang使用的也是这样的思路. 虽然暴力了一点, 但是能够让程序跑对, 性能优化的东西放在之后来做, 缓冲下就可以解决

• 在调用测试用例中, 毫无悬念的, 调用速度很慢
  因此, 我们在平时使用反射时, 尽量偏向于反射变量缓冲存在下的变量赋值或者获取
  而调用的需求尽量减少, 如果有goroutine存在的情况下, 则不必太多担心.

C#

开发效率：Windows下可以通过VisualStudio进行开发，其他平台可以使用MonoDevelop，非常方便

运行效率：JIT的性能优化比较到位，能适应90%性能环境

部署便捷性：可以通过交叉编译生成其他平台的可执行文件，通过mono运行可执行文件

调试便捷性：VisualStudio和MonoDevelop调试均很方便， 还可远程调试

上手度：对C系语言熟悉的几天就可上手

热更新：可以通过DLL方式进行

Web对接：可做，代码比较啰嗦

崩溃处理：可通过try catch捕获错误

网络库编写难度：一般，需注意gc问题

第三方网络库及框架数量：一般

Golang

开发效率：高

运行效率：并发上非常有优势，对CPU利用率比较高，原生运行无虚拟机

部署便捷性：一次编译到处运行，无任何运行库依赖

调试便捷性：实际操作中，单线程挂接调试器可行， 但变量显示不正确，开发期基本采用日志方式进行查错

上手度：语言简单，特性少， 新手1周能贡献代码

热更新：无法进行热更新，语言无法编译为DLL，也不支持DLL加载（linux平台的.so加载忽略不计）

Web对接：非常方便， 代码精简

崩溃处理：崩溃后以命令行方式打印出栈，程序内可以捕获任何崩溃错误并继续运行

网络库编写难度：简单，比C socket更简单

第三方网络库及框架数量：偏少

Skynet(lua+C)

开发效率：基于动态语言的开发初次写比较快，后期维护和重构会耗费一定的时间在查错上

运行效率：基于lua jit的运行效率还是能接受的

部署便捷性：方便， 只有底层修改需要重新编译， 大部分时间只用更新lua文件

调试便捷性：不是很方便，基于日志方式进行查错

上手度：lua语言特性有部分和C系语言有一定差异，基于Actor模型的思想学习，适应需要耗费一定的时间

热更新：类似于Erlang，可精确到函数级的热更新

Web对接：有一些http支持，通过社区慢慢进行完善

崩溃处理：lua天生可以捕获错误

网络库编写难度：自带，无需编写

第三方网络库及框架数量：通过社区慢慢完善

C++

开发效率：编译慢，文件多，通用库少

运行效率：native速度标杆

部署便捷性：编写各类的make门槛较高

调试便捷性：可通过VisualStudio进行Windows平台调试

上手度：2~3年经验的熟手仍然会写出崩溃和泄露代码

热更新：可通过DLL进行

Web对接：代码啰嗦，第三方库少

崩溃处理：Windows下可使用SEH捕获段异常，其他平台只能通过崩溃后进行coredump分析，容错非常差

网络库编写难度：基于asio编写较为简单，但总体看来难度不低

第三方网络库及框架数量：较多

以下是得分

从发文时的项目对这些语言使用率来说，Java，Erlang，C++编写的服务器较多，Golang，JavaScript，C#是第二梯队，Skynet由于上手不是很容易，所以仅有两位数的团队在使用，但总体表现还是比较出色的

对于老团队， C++的服务器工具链和框架已经相对成熟， 完全没必要更换新语言， 只是在对接sdk感觉困难时，可以尝试Golang这些对web有优势的语言进行混合语言开发

对于新团队，开发效率，上手度和部署效率是优先选择的，C#，Golang，JavaScript这些新兴语言会让你事半功倍

对于大规模无需选服的服务器， Skynet的actor模型对扩展会比较容易

对于大公司，好项目，上线后需要通过热更新进行bug修补的，C#，C++，Erlang会是首选

但总的一点， 还是根据团队熟悉度来选择语言，贸然的使用新语言的风险也是很大的

func server() {

    pipe := cellnet.NewEventPipe()

    evq := socket.NewAcceptor(pipe).Start("127.0.0.1:7234")

    socket.RegisterSessionMessage(evq, coredef.TestEchoACK{}, func(content interface{}, ses cellnet.Session) {

        msg := content.(*coredef.TestEchoACK)

        log.Println("server recv:", msg.String())

        ses.Send(&coredef.TestEchoACK{

            Content: proto.String(msg.String()),

        })

    })

    pipe.Start()

}

func client() {

    pipe := cellnet.NewEventPipe()

    evq := socket.NewConnector(pipe).Start("127.0.0.1:7234")

    socket.RegisterSessionMessage(evq, coredef.TestEchoACK{}, func(content interface{}, ses cellnet.Session) {

        msg := content.(*coredef.TestEchoACK)

        log.Println("client recv:", msg.String())

    })

    socket.RegisterSessionMessage(evq, coredef.SessionConnected{}, func(content interface{}, ses cellnet.Session) {

        ses.Send(&coredef.TestEchoACK{

            Content: proto.String("hello"),

        })

    })

    pipe.Start()

}

项目地址: https://github.com/davyxu/cellnet

首先我们来看下

RSA的几个标准用法

非对称加密解密

假设A要把内容传输给B

1. B生成RSA的公钥和密钥, 这是成对出现的, 密钥由B保存, 把公钥告诉A

2. A用B的公钥加密内容, 并把密文内容传输给B

3. B用密钥解密

验证

证明某个内容是你发的, 而不是被别人冒名顶替, 例如git的push中就带有这个功能

假设A有内容,  B要验证内容确实由A发出

1. A生成公钥和密钥

2. A将内容做一个hash, 把hash码用自己的密钥加密并把这段密文发给B

3. B用A的公钥对密文进行验证, 即可确认密文是否由A发出

可以看出, 两种用法都是典型的非对称用法

但PP助手却干了件神奇的事情:

非对称当对称算法加解密

在PP SDK官方文档里, 我们找到了PHP语言的验证方法, 方法里使用了这样一个API

openssl_public_decrypt

从官方文档看得出这个使用openssl的算法库

类似的, 还有Java, C++, Python语言的处理方法

其中, C++也是用的openssl, Python则是需要预编译C库，在Ubuntu下需要手工patch M2Crypto的_ssl.c文件.

先不说这些非正规的编译,patch方法会造成多大的问题, 单就这个用公钥解密就很蛋疼

从之前的RSA算法中了解, 只有对公钥进行验证的方法, 也就是只能得到是还是不是的结果. 但PP的SDK则要求必须用公钥解密…

解出的数据为一段json, 以对比是否有订单篡改.

那么这种做法就等效于, 用最简单的异或+一个公钥进行订单加密, 然后同样用这个公钥进行解密

只不过用RSA感觉很高级…

这种做法一旦公钥在PP助手服务器或者玩家的开发服务器, 甚至源代码泄露, 那么马上就有很大的伪造订单的危险

我把这个做法发给朋友看, 他们说, 其实PP助手的开发者只管用了RSA, 跟传输不是明文就好了, 至于什么信息安全, 都是屁!

在我们的游戏项目中使用的golang服务器开发方式如下

1.多线程逻辑

2.同步阻塞. 也就是说, 每个人一个线程(goroutine), io线程=逻辑线程

这种方式的优点:

1. 同步阻塞方式与人的思维方式类同

2. 逻辑处理性能有一定提升

在大规模使用这种模式编写逻辑后, 我们发现了这种模式只有1个缺点: 编写者需要处理多线程关系

但这本身确实直接致命的, 回想C++时代, 多线程处理时, 调试重现的困难… 脑补景象太惨不敢直视

单线程+异步多进程模型

在C++时代, 我曾经编写过一套asio的C++服务器框架. 采用io多线程, 逻辑单线程, 依赖着C++高性能的优势, 让开发便捷简单且无需关心线程问题.

那么到了golang时代, 为什么不能试下单线程异步多进程方式来编写逻辑?

与多线程同步阻塞对比后, 我们发现, 两者优缺点互补. 那这就回到了领域选型问题了. 对于游戏服务器需要的上手简单, 开发便捷, 压力降低(非MMO)这些特点来说, 单线程异步多进程再合适不过了

那么, 我们在用golang编写单线程异步多进程服务器应该注意哪些点呢?

1. socket处理完全封装, 只通过channel抛出到逻辑线程排队处理

2. 数据库, rpc及其他io处理, 一律改为异步回调模式, 不使用同步接口

3. 玩家存盘提交数据可以考虑复制并提交到存盘线程方式, 提高性能.

4. 采用多进程架构, 比如设网关进程, 把io压力分散到进程中

5. 逻辑编写中, 不允许使用go开线程及channel, 有需要提高性能部分需要单独编写

Actor模型的痛

cellnet在开发时本来考虑使用actor模型来进一步简化多线程逻辑的麻烦, 经历了一段时间的原型开发后, 发现了一些问题, 列举如下:

1. golang的强类型不适合actor模型这种经常需要动态生成各类消息的模型, 但skynet(C+lua)/erlang就有天生优势

2. actor模型本身不是万能的, 不能解决所有需求, 特别是游戏

3. actor模型理解到应用有一定的难度. 本身还需要搭建框架, 上手复杂

总之, 看过一些erlang及skynet的用例, 没有应用的很纯正且成熟的成功actor模型案例, 从传统socket服务器框架跨越到actor模型会扯到蛋, 因此, 后期cellnet会考虑回归到成熟的socket服务器框架. 把架构做到简单上手, 高扩展上.

概述

游戏客户端采用Cocos2dx-Lua的纯Lua编写逻辑, 服务器采用Golang作为开发语言

游戏类型类似于COC,因此无需选服. 需要使用大服务器架构进行处理

数据库

采用Mongodb做持久存储, redis做跨服通信数据交换

使用UCloud的云技术, 省去了烦人的运维工作

通信及协议

客户端和服务器通讯使用HTTP短连接, 基于json的数据封包协议

服务器间大量使用Golang自带的json+rpc进行通信

服务器类型

服务器类型大致分为逻辑服务器,战斗服务器, 中心服务器

逻辑服务器

逻辑服务器负责日常逻辑及公共逻辑处理(好友, 公会)

1个逻辑服务器对应一个区, n个区均使用Ucloud云Mongodb进行数据存储

战斗服务器

战斗服务器是一个集群, 集群会返回一个负载最低的服务器返回使用

战斗服务器通过cgo技术与客户端C++/lua的战斗逻辑进行逻辑复用, 在此技术上进行

战斗逻辑的校验

中心服务器

客户端登陆前, 在中心服务器这里获得可登陆的逻辑服务器地址, 同时做一个负载均衡

短连接

评价

由于操作系统的技术趋于稳定, 同时, 手游的弱交互型导致的游戏架构趋于简单. 因此网络负载不再是游戏服务器技术的瓶颈. 从经验看来, 游戏服务器技术, 更重要的是还是看数据库的选型及处理方式. 

虽然Mongodb的性能上不如内存数据库. 但是从存储安全性上要比个人搭建的内存数据库简单, 安全

外加上云技术的引用, 性能的瓶颈和运维的技术复杂度迎刃而解

Redis用于跨服数据交互那是再好不过的数据中介了, 保证速度和稳定性, 绝对不是造轮子能比拟的

短连接在手游上处理起来比长连接简单一些, 无需做断线重连. 服务器的底层也是由Golang的框架库保证质量的. 因此负载毫无问题. 服务器对内及对外均使用json进行数据交换, 简化了协议处理. 也方便了调试

json rpc的性能损耗对于整个逻辑的处理来说均可以忽略不计

我们的项目一直使用MySQL作为数据库. 无论是从C++的服务器, 还是到Golang服务器. 当年搞服务器时, 看大部分人都是用SQL(MySQL/SQLServer), 而Mongo感觉像邪教一样, 再加上服务器还是Linux比较正统, 所以果断选了MySQL.

刚开始感觉,游戏服务器的数据存储其实应该是蛮神圣的过程. 那么多的数据, 需要按照MySQL一样分表, 分字段存储, 为了查询, 还要乖乖的学一下SQL的语法

就这么折腾了几年. 在云DB的蒙蔽下, 一直认为MySQL就是做游戏服务器存储的专业技术. 分布式和存储压力一定交给云DB来做. 直到真正试了下NoSQL在游戏服务器开发里的思路.

用了Golang, 才发现同步写逻辑是多么的优雅.

用了NoSQL系列的数据库, 才意识到: 游戏服务器的数据存储和游戏服务器的存盘两个概念差异其实蛮大的.

MySQL中, 背包其实跟角色完全没有关系, 只是通过1个角色id映射过去, 人为的割裂了数据的关联性. 还硬生生的整出个概念叫结构化查询让你学

NoSQL中, 只是把数据库当成是存储点, 每个角色的数据是完整的一块. 里面怎么存随你便. 每个角色通过id来查询, 其他都没有了

于是乎, 游戏开发变得异常简单. MySQL角色进门查询4~5次才能搞定要的数据.而NoSQL一口气全查出来, 存盘也无需增量, 直接存盘就可以了

所以现在觉得, NoSQL的思路对于游戏服务器存储来说简直是完美的!

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

NoSQL数据库方案对比

NoSQL下实现方案很多, 游戏常用的就这么3家: mongo, redis, memcached

下面说下优缺点

mongo

磁盘映射内存数据库

value为document类型, 基于BSON的value序列化

应用场景:

适合多写少读, 例如日志和备份

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

redis

内存数据库

单核

value限制512M

多种value类型, 游戏用途使用私有的序列化协议(例如protobuf)

支持落地(bgsave)

用户: 新浪, 淘宝, Flickr, Github

应用场景: 适合读写都很高, 数据处理复杂等

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

memcached

内存数据库

多核

value限制1M

不支持落地(持久化)

用户: LiveJournal、hatena、Facebook、Vox

应用场景: 动态系统中的缓冲, 适合多读少写

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

个人评价

memcached 适合网页缓冲, 游戏里很少有使用. 目前只有腾讯云支持云memcached

redis非常适合游戏的内存数据库, 但是落地策略会比较复杂, 需要具体分析, 可以参考后面的链接看下云风怎么处理这个问题

mongo数据库在早期还是非常不错的NoSQL的数据库. 工具比较方便, 可视化. 但是随着近年来游戏的并发度越来越高, 所以为了一次到位, 很多人还是选择了redis

下图参考自知乎问题. 链接在后面有提示, 若侵权请联系删除

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

参考链接:

    谈谈陌陌争霸在数据库方面踩过的坑( Redis 篇)

http://blog.codingnow.com/2014/03/mmzb_redis.html

转载请注明: 战魂小筑http://www.cppblog.com/sunicdavy

Memcache,Redis,MongoDB（数据缓存系统）方案对比与分析

http://blog.csdn.net/suifeng3051/article/details/23739295

http://www.zhihu.com/question/31417262

回想了下, goroutine的调度规则: 1.4之前, 在碰到syscall时, goroutine会被调度并处理. 1.4后, 只要有函数调用时, 均会进行一次调度. 密度比以前增加了, 更加接近真线程的处理.

根据这个原理, 问题应该出现在服务器底层没有给系统提供调度机会的点上. 我们的服务器通过一个bool型的chan进行阻塞, 让服务器维持阻塞进行消息处理不退出. 但是最近为了在windows下提供命令行支持, 增加了一些代码, 如下

   1:  func WaitForExit() {

   2:   

   3:      if len(peerMap) == 0 {

   4:          log.Println("no peer running, exit!")

   5:          return

   6:      }

   7:   

   8:      // 命令行功能只在windows下启用

   9:      if runtime.GOOS == "windows" {

  10:          reader := bufio.NewReader(os.Stdin)

  11:   

  12:          var running bool = true

  13:   

  14:          go func() {

  15:              select {

  16:              case <-exitChan:

  17:                  running = false

  18:              }

  19:          }()

  20:   

  21:          for running {

  22:              data, _, _ := reader.ReadLine()

  23:              command := string(data)

  24:   

  25:              dispatchConsoleCommand(command)

  26:          }

  27:      } else {

  28:          // Linux环境

  29:          <-exitChan

  30:      }

  31:   

  32:  }

我暂时屏蔽了新加的这套功能, 维持<-exitChan, 问题马上解决

结合前面的猜测, 我估计在reader.ReadLine()函数内, 没有给底层提供调度的机会, 导致其他goroutine无法运行, 造成服务器卡死

技术讨论群:  309800774 欢迎golang爱好者加入, 纯技术研讨

基于C/C++游戏服务器框架总体设计的还是不错的, 兄弟们总体使用效果都是好评. 因为在技术上喜欢"偷懒", 所以在很多设计上, 都是力求简单, 高效(开发效率).

基于任务的异步DB查询系统, 带多重异步的同步

代码示例:

   1:   

   2:  void BatchQueryPlayerInfo( uint32 ClientID, const std::string& AccountName, int64 CharID )

   3:  {

   4:      GDBExecutor->Commit

   5:          (    

   6:          dynamic_cast<DBDataTask*>( (new DBQueryCharInfo(  ClientID, CharID ) ) 

   7:          ->LinkAtomTask( new DBQueryQuest( ClientID, CharID ) )

   8:          ->LinkAtomTask( new DBQuerySkill( ClientID, CharID ) )

   9:          ->LinkAtomTask( new DBQueryHero( ClientID, CharID ) )

  10:          ->LinkAtomTask( new DBQueryAccountInfo( ClientID, AccountName ) )

  11:          ->LinkAtomTask( new DBQueryEquip( ClientID, CharID ) )

  12:          ->LinkAtomTask( new DBQueryObject( ClientID ,CharID ) )

  13:          ->LinkAtomTask( new DBQueryLevel(ClientID, CharID))

  14:          ->LinkAtomTask( new DBQueryChapter(ClientID, CharID))

  15:          ->LinkAtomTask( new DBQueryActivity( ClientID, CharID ))

  16:          )

  17:          );

  18:   

  19:  }

这段主要处理玩家在登陆时, 需要从DB查询大量的不同分类的数据. 为了保证效率, 我让每个Task并行执行, 然后通过一个机制, 让所有任务完成后, 回调第一个任务的一个函数. 这样就无需手动实现很多粘合代码, 避免了反复调试和错误

基于protobuf反射机制的语句自动合成

   1:  DBUpdateCharInfo::DBUpdateCharInfo( int64 CharID, const std::string& Buffer )

   2:  {

   3:      char buffer[256];

   4:   

   5:      sprintf( buffer, "update tb_char set $FIELD$ where charid = %lld;", CharID );

   6:          

   7:      ExecuteCommand( buffer, Buffer, dbopr::FET_Equation );

   8:  }

这段就是一个典型的DB任务, 构造函数提供了CharID和一个由结构体序列化好的buffer, $FIELD$字段, 是通过反射根据Buffer内容, 自动填充字段

这段例子中, $FIELD$可以填充为 hp=100, mp=100之类的. 自动填充避免了因为添加字段的到处添加代码, 还需要调试, 容易搞错

配置系统概念

基于同一个配置系统, 分层实现不同的需求. 更简单的说, 解决的1个实际问题是:

自己改了配置文件中的ip, 上传svn后, 覆盖了别人的配置, 很多人的解决方法都是, 本地配置不提交. 但同时问题又来了:

当配置中有别人新加的系统配置, 怎么保证每个人都能更新到?

上线后, 服务器交付运维, 他们会对配置有一定程度的修改, 这个时候怎么合并程序配置和运维配置?

其实对于冲突的需求, 只要对系统进行分层就可以解决问题,我的处理方式:

配置分为:

全局配置: 所有服务的总体配置

单服务配置: 本服务的配置, 涉及网络及逻辑

本地配置: 这个配置每个人一份, 不上传SVN

命令行配置: 格式和前面的一致, 这块就可以通过运维进行配置

总体结构其实就是OO的派生概念, 下层可以覆盖, 修改上层的配置

服务器互联及识别框架

基本功能: 基于一些简单的配置就可以将多台服务器, 同种类的不同服务器互相连接起来, 断线自动重连.

服务器连接后, 所有服务器可知晓并可自动按需连接

逻辑端也很方便的进行广播或者单独发送等

也就是说, 每个服务器的连接和接受端都是带识别名称或id的.

后面觉得这套东西实在是做的复杂, 多整出一台中心服务器来做. 但好歹框架稳定下来了, 也就好了.

基于lua的服务器web后台框架

思想是很不错的,  C++ 配合lua本身绝对是个失败

问题出在web处理,本身都是一个同步阻塞过程, 而这个后台框架是异步方式来做, 所以特别别扭

不过比起以前的本地GM系统, 这块的设计是伟大的进步

现在正在设计基于golang的服务器框架, 基本框架已经完工, 等待编写逻辑后的实战测试

以上的很多思想在golang的服务器框架都有改进, 特别是golang本身做web也是优秀的, 外加martini这种牛X框架, 更是水到渠成

如果你对服务器框架设计有特别的认识, 或者想碰撞思想, 可以加博客群 309800774或者我的qq: 20998333讨论

但默认因为找不到git而报错。 解决方法如下：

在http://git-scm.com/downloads下载对应平台git

在LiteIDE的查看->编辑环境变量中， 修改PATH， 加入git路径。例如

PATH=c:\mingw64\bin;%GOROOT%\bin;c:\Program Files (x86)\Git\bin;%PATH%

再按下Get键， 第三方包就会自动更新了

按照作者的安装方法在天朝行不通的, 原因你懂的

因此进入这个链接, 点击右边的Download ZIP下载快照包

下载好后放到你的GOPATH指定路径, 整理路径如下

github.com\aarzilli\golua\

其下的目录如下

example\
    lua\
    LICENSE
    README.md
    TODO

然后准备lua5.1的开发包

lua-5.1.4.tar.gz

还有2个第三方依赖包

readline-6.2.tar.gz

ncurses-5.9.tar.gz

直接configure –> make install 装好

go env确认你的GOPATH已经指向你的开发目录

golua默认使用cgo进行编译, 可能会报错, 修改lua.go的cgo定义如下

#cgo linux,!llua,!luaa LDFLAGS: -llua -lm –ldl

进入$GOPATH\src\github.com\aarzilli\golua\lua

执行go install

完成

目前Go编译器是C写的，是时候换成Go啦。

背景

“gc"Go工具链来自Plan 9编译器的工具链。组装器、C编译器和链接器基本没变。Go的编译器(cmd/gc,cmd/5g,cmd/6g,cmd/8g)是配合工具链写的新的C程序。

项目起始时，用C而不是Go写编译器有很多好处。突出的比如，首先，那时候Go还不存在，没法儿写编译器。而且实际上，就算存在，也会经常有明显的不兼容的变化。用C不用Go可以避免初始和持续开发导致的问题。然而如今Go 1已经稳定，所以这些持续的问题减少了很多。

持续开发的问题已经消除，为了让Go实现的编译器比C更有吸引力，另一些工程问题出现：

• 写正确的Go代码比写正确的C代码更容易。

• 调试错误的Go代码比调试错误的C代码更容易。

• 使用Go编译器需要对Go有一定理解。而用C编译器还需要一定理解C。

• Go使并发执行比C更方便。

• Go有更好的标准支持模块化，自动重写，单元测试和性能分析。

• Go比C更有趣(fun)。

基于以上理由，我们相信是时候用Go写Go编译器啦。

计划设想

我们打算用自动化翻译工具来用Go重写现在C的编译器。这个翻译需要一些阶段，将从Go 1.3开始持续到未来的发行版。

第一阶段。开发和调试一个自动化翻译工具。这可以在日常开发时同步进行。而且，人们还可以在这个阶段为C编译器继续改进。这个工具工作量很大，不过我们有信心完成这个特殊使命的工具。有许多C的观念没法儿直接转换成Go；macros(宏)，unions(联合，共用体,)，bit fields(位域)可能最先考虑。比较幸运（不是巧合），这些功能功能用的少，都会被翻译掉。指针运算和数组也需要一些转换工作，尽管编译器里很少。编译器里主要是tree(树)和linked list(链表)。翻译工具会保留注释和C代码的结构，所以翻译后的代码和当前的编译器代码一样可阅读。

第二阶段。用翻译工具转换C代码到Go，并删除C源码。这时我们已经开始翻译，但是Go还是运行在C编译器上。非常乐观的，这可能发生在Go 1.3。不过更可能是Go 1.4。

第三阶段。使用一些工具，可能来自gofix和the Go oracle，拆分编译器到包，清理和文档化代码，添加适当的单元测试。这是编译器会是地道的Go程序。目前打算在Go 1.4实现。

第四a阶段。使用标准的分析和测试工具优化编译器的CPU和内存使用。可能要引入并行。如果真这样，Race Detector(Go的并行竞争检测工具,)会有很大帮助。这目标在Go 1.4，可能部分会延后到1.5。基本的优化分析会在第三阶段完成。

第四b阶段。（和四a几段同时进行）当编译器依照明显的界限分割成包之后，需要明确引入一个中介码，在结构无关的无序树(Node_s)和结构相关的有序链表(Prog_s)之间。这个中介码应该不依赖整体架构，但是包含准确的执行顺序信息，可以用于有顺序但是结构无关的操作的优化，比如清理多余的nil检测和出界检测。这些过程基于SSA（静态单赋值），你可以从Alan Donovan的 go.tools/ssa 包中了解更多。

第五阶段。替换go/parser和go/types到最新（全新）的版本。Robert Griesemer参考现在的经验，讨论了设计新的parser和types的可能。如果联系他们到编译器后端，相信对设计新的API有很大帮助。

自展（Bootstrapping）用Go语言实现的Go的编译器，从一开始就要考虑如何自展。我们考虑的规则就是Go1.3编译器必须由Go1.2编译，Go1.4的编译器必须由Go1.4编译，以此类推。

这时，我们就有了一个清晰的流程来生成当前的程序：编译Go1.2的工具链（由C编写），然后使用它编译Go1.3的工具链，以此类推。这里需要一个脚本来做这个事情，来保证只会消耗CPU的时间而非某个人的时间。这样的自展，每个机器只会做一次，Go1.x的工具链将会在本地保留，并在执行all.bash来编译Go1.(x+1)工具链的时候被再次使用。

显然，随着时间的推移这种自举方式是不充分的。在后面的多个版本被发布之前，为编译器写一个后端来生成C代码也许是一个更有意义的事情。这些C代码不要求效率或可读性，只要正确即可。这些C代码将会被签入，就像我们签入由yacc生成的y.tab.c文件一样。这样，自展过程就会变成：先用gcc编译C代码生成一个自展编译器，然后使用这个自展编译器来编译真正的编译器。类似于另一个自展过程，这个自展编译器将会在本地保留，并在每次执行all.bash的时候重复使用（不用重新编译）。

替代选择还有一些比较明显的替代方案，需要我们说明一下为什么放弃了这些选择。

从一开始写一个编译器。现在的编译器有一个非常重要的特征：他们能够正常工作（或者其至少能够满足所有用户的要求）。尽管Go语言比较简单，但是编译器中有很多细微的细节优化和改写，直接丢弃10或数年的在这上面的努力是比较愚蠢的。

对编译器进行人工翻译。我们已经以人工的方式翻译了一小部分C/C++代码到Go语言了。这个过程是枯燥而且易错的，且这些错误非常的细微及难以发现。相反，使用机械翻译会形成一些比较一致的错误，而这些错误是易于发现的；而且不会因为枯燥的过程开小差。Go编译器的代码明显的比我们翻译的代码多很多：超过60,000行C代码，机械翻译会使这个过程容易一些。就像Dick Sites在1974年说的一样：“相比写程序，我宁愿写一个程序来帮我写程序。“ 使用机械来翻译编译器也方便于在准备好切换之前，我们可以继续开发完善现有的C程序。

只翻译后端并链接到go/parser和go/types.从前端传给后端的数据结构所包含的信息中，go/parser和go/types所能提供的除了API就没其他的东西了。如果使用这些库来替代前端，需要写代码来转换go/parser和go/types所能提供数据结构到后端，这是一个非常宽泛且易出错的工作。我们相信使用这些库是有意义的，但更明智的是，等到将编译器代码调整的更像Go程序，分成确定边界的、包含说明文档和单元测试子包之后再使用。

放弃现有的编译器，使用gccgo（或者go/parser + go/types + LLVM, …）。现有的编译器是Go语言显得比较灵活的一个重要组成部分。如果尝试使用基于大量代码的GCC或LLVM来开发Go程序，感觉会有碍到Go语言的灵活性。另外，GCC是大量C代码（现在有部分C++）、LLVM是大量C++代码的程序。以上列举的、用于解释不使用现有编译框架代码的几个原因，也都适用于更多的类似的代码库。

C语言的长期使用

临近结束，这个计划还留下了由C写成的Plan9的工具链的一部分。在长期发展中，还是将所有的C从代码树排除掉比较好。本章节推测了一下这件事将会如何发生，但不保证其指定会发生或者按照这种套路发生。

运行时包(runtime)。 runtime包的大部分都是用C写成，基于一些同样的原因，Go编译器也是用C实现。但是，runtime包远比编译器的代码量要小，且它现在已经是用Go和C混合编写。将C代码转换为Go代码时，一次转化一部分貌似也是可行的。其中，主要部分有：调度器（scheduler），垃圾回收（the garbage collector），散列映射表（hash map）的实现，和channel的实现。（这里Go和C代码混合的很融洽，是因为这里使用的6c而不是gcc来编译的C代码。）

C编译器。 Plan 9的C编译器本身就是用C写成，如果我们要从Go包实现里面移除所有的C代码，那么我们将移除这些编译工具：“go tool 6c”等等，另外，.c的文件也将不被支持出现的Go包的目录里面。我们应该提前声明这样的计划，以便使用C的第三方包有时间去移除这类C代码的使用。（Cgo，由于使用了gcc来替代6c，所以它仍然可以作为一个途径来在Go包中使用C实现部分功能。）在Go1的兼容性文档中没有包含工具链修改的描述，也就是说去掉C编译器是被允许的。

汇编器。 Plan 9的汇编器也是用C实现的，但这个汇编器只不过是一系列解析树组成的简单解析器，这使得不论手动还是自动将它翻译成Go语言都比较简单。

连接器。 Plan 9的连接器也是由C写成。最近的一些工作，已经将大部分的连接器工作放到的编译器中，而且，也已经有个计划将剩余的部分重写成一个新的、更简单的Go程序。转移到编译器的部分连接器代码，现在需要随着编译器的原有代码一起进行翻译。

基于Libmach的工具: nm, pack, addr2line, 和objdump。 Nm现在已经使用Go语言重写。Pack和addr2line可以任何一天被重写。Objdump现在依赖于libmach的反汇编器，但这些转换为Go也是比较简单的，不论是使用机械还是人工翻译。所以基于这几点，libmach本身将来也可以被移除。

来源: http://www.oschina.net/translate/go-1-3-compiler-overhaul

英文来源:https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1

搜索到gocode的开发页面https://github.com/nsf/gocode  结果发现nsf这家伙居然也是luaBridge的作者.

下载最新的gocode代码, 解压后, 编译:

windows下命令行

go build gocode.go autocompletecontext.go autocompletefile.go client.go config.go cursorcontext.go decl.go declcache.go formatters.go os_windows.go package.go ripper.go rpc.go scope.go server.go utils.go

linux下, 只需要将os_windows.go换为os_posix.go即可

编译完成后, 将可执行文件gocode覆盖到liteIDE下的同名文件, 杀掉gocode进程后重启liteIDE即可

error: missing binary operator before token "("

根据老外的描述, boost中的BOOST_PP_ITERATION_FLAGS从1.49版本后发生了一些变化.

在git找到一个patch, 链接在此

以下简单描述

修改call_function.hpp, call_member.hpp及wrapper_base.hpp

去掉#elif BOOST_PP_ITERATION_FLAGS() == 1

更换为

#else

#if BOOST_PP_ITERATION_FLAGS() == 1

然后在源码底部加一个#endif即可

在编写本文前, 笔者使用过诸如libunwind等库进行错误时堆栈打印, 但是其本身由于需要引用第三方库, 使用还是稍微麻烦.

经过Google后, 居然找到一篇好文, 其通过捕获SIGSEGV信号, 并迫使程序进入gdb调试阶段, 利用gdb强大的调试功能可以进行各种错误跟踪, 此法已与Windows下程序崩溃后弹出VC调试几乎接近.

我在此文基础上, 扩展了其通用性及便利性

1. 使用gdb的 -ex参数, 在挂接程序后, 执行bt指令打出程序堆栈

2. 将信息重定向到自定义的文件,在多进程都需要进行后台输出时带来更大的灵活性, 同时也解决了gdb只能在前台调试的问题

代码如下

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <string.h>

void dump(int signo)
{
        char buf[1024];
        char cmd[1024];
        FILE *fh;

        snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());
        if(!(fh = fopen(buf, "r")))
                exit(0);
        if(!fgets(buf, sizeof(buf), fh))
                exit(0);
        fclose(fh);
        if(buf[strlen(buf) - 1] == '/n')
                buf[strlen(buf) - 1] = '/0';
        snprintf(cmd, sizeof(cmd), "gdb %s %d -ex=bt > ./a.txt", buf, getpid());
        system(cmd);

        exit(0);
}

在服务器开启时,添加 signal(SIGSEGV, &dump ); 进行信号处理挂接即可

引用: http://blog.csdn.net/kakaka2011/article/details/6597857  作者: kakaka2011

”After a successful async_read_until operation, the streambuf may contain additional data beyond the delimiter. An application will typically leave that data in the streambuf for a subsequent async_read_until operation to examine.”

意思是, streambuf中并不一定是到分隔符前的所有数据, 多余的数据可能一样会在streambuf中. 也就是说, 还需要自己再次处理一遍数据...

动手呗, async_read_until看似就是一个废柴, 底层已经费了很多CPU在逐字符与分隔符的匹配上, 抛上来的数据居然还是半成品.

代码如下, 测试通过, 但是实在很费解为啥非要再做一次..

          boost::asio::streambuf* SB = SBP.get();

            // 访问缓冲
            const char* Buffs = boost::asio::buffer_cast<const char*>( SB->data() );

            uint32 DataSize = 0;
            for ( uint32 i = 0; i < SB->size(); ++i )
            {
                const char DChar = Buffs[i];

                // 这里需要自己判断字符串内容, read_until的文档里这么说的
                if ( DChar == '\0' )
                {
                    DataSize = i;
                    break;
                }
            }

            if ( DataSize > 0 )
            {
                // 取成字符串
                std::string FullText( Buffs, DataSize );
                
                // 消费
                SB->consume( DataSize );                

                mWorkService->post(
                    boost::bind(&AsioSession::NotifyReadString,
                    shared_from_this(),
                    FullText )
                    );

            }

  另外, 为了保证输入性安全, 可以在streambuf构造时加一个最大一个读取量, 超过此量会返回报错, 避免了缓冲区被撑爆的危险

最近遇到DB服务器中报出一个MySQL的错误:Commands out of sync; you can't run this command now,2014

查阅很多代码, 解决方法都是使用C接口的方式, 模仿其解决方法,在MySQL++中找到了比较好的解决方案:

方案A: 清空每次未使用的记录

for (int i = 1; DataQuery.more_results(); ++i)
{
   DataQuery.store_next();                
}

其中 DataQuery类型为mysqlpp::Query

方案B: 对于存储过程中,使用了多个select语句返回同样的列结果, 就需要使用以下语句

static void print_multiple_results(Query& query)

{

    // 执行查询并输出结果表

 StoreQueryResult res = query.store();

 print_result(res, 0);

 for (int i = 1; query.more_results(); ++i) {

  res = query.store_next();

  print_result(res, i);

 }

}

参考文章:http://hi.baidu.com/freeknight/item/ea9fd88e7d291f854514cf43

传统的服务器/客户端版本发布流程都需要经历以下流程:

1. 获取代码

2. 编译代码

3. 将配置,二进制文件, 资源打包

4. 挂接远程服务器磁盘拷贝打包文件

5. 远程操作解压打包文件

6. 修改设置,指向最新版本

7. 重启服务器

此流程繁琐,重复且无聊, 同时, 由于网络带宽,网速等约束, 每次若使用完整包发布,传输起来非常吃力

本文讨论的外网服务器由于安全性要求,禁止root登录,只能用普通帐号登录或传输后, 提权为root继续进行以上操作, 因此rsync的使用受到严重限制

即便使用Windows下的同步软件, 也几乎不可能.

HG特性及优势

HG作为一个优秀,小巧的跨平台代码管理软件的特性,正好能解决以上问题, 主要特性:

1. 安装简便, 可以使用代码直接安装

2. 利用本地映射版本可以对新版本做差异比较

3. 增量包传输, 100%同步, 本地文件删除后, 远程文件也会同步删除

4. 传输压缩

5. 增量包可以打包为patch进行离线更新

6. 可以恢复到任意版本, 提交版本有据可查

以下部署系统以CentOS为基础, 其他系统类似

本文来自战魂小筑的博客http://www.cppblog.com/sunicdavy 转载请注明来源

为远程服务器安装HG

安装依赖库

yum install python-devel

获取HG源码

wget http://mercurial.selenic.com/release/mercurial-2.1.tar.gz

tar zxvf ./mercurial-2.1.tar.gz

编译安装

make all

make install

hg debuginstall

使用HG同步数据

创建仓库

找到你需要同步的目录,进入目录

执行

hg init

vi .hg/hgrc

添加以下内容,让这个仓库支持外部push

[ui]

username=服务器提交后看到的用户名

[web]

同步

vi /etc/sysconfig/iptables

添加HG服务的8000端口

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 8000 -j ACCEPT

开启仓库同步服务

hg serve

本地机器同样找到文件夹,创建仓库

hg init

以后每次需要同步时,使用命令,或者乌龟HG的界面工具拉取服务器数据即可

hg pull http://服务器地址:8000

版本提交方法与HG日常使用类似, 这里不再阐述

离线更新

对于某些服务器深处防火墙或者安全登录后方,不能直接开启8000端口的情况

可以使用hg导出一个patch, 传输到远程服务器, 使用hg import PATCH 即可

[root@localhost bin]# ldd wkcenter
./wkcenter: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by ./wkcenter)
./wkcenter: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./wkcenter)
./wkcenter: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.9' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.7' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.8' not found (required by ./wkcenter)
./wkcenter: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./wkcenter)
        linux-gate.so.1 =>  (0xffffe000)
        liblog4cpp.so.4 => not found
        libprotobuf.so.7 => not found
        libboost_filesystem.so.1.48.0 => not found
        libboost_system.so.1.48.0 => not found
        libboost_thread.so.1.48.0 => not found
        libboost_program_options.so.1.48.0 => not found
        libunwind-x86.so.7 => not found
        libluabind.so.0.9.0 => not found
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x008ae000)
        libm.so.6 => /lib/libm.so.6 (0x0044b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00476000)
        libc.so.6 => /lib/libc.so.6 (0x002c1000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x0041d000)
        librt.so.1 => /lib/librt.so.1 (0x00440000)
        /lib/ld-linux.so.2 (0x002a2000)

上面红字部分表示glibc及glibcxx库依赖不正确. 本人使用的Linux编译版本为Mint 11(基于Ubuntu), 一般Ubuntu发行版的glibc配备非常高. 但是上文中的发布的Linux版本为CentOS 5.8

使用/lib/libc.so.6 查看libc版本为2.5, 远远低于开发环境的2.11

GNU C Library stable release version 2.5, by Roland McGrath et al.
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.1.2 20080704 (Red Hat 4.1.2-51).
Compiled on a Linux 2.6.9 system on 2012-02-21.
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        GNU libio by Per Bothner
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

由于Linux操作系统的特有elf加载顺序. (可以参考此文). 虽然可以很大程度上解决Windows早期版本的dll hell问题, 但是给部署带来了很大难度

一般常见的解决方法是, 找到一个与目标Linux版本及glibc版本一致的Linux, 将代码及依赖包放在之上编译, 完成后再发布.这种方法与Linux下常见软件安装方法类似. 但是对于商用服务器部署步骤来说未免繁琐, 安全性低.

还有一种方法,使用静态链接. 将所有可执行文件文件依赖的静态库, 系统库,全部静态链接到可执行文件中,可以一次性解决这个问题

步骤:

    1. 在gcc链接命令行中添加-static -static-libgcc -static-libstdc++

    2. 将第三方依赖库打开静态链接开关, 将原来链接.so的库,全改为链接.a

    3. gcc对链接库顺序很敏感, 链接库顺序需要按照从前至后为:  项目产生的静态库 > 第三方库静态库 > 系统静态库

    4. 链接时, 若有未解决的symbol, 可以尝试在最后添加-lpthread及-lrt解决

在发布版本Linux上运行可能遇到的问题:

terminate called after throwing an instance of 'std::runtime_error'

what(): locale::facet::_S_create_c_locale name not valid

解决方法: 执行之前运行export LC_ALL="C"

ServicePath=/usr/local/bin

ServiceList=(
"wkcenterd --toc /home/davy/dev/kaze/Config/CenterService.toc --logfile /tmp/centerd.log"
"wkagentd --toc /home/davy/dev/kaze/Config/AgentService.toc --logfile /tmp/agentd.log"
)

StartAll()
{
    for((i = 0;i<${#ServiceList[*]};i=i+1))
    do

     echo "start:" $ServicePath/${ServiceList[i]}
     $ServicePath/${ServiceList[i]} > /dev/null &

    done
}

StopAll()
{
    for((i = 0;i<${#ServiceList[*]};i=i+1))
    do

     echo "stop:" $ServicePath/${ServiceList[i]}
     svcname=`echo ${ServiceList[i]} | awk '{print $1}'`
     killall $svcname > /dev/null

    done
}

RestartAll()
{
    StopAll
    StartAll
}


InstallService()
{
    svcname=`basename $0`
    chmod +x $svcname
    cp $svcname /etc/init.d
    ln /etc/init.d/$svcname /etc/rc3.d/S03$svcname
    ln /etc/init.d/$svcname /etc/rc0.d/K03$svcname
    chkconfig --add $svcname
    chkconfig $svcname on
    chkconfig --list | grep $svcname
}

UninstallService()
{
    svcname=`basename $0`
    chkconfig --del $svcname
    rm -f /etc/init.d/$svcname
    rm -f /etc/rc3.d/S03$svcname
    rm -f /etc/rc3.d/K03$svcname
}



case "$1" in
    start)
    StartAll
    ;;
    stop)
    StopAll
    ;;
    restart)
    RestartAll
    ;;
    install)
    InstallService
    ;;
    uninstall)
    UninstallService
    ;;
    *)
           echo "Usage: service $EXEC {install|start|stop|restart|uninst}"
       exit 1
esac
 
exit $? 

这里是一个Shell可以将依赖列表中的文件拷贝到指定目录

deplist=$( ldd $1 | awk '{if (match($3,"/")){ print $3}}' )
cp $deplist $2

代码解释: ldd导出列表, 这个列表打印出来很丑

linux-gate.so.1 =>  (0x00ed2000)
    liblog4cpp.so.4 => /usr/local/lib/liblog4cpp.so.4 (0x00657000)
    libprotobuf.so.7 => /usr/local/lib/libprotobuf.so.7 (0x00360000)
    libboost_filesystem.so.1.48.0 => /usr/local/lib/libboost_filesystem.so.1.48.0 (0x00a9a000)
    libboost_program_options.so.1.48.0 => /usr/local/lib/libboost_program_options.so.1.48.0 (0x00110000)
    libboost_system.so.1.48.0 => /usr/local/lib/libboost_system.so.1.48.0 (0x00a85000)
    libboost_thread.so.1.48.0 => /usr/local/lib/libboost_thread.so.1.48.0 (0x00179000)
    libunwind-x86.so.7 => /usr/lib/libunwind-x86.so.7 (0x00821000)
    libluabindd.so.0.9.0 => /usr/local/lib/libluabindd.so.0.9.0 (0x00bb3000)
    libmysqlpp.so.3 => /usr/local/lib/libmysqlpp.so.3 (0x00de5000)
    libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0x001a9000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x00782000)
    libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0x00aea000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00447000)
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0x00abd000)
    librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0x00193000)
    libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0x00294000)
    libunwind.so.7 => /usr/lib/libunwind.so.7 (0x002ab000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0x00e8a000)
    libmysqlclient_r.so.16 => /usr/lib/libmysqlclient_r.so.16 (0x0083b000)
    /lib/ld-linux.so.2 (0x00608000)
    libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0x002c0000)

我们发现第一行的so没有对应的库地址, 因此我们使用awk的脚本功能,判断第三个参数,也就是=>之后的路径必须包含/

之后将第一行的输出重定向到变量中, 再使用cp指令从列表拷贝到指定目录

参考链接http://yubosun.akcms.com/tech/linux-daemon-program.htm

   1:  #include <unistd.h> 

   2:  #include <signal.h> 

   3:  #include <sys/types.h> 

   4:  #include <sys/stat.h> 

   5:  #include <stdio.h> 

   6:  #include <stdlib.h>

   7:   

   8:  #ifndef NOFILE 

   9:  #define NOFILE 3 

  10:  #endif

  11:   

  12:  void init_daemon() 

  13:  { 

  14:          int pid; 

  15:          int i; 

  16:          if(pid = fork()) exit(0); //父进程，退出 

  17:   

  18:          else if(pid < 0) exit(1); //fork失败 

  19:   

  20:          /* 子进程继续执行 */ 

  21:          setsid(); //创建新的会话组，子进程成为组长，并与控制终端分离 

  22:   

  23:          /* 防止子进程（组长）获取控制终端 */ 

  24:          if(pid = fork()) exit(0); //父进程，退出 

  25:   

  26:          else if(pid < 0) exit(1); //fork错误，退出 

  27:   

  28:          /* 第二子进程继续执行 , 第二子进程不再是会会话组组长*/ 

  29:   

  30:          //for(i = 0; i < NOFILE; i++) /* 关闭打开的文件描述符*/ 

  31:          //{ 

  32:          //close(i); 

  33:          //} 

  34:          chdir("/tmp"); /* 切换工作目录 */ 

  35:          umask(0); /* 重设文件创建掩码 */ 

  36:          return; 

  37:  }

  38:   

  39:  int main(int argc, char* argv[])

  40:  {    

  41:      FILE *fp; 

  42:   

  43:      signal(SIGCHLD, SIG_IGN); /* 忽略子进程结束信号，防止出现僵尸进程 */ 

  44:   

  45:      init_daemon(); 

  46:   

  47:      while(1) 

  48:      { 

  49:              sleep(1);

  50:              

  51:  // 注意, 日志写到这个目录

  52:              if((fp = fopen("/var/tmp/test.log", "a")) != NULL) 

  53:              { 

  54:                      fprintf(fp, "%s\n", "test message"); 

  55:                      fclose(fp); 

  56:              } 

  57:      } 

  58:   

  59:      return 0;

  60:  }

1.2 编写服务脚本

参考链接http://blog.sina.com.cn/s/blog_57421ff80100c7nn.html

红色字是需要填写的部分, 文件头部分可以选填

   1:  #!/bin/bash

   2:   

   3:  # chkconfig: 3 3 1

   4:   

   5:  # description: web kill center

   6:   

   7:  EXEC_PATH=/usr/local/bin

   8:   

   9:  EXEC=CenterServiced

  10:   

  11:  PID_FILE=/var/run/CenterServiced.pid

  12:   

  13:  DAEMON=/usr/local/bin/CenterServiced

  14:   

  15:  if ! [ -x $EXEC_PATH/$EXEC ] ; then

  16:   

  17:  echo "ERROR: $EXEC_PATH/$EXEC not found"

  18:   

  19:  exit 1

  20:   

  21:  fi

  22:   

  23:  stop()

  24:   

  25:  {

  26:   

  27:  echo "Stoping $EXEC ..."

  28:   

  29:  killall $DAEMON >/dev/null

  30:   

  31:  echo "Shutting down $EXEC: [ OK ]"

  32:   

  33:  }

  34:   

  35:  start()

  36:   

  37:  {

  38:   

  39:  echo "Starting $EXEC ..."

  40:   

  41:  $DAEMON > /dev/null &

  42:   

  43:  echo "Starting $EXEC: [ OK ]"

  44:   

  45:  }

  46:   

  47:  restart()

  48:   

  49:  {

  50:   

  51:  stop

  52:   

  53:  start

  54:   

  55:  }

  56:   

  57:  case "$1" in

  58:   

  59:  start)

  60:   

  61:  start

  62:   

  63:  ;;

  64:   

  65:  stop)

  66:   

  67:  stop

  68:   

  69:  ;;

  70:   

  71:  restart)

  72:   

  73:  restart

  74:   

  75:  ;;

  76:   

  77:  status)

  78:   

  79:  status -p $PID_FILE $DAEMON

  80:   

  81:  ;;

  82:   

  83:  *)

  84:   

  85:  echo "Usage: service $EXEC {start|stop|restart|status}"

  86:   

  87:  exit 1

  88:   

  89:  esac

  90:   

  91:  exit $?

  92:   

1.3 创建服务

参考链接http://hi.baidu.com/guanxiansun/blog/item/b4c7dcf55f6011e47709d724.html

将服务文件拷贝到/etc/init.d下,去掉扩展名, 文件名即是服务名

chmod +x ./wkcenter

如果不设置启动, 那么service中将无法找到该服务及操作

1.4 设置启动顺序

创建启动链接

ln /etc/init.d/wkcenter /etc/rc3.d/S03wkcenter

创建关闭链接

ln /etc/init.d/wkcenter /etc/rc0.d/K03wkcenter

1.5 添加服务

chkconfig --add wkcenter

查看服务是否存在

chkconfig –-list | grep wkcenter

查看服务状态

chkconfig wkcenter on

注意, 确认wkcenter在2,3,4,5中任意或者部分开启, 必须为绿字. 灰字代表服务无法开机启动或者其他问题

1.6 测试

临时开启命令测试

service wkcenter start

1.7 QA

参考链接: http://blog.526net.com/?p=1706

1. 服务切记不可放在用户home目录, 最好放在/usr/local/bin目录, 日志写到var中, 否则服务测试正常,但是无法自动启动

2. Linux下, 父进程启动的程序的生命期跟随父进程, 父进程可以是终端, 父进程一旦终止, 子进程都必须结束. 因此守护进程需要脱离父进程,避免被父进程生命期控制

在原来原基础上,将代码整理,并加强安全性. 并按照WindowsAPI设计, 添加输出缓冲长度探测功能

当OutUTFString为NULL时, 可以进行输出的UTF8字符串长度探测

   1:  uint32 UniCharToUTF8(wchar_t UniChar, char *OutUTFString)

   2:      {

   3:   

   4:          uint32 UTF8CharLength = 0;

   5:   

   6:          if (UniChar < 0x80)

   7:          {  

   8:              if ( OutUTFString )

   9:                  OutUTFString[UTF8CharLength++] = (char)UniChar;

  10:              else

  11:                  UTF8CharLength++;

  12:          }

  13:          else if(UniChar < 0x800)

  14:          {

  15:              if ( OutUTFString )

  16:              {

  17:                  OutUTFString[UTF8CharLength++] = 0xc0 | ( UniChar >> 6 );

  18:                  OutUTFString[UTF8CharLength++] = 0x80 | ( UniChar & 0x3f );

  19:              }

  20:              else

  21:              {

  22:                  UTF8CharLength += 2;

  23:              }

  24:          }

  25:          else if(UniChar < 0x10000 )

  26:          {

  27:              if ( OutUTFString )

  28:              {

  29:                  OutUTFString[UTF8CharLength++] = 0xe0 | ( UniChar >> 12 );

  30:                  OutUTFString[UTF8CharLength++] = 0x80 | ( (UniChar >> 6) & 0x3f );

  31:                  OutUTFString[UTF8CharLength++] = 0x80 | ( UniChar & 0x3f );

  32:              }

  33:              else

  34:              {

  35:                  UTF8CharLength += 3;

  36:              }

  37:          }

  38:          else if( UniChar < 0x200000 ) 

  39:          {

  40:              if ( OutUTFString )

  41:              {

  42:                  OutUTFString[UTF8CharLength++] = 0xf0 | ( (int)UniChar >> 18 );

  43:                  OutUTFString[UTF8CharLength++] = 0x80 | ( (UniChar >> 12) & 0x3f );

  44:                  OutUTFString[UTF8CharLength++] = 0x80 | ( (UniChar >> 6) & 0x3f );

  45:                  OutUTFString[UTF8CharLength++] = 0x80 | ( UniChar & 0x3f );

  46:              }

  47:              else

  48:              {

  49:                  UTF8CharLength += 4;

  50:              }

  51:   

  52:          }

  53:   

  54:          return UTF8CharLength;

  55:      }

当OutUnicodeString为NULL时, 可以进行输出的Unicode字符串长度探测

   1:  uint32 UTF8StrToUnicode( const char* UTF8String, uint32 UTF8StringLength, wchar_t* OutUnicodeString, uint32 UnicodeStringBufferSize )

   2:      {

   3:          uint32 UTF8Index = 0;

   4:          uint32 UniIndex = 0;

   5:   

   6:          while ( UTF8Index < UTF8StringLength )

   7:          {

   8:              unsigned char UTF8Char = UTF8String[UTF8Index];

   9:   

  10:              if ( UnicodeStringBufferSize != 0 && UniIndex >= UnicodeStringBufferSize )

  11:                  break;

  12:   

  13:              if ((UTF8Char & 0x80) == 0) 

  14:              {

  15:                  const uint32 cUTF8CharRequire = 1;

  16:   

  17:                  // UTF8字码不足

  18:                  if ( UTF8Index + cUTF8CharRequire > UTF8StringLength )

  19:                      break;

  20:   

  21:                  if ( OutUnicodeString )

  22:                  {

  23:                      wchar_t& WideChar = OutUnicodeString[UniIndex]; 

  24:   

  25:                      WideChar = UTF8Char;

  26:                  }

  27:   

  28:                  UTF8Index++;

  29:                  

  30:              } 

  31:              else if((UTF8Char & 0xE0) == 0xC0)  ///< 110x-xxxx 10xx-xxxx

  32:              {

  33:                  const uint32 cUTF8CharRequire = 2;

  34:   

  35:                  // UTF8字码不足

  36:                  if ( UTF8Index + cUTF8CharRequire > UTF8StringLength )

  37:                      break;

  38:   

  39:                  if ( OutUnicodeString )

  40:                  {

  41:                      wchar_t& WideChar = OutUnicodeString[UniIndex]; 

  42:                      WideChar  = (UTF8String[UTF8Index + 0] & 0x3F) << 6;

  43:                      WideChar |= (UTF8String[UTF8Index + 1] & 0x3F);

  44:                  }

  45:                  

  46:                  UTF8Index += cUTF8CharRequire;

  47:              }

  48:              else if((UTF8Char & 0xF0) == 0xE0)  ///< 1110-xxxx 10xx-xxxx 10xx-xxxx

  49:              {

  50:                  const uint32 cUTF8CharRequire = 3;

  51:   

  52:                  // UTF8字码不足

  53:                  if ( UTF8Index + cUTF8CharRequire > UTF8StringLength )

  54:                      break;

  55:   

  56:                  if ( OutUnicodeString )

  57:                  {

  58:                      wchar_t& WideChar = OutUnicodeString[UniIndex]; 

  59:   

  60:                      WideChar  = (UTF8String[UTF8Index + 0] & 0x1F) << 12;

  61:                      WideChar |= (UTF8String[UTF8Index + 1] & 0x3F) << 6;

  62:                      WideChar |= (UTF8String[UTF8Index + 2] & 0x3F);

  63:                  }

  64:                  

  65:   

  66:                  UTF8Index += cUTF8CharRequire;

  67:              } 

  68:              else if((UTF8Char & 0xF8) == 0xF0)  ///< 1111-0xxx 10xx-xxxx 10xx-xxxx 10xx-xxxx 

  69:              {

  70:                  const uint32 cUTF8CharRequire = 4;

  71:   

  72:                  // UTF8字码不足

  73:                  if ( UTF8Index + cUTF8CharRequire > UTF8StringLength )

  74:                      break;

  75:   

  76:                  if ( OutUnicodeString )

  77:                  {

  78:                      wchar_t& WideChar = OutUnicodeString[UniIndex]; 

  79:   

  80:                      WideChar  = (UTF8String[UTF8Index + 0] & 0x0F) << 18;

  81:                      WideChar  = (UTF8String[UTF8Index + 1] & 0x3F) << 12;

  82:                      WideChar |= (UTF8String[UTF8Index + 2] & 0x3F) << 6;

  83:                      WideChar |= (UTF8String[UTF8Index + 3] & 0x3F);

  84:                  }

  85:   

  86:                  UTF8Index += cUTF8CharRequire;

  87:              } 

  88:              else ///< 1111-10xx 10xx-xxxx 10xx-xxxx 10xx-xxxx 10xx-xxxx 

  89:              {

  90:                  const uint32 cUTF8CharRequire = 5;

  91:   

  92:                  // UTF8字码不足

  93:                  if ( UTF8Index + cUTF8CharRequire > UTF8StringLength )

  94:                      break;

  95:   

  96:                  if ( OutUnicodeString )

  97:                  {

  98:                      wchar_t& WideChar = OutUnicodeString[UniIndex]; 

  99:   

 100:                      WideChar  = (UTF8String[UTF8Index + 0] & 0x07) << 24;

 101:                      WideChar  = (UTF8String[UTF8Index + 1] & 0x3F) << 18;

 102:                      WideChar  = (UTF8String[UTF8Index + 2] & 0x3F) << 12;

 103:                      WideChar |= (UTF8String[UTF8Index + 3] & 0x3F) << 6;

 104:                      WideChar |= (UTF8String[UTF8Index + 4] & 0x3F);

 105:                  }

 106:   

 107:                  UTF8Index += cUTF8CharRequire;

 108:              }

 109:   

 110:   

 111:              UniIndex++;

 112:          }

 113:   

 114:          return UniIndex;

 115:      }

疗效: 用了此代码啊, 再也不用被iconv折磨了

   1:  #ifdef _WIN32

   2:      #include <hash_map>

   3:      #define HASHMAP_PREFIX stdext

   4:  #else

   5:      #include <ext/hash_map>

   6:      #define HASHMAP_PREFIX __gnu_cxx    

   7:  #endif

对于初始桶大小设置,Linux下使用hash_map构造函数可以设置, Windows下则没有对应的设置函数.

查阅Windows下hash_map的源码,并在hash_map()默认构造函数旁边添加一个测试用初始桶设置函数

   1:      hash_map( size_type _Buckets )

   2:          : _Mybase(key_compare(), allocator_type())

   3:      {

   4:          _Init( _Buckets );

   5:      }

接下来使用相同的测试代码

   1:      const uint32 Buckets = 1000;

   2:      HASHMAP_PREFIX::hash_map<uint32,uint32> MyHash( Buckets );

   3:   

   4:      TimeRuler Ruler;

   5:      for ( uint32 i = 0; i <1000000;i++)

   6:      {

   7:          MyHash[i] = i;

   8:      }

   9:   

  10:      printf("%d\n", Ruler.GetCostTime() );

这里的TimeRuler是使用boost timer的时间戳封装

Release下测试结果:

Windows的测试结果说明, 不给出桶初始化函数是正确的, 默认管理比自己设置更高效.

Linux平台感觉很诡异, 不清楚是不是虚拟机造成的结果不准确

查阅bjam的参数说明及luabind的jamroot文件第240行有如下文字

install stage
  : luabind
  : <location>$(stage-locate)
    <install-no-version-symlinks>on
    <install-dependencies>on
    <install-type>LIB
  ;

说明参数应该是这样的: bjam install [stage]

而且文章中给出的是bjam install 因此默认出调试版也是正确的, 而且估计作者只编译了调试版就没有处理release版了

正确的luabind编译法应该是:

export BOOST_ROOT=/home/davy/dev/boost_1_48_0

export LUA_PATH=/usr/local/

/home/davy/dev/boost_1_48_0/bjam stage --toolset=gcc --with-date_time --with-fpic --with-filesystem link=static debug release

/home/davy/dev/boost_1_48_0/bjam install debug

/home/davy/dev/boost_1_48_0/bjam install release

我这里必须指明bjam是因为boost的bjam版本高于默认安装的版本, 因此使用高版本编译

以下将虚拟机内系统叫Guest, 运行VMWare的系统叫Host

将VMWare的网络方式设为Bridge模式. 注意Host-Only模式只能与Host连接,局域网的机器及互联网机器无法访问

在Guest的网络设置中,将IP设置为与Host在一个局域网网段的IP, 设置DNS

关闭Guest系统

接下来将Host的可以上网的连接添加共享,并连接到VMNet1

进入Guest系统, 测试上网