新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
UID空间积分0 积分4951阅读权限50帖子精华可用积分4951 信誉积分2589 专家积分0 在线时间2107 小时注册时间最后登录
小富即安, 积分 4951, 距离下一级还需 49 积分
帖子主题精华可用积分4951 信誉积分2589 专家积分0 在线时间2107 小时注册时间最后登录
认证徽章论坛徽章:31
&&go语言最大的特点就是原生的并发特性,类似erlang.
但是相应的,要求对应的api必须是无阻塞的.
erlang中的任何io操作,都是不会阻塞整个程序的,
go语言的文件\数据库api,尤其是非官方扩展的api
比如redis,mysql之类的,能否做到无阻塞呢?
&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp&&nbsp|&&nbsp
UID45332空间积分0 积分81634阅读权限100帖子精华可用积分81634 信誉积分3443 专家积分1309 在线时间15513 小时注册时间最后登录
招聘 : 帖子主题精华可用积分81634 信誉积分3443 专家积分1309 在线时间15513 小时注册时间最后登录
论坛徽章:1
laputa73 发表于
go语言最大的特点就是原生的并发特性,类似erlang.
但是相应的,要求对应的api必须是无阻塞的.
erlang中的 ...
阻塞没关系啊，用 go 程就可以了。
UID空间积分0 积分4951阅读权限50帖子精华可用积分4951 信誉积分2589 专家积分0 在线时间2107 小时注册时间最后登录
小富即安, 积分 4951, 距离下一级还需 49 积分
帖子主题精华可用积分4951 信誉积分2589 专家积分0 在线时间2107 小时注册时间最后登录
认证徽章论坛徽章:31
& & 如果api只阻塞协程,那是没问题的,但是如果阻塞整个进程,不就没法并发了?
& & 我看&go web编程&上对数据库这块都没有提及
& &只说是否符合database/sql接口
& &是否可以认为这些驱动都是支持go-routine的了?
UID45332空间积分0 积分81634阅读权限100帖子精华可用积分81634 信誉积分3443 专家积分1309 在线时间15513 小时注册时间最后登录
招聘 : 帖子主题精华可用积分81634 信誉积分3443 专家积分1309 在线时间15513 小时注册时间最后登录
论坛徽章:1
laputa73 发表于
回复 2# flw
go 程不是协程。它更像线程。
UID空间积分0 积分942阅读权限20帖子精华可用积分942 信誉积分1975 专家积分0 在线时间2147 小时注册时间最后登录
丰衣足食, 积分 942, 距离下一级还需 58 积分
帖子主题精华可用积分942 信誉积分1975 专家积分0 在线时间2147 小时注册时间最后登录
论坛徽章:0
用go来写分布式计算的是不是很合适？
UID空间积分0 积分942阅读权限20帖子精华可用积分942 信誉积分1975 专家积分0 在线时间2147 小时注册时间最后登录
丰衣足食, 积分 942, 距离下一级还需 58 积分
帖子主题精华可用积分942 信誉积分1975 专家积分0 在线时间2147 小时注册时间最后登录
论坛徽章:0
用go来写分布式计算的是不是很合适？
UID空间积分0 积分4951阅读权限50帖子精华可用积分4951 信誉积分2589 专家积分0 在线时间2107 小时注册时间最后登录
小富即安, 积分 4951, 距离下一级还需 49 积分
帖子主题精华可用积分4951 信誉积分2589 专家积分0 在线时间2107 小时注册时间最后登录
认证徽章论坛徽章:31
理论是这样的.不过还得要有基于go的hadoop类似的应用出来才行.
UID7692680空间积分0 积分312阅读权限20帖子精华可用积分312 信誉积分215 专家积分0 在线时间44 小时注册时间最后登录
稍有积蓄, 积分 312, 距离下一级还需 188 积分
帖子主题精华可用积分312 信誉积分215 专家积分0 在线时间44 小时注册时间最后登录
论坛徽章:0
纯 go 实现的驱动都会是无阻塞的
用 cgo 包装的就不好说了。
但是无论哪种情况，都不会造成整个程序阻塞，在 cgo 调用的时候，会从线程池里取一个线程来执行。
UID空间积分0 积分1417阅读权限30帖子精华可用积分1417 信誉积分280 专家积分0 在线时间119 小时注册时间最后登录
家境小康, 积分 1417, 距离下一级还需 583 积分
帖子主题精华可用积分1417 信誉积分280 专家积分0 在线时间119 小时注册时间最后登录
论坛徽章:0
弱弱的说我连erlang都不知道。
UID空间积分0 积分43阅读权限10帖子精华可用积分43 信誉积分216 专家积分0 在线时间308 小时注册时间最后登录
白手起家, 积分 43, 距离下一级还需 157 积分
帖子主题精华可用积分43 信誉积分216 专家积分0 在线时间308 小时注册时间最后登录
论坛徽章:0
要用无阻塞,就用buffered channel数据传递使用 Go 语言开发游戏服务端的是如何忍受无法热更新的？
Go 语言不能热更新，真的适合用在游戏服务端吗。看很多同学在用 Go 语言写游戏服务端，本人目前项目用 Python + 少量 C，无法想象不能热更新的游戏要怎么运营。也有看到有人用 Go 结合脚本的，但是大部分逻辑代码应该还是 Go 语言吧，你无法判断一段代码什么时候会出问题需要 reload 的，也就不好在开发一个功能的时候就决定使用脚本还是 Go。
按投票排序
有一种做法是可以将服务端微服务化；这样每个服务的重启成本很低，像达达说的reload数据库到内存的时间成本就会更低。------分割------另外为服务化后，可以针对不同的服务是否有必要热更新，结合脚本或其它方法实现（如:游戏运维的活动服务需要频繁变更）。而像一些基本的如用户，游戏逻辑等接口设计灵活一点的情况下；是完全没必要热更新的；每次版本变更停服重启就ok。
当初从erlang切换到go，最难适应的就是没热更新。紧急修复BUG，在线修数据，等等，都是很救命的。再加上我们的服务端设计是整个数据库加载进内存的，重启需要较长时间，所以就特别担心频繁重启对游戏会很伤。后来产品上线了感觉还好，没有热更新的确没那么方便，但是也没那么可怕。原因：1. 需要临时重启更新就运营公告，如果实际较长就适当发放补偿。2. Go加载数据到内存的速度也比之前快很多，重启压力也没想象的那么大。3. 强类型语法在编译器提前排除了很多之前要到线上运行时才能发现的问题，所以BUG率低了。所以没有热更新也顺利跑下来了。不过以上只能做为参考，不同项目需求不一样，还是得结合实际情况来判断。热更新肯定是可以做的，方案挺多，数据驱动、内嵌脚本或者无状态进程都可行，只是花多大代价换多少回报的问题。如果评估下来觉得热更新必做不可，那么用再大代价也得做，这是项目存亡问题。如果不是必须的，那就需要评估性价比了。做热更新、换编程语言或者换服务端架构所花的代价，换来的产品在运营、运维或开发各方面的效率提升，是否划算。
1.5 支持编译成so，所以可以像C一样用dlopen做hot reload。举个例子主程序：package main
#include &dlfcn.h&
#cgo LDFLAGS: -ldl
void (*foo)(int);
void set_foo(void* fn) {
void call_foo(int i) {
import "C"
import "fmt"
func main() {
var bar string
hd := C.dlopen(C.CString(fmt.Sprintf("./foo-%d.so", n)), C.RTLD_LAZY)
if hd == nil {
panic("dlopen")
foo := C.dlsym(hd, C.CString("foo"))
if foo == nil {
panic("dlsym")
fmt.Printf("%v\n", foo)
C.set_foo(foo)
C.call_foo(42)
fmt.Scanf("%s", &bar)
因为go编译出的so不能dlclose（这里说了原因：），所以每次只能load不同的，所以内存和线程会泄漏一些。另外由于cgo的限制，不使用set_foo和call_foo似乎不行，所以会引入cgo调用的开销。所以如果不在意上面这些缺陷，可以试试。so源码：package main
import "fmt"
import "C"
func main() {
//export foo
func foo(i C.int) {
fmt.Printf("%d-2\n", i)
用 go build -buildmode=c-shared -o foo-1.so
mod.go 编译。需要1.5的编译器，8月初会出正式版。这是借助C的机制来实现的，go的execution modes文档提到会有go原生的plugin模式，就不需要借助C的了，不过什么时候实现也未定。
谢邀可行性热更新怕的就是测试覆盖率不到位. 更不要说游戏这种设计很奇葩, 有时根本就不是覆盖率可以科学测试达到的. 任何一个考虑不周到的更新都会被玩家当成刷点其实只要运维, 运营, CP胆子肥, 测试牛B, 没什么怕的, 尽管热更新就是了Golang和热更新1. Golang 1.4还不支持编译为动态链接库和把自己作为动态链接库进行加载因此要通过动态链接库方式进行热更新是行不通的2. Golang是通过编译为native code外加自己runtime配合跑起来的. 更接近JIT.所以, 想要热更新的话, 我估计底层和设计改动会很大Golang现在还不支持把自己的语言当成脚本进行嵌入式运行.因此, 想做类似lua那种脚本方式, 使用自己当做脚本的运行也不行3. Lua+Golang, 这种方式其实只是把Golang当成一个网络库来用, 逻辑全用Lua来写. 跟客户端里的Unity3D+Lua有异曲同工之妙. 但不得不说, 这种做法还不如用skynet来的舒服点, 人家本来就设计有热更新, 何苦自己造轮子. 长远点说, Unity3D+Lua做客户端热更新现在已经风险很大了, 而且渠道也慢慢接受了测试+大更新的方式了. 因此Lua来解决热更新的方案迟早会变成废技术至于题主说的方式, 大部分用go, 小部分用lua, 还要判断啥时候需要热更新. 我只想说,
把游戏逻辑和框架为了热更新来设计, 合理么?值得么?如果哪天运营说, 你能实时在服务器上开发逻辑代码, 马上更新给玩家时, 你该怎么办?作为服务器程序员的基本节操:1. 保证服务器的稳定2. 保证服务器的逻辑正确性3. 不断提高业务处理性能4. 拒绝不合理的需求, 以保证前面3点
个人感觉客户端的热更新要比服务器的热更重要，从手游这个领域来看，服务器相比客户端会稳定一些，我们游戏内测了三次：第一次内测，服务器因为Bug或策划数据表更新而热更了好几次，后面两次慢慢减少；而客户端呢，基本上每次测试的第一天，都是要打十几次Patch的。个人感觉服务器不支持热更，可能真的没想象的那么严重，服务器需要更新，不外乎下面几种情况：1.
策划数据表的更新，这个本来就应该做好数据重加载的支持，如果因为这个需要重启则说明这块没有做好。另外，系统功能要尽可能参数化，让策划去配表而不是写死程序中。2. 代码出BUG，重启后看情况运营补偿，最好是前期做好测试，别出一些可以刷的漏洞。（当然这块有热是会方便很多）3. 策划新制作的系统，这个要求服务器重启也不过份吧。4. 运营活动，基本上也是新功能，客户端必然也是要相应更新的，服务器重启似乎也不过份吧？所以我想热更新更多的应该是解决一些小问题，大功能应该不大可能通过热更可以完成。
其实最简单的就是开一个新服务，老服务的负载逐步转过去，到了合适的时候，关闭老服务，虽然有不少限制，但不依赖语言
鹅厂自研用C++写后台，很多场景也是热更的。能否热更看你基础架构如何，而语言只是基础架构的一部分
快速重启，客户端做好重连机制
(⊙o⊙)…golang可以做热更新啊
go不能热更新是开发游戏服务器的硬伤。从技术角度来说热更新不是必须的。但是从产品角度来说，每一次停机维护都是对在线数的一次巨大伤害。
目前的大部分的手游都会做断网自动重连，因此在停机10秒之内影响不明显。但是如果超过10秒，从监控曲线看会掉一截，而再回到峰值是需要一段时间的。人数下降，收入必然也受到影响。总的来说停机维护代价是很大的。尤其是游戏刚上线特别容易出bug，停机维护的频率高对第一批用户的伤害是巨大的。
我带过的3个游戏项目除了第一个是c++，后面的都是以lua为主语言。最新的项目是erlang+lua的方式，无论是底层、协议、配置还是逻辑都支持热更新。保守估计停机的机率降低90%。
目前也在考虑用go开发，但是热更新必须要有一个方案，不能接受任何小bug的修改都要停机维护。可行的思路只有尽量把服务拆细，单独更新各个服务。
已有帐号？
无法登录？
社交帐号登录为什么用golang作为游戏服务端的开发语言，它的并发性如何_百度知道
为什么用golang作为游戏服务端的开发语言，它的并发性如何
提问者采纳
写下这篇文章总结一下。只有玩家自发形成一个稳定的生态系统，很大程度上依赖于玩家自发形成的社区，游戏才能持续下去。从网游的角度看个人觉得golang十分适合进行网游服务器端开发，避免鬼城的出现：要成功的运营一款网游
其他类似问题
为您推荐：
并发性的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁启程的故事 使用Golang写服务器是一件非常幸福的事情. 不用长时间的等待编译, 零依赖部署. 开发效率高, 多出的时间陪陪家人, 看书充充电多好. 所以Golang就像是手机界的苹果, 从发布后, 瞬间成为了口碑超好的开发语言.
Golang进行服务器开发, 最显耀的就是其并发架构, 能充分榨干每一个CPU. 但是Golang和Erlang不一样, Golang使用了CSP的模型, 而Erlang采用的是Actor模型. 两者区别仅仅只是消息队列归属范围区别而已. 但带来的巨大的框架实现及使用差异让Golang和Erlang阵营里的童鞋们撕逼很久.
其实可以这么理解. Erlang基于Actor模型的并发架构真正是一个框架, 让每一个人用同样的方法处理事情. 而不用更多的担心横向扩展的问题. Golang的CSP并发架构没有很多框框条条. 让开发者自由发挥,设计自己想要的结构. 但碰到需要横向扩展时, 还是需要考验架构人的经验和实力.
所以说, CSP和Actor其实着眼点不一样. 所以还是不能同日而语. 但项目还得做, 问题还得解决. 不能为每一个项目重复设计, 编写重复的代码来应对各种横向扩展的问题. 烦了, 火了, 所以就准备造一个用Golang实现Actor的轮子.
调研了一段时间, 使用Golang做Actor模型的实现并不多. 而且大多是实验性项目, 并没有真正像Skynet一样, 在项目中使用同时做开源的.
说到Skynet, 这是一个极好的开源轻量级游戏服务器框架. 使用lua的coroutine模拟goroutine, 同步+多线程逻辑, 用C底层帮你处理了复杂的Actor模型. 留给上层只是发发消息, 管理下id, 很是惬意. 再加上lua天生动态语言, 模拟Erlang的动态更新更不是啥大问题. 因此在服务器界, Skynet变的有名了起来.
既然要做轮子, 我果断选择不关门. 讨论群都开了, 博客一直更新, github也有, 为啥不搞开源轮子呢? 因此这次的服务器框架计划定位于开源. 目的是为Golang贡献一款轻量级的游戏服务器框架, 由大家支持, 供大众使用.
& 项目地址:
感觉不错, 请给Star, 谢谢
支持，沙发&&&&
&re: 基于Golang的游戏服务器框架nucleus开发日记(一)
那github连接什么时候发出来呢？&&&&
&re: 基于Golang的游戏服务器框架cellnet开发日记(一)
支持! cellnet 是什么模型&&&&
&re: 基于Golang的游戏服务器框架cellnet开发日记(一)
@虞双齐请看下我博客最新的文章&&&&
&re: 基于Golang的游戏服务器框架cellnet开发日记(一)
开源轮子学习了 MARK下&&&&