@sthwrong @kekeabab #24 #25 没什么好办法, 又何止是工作, 程序员至少还是逻辑比较强的, 生活中的更多人和事情比这还折腾. 改变不了, 气也没用, 不如平和, 效果反倒会好些. 应该庆幸的是自己不是这种, 自己已经是极少数的优秀了, 如果心态能平和, 自己会更厉害.

@lujiaxing #8 绝大多数都是普通人. 会用梯子和懂你说的那些也并不能代表牛逼, 老外很多你说的这种"菜鸟", 对这些人而言, 写代码这只是一份工作, 他们挣钱享受生活, 很多这种人家里条件都还可以, 他们自己没生活和钱的压力所以不需要卷技术. 除了具体技术问题要争对错, 怎样的技术追求和技术节奏, 并没有什么必要去批评. 我年轻时候也跟你一样, 眼里看着很多菜鸡老司机程序员啥也不会, 心里也很鄙视, 直到闲聊发现, 比如一个同事, 刚毕业工作家里就给买了 180 平的房子奥迪宝马两个车换着开后来老被同事议论觉得太高调了不好又买了个便宜车用来上班开, 比如另一个同事不只是啥也不会而且还很笨他自己倒是挺想学技术的但学很慢甚至学不会, 但是他家深圳开农家乐而且那半个山是他家的.
做自己喜欢的事, 让自己活得幸福, 珍惜自己重视的人, 其他的, 不那么重要

先问问其余那 99w 是不是他们自有资金吧, 万一大头都是借的需要好好劝劝他们更谨慎点, 毕竟亲姐姐, 除了考虑借不借也得多关心关心

回 LV 好些

应该增加锻炼身体的时间, 运动能让状态心情大大提升并且预防电子产品相关的慢性疾病

@mingtdlb #27 刚开始那段时间好像站长有发公告帖子禁止这个, 但很多人没看到; 创建新主题有提示, 但是回帖的时候没有这个提示. 所以, 很多人可能仍然并不知道有这个规定. 很多人被封时一脸懵逼, 被封了才知道有这个规定但为时已晚

@PROJECT #18

@Livid 建议把不允许直接使用 AI 回复的指引做更明显些, 有不少用户可能并不知道有这个规定, 甚至是老用户. 或者, 第一次封禁一周, 第二次再永久封禁, 人非圣贤, 何况不知

@guanzhangzhang #46

> 你这些的前提都是 server 和 client 都是自己写

这不废话吗. 如果是涉及已有的或者别人的, 你自己没法自己搞的, 当然得用已有的啊, 或者改造成新的. 你都有现在的限制了而且不想改造, 为什么还要来问其他的方案? 这不是浪费别人时间吗?

感觉你自己对技术不是太懂, 所以你不明白具体问题在哪里, 你问问题的时候也难把问题描述清楚. 如果不是不懂技术, 那就是纯伸手党了. 不管哪种, 建议不要白白浪费自己和别人时间, 问问题之前至少自己先搞明白一些基础, 这也是对别人的尊重

@picone
就目前国内开源社区的 go 游戏框架的玩具看, 我的 arpc 随便封装点日志/串行化的协程池就可以叫游戏框架了...太没含金量了, 都不好意思这样叫

还有些重度的, 好像 nano 是沿袭了网易那个 nodejs 的 pomelo, 这种定位重度 mmorpg 类业务的框架他们真是真敢做, 而且都是直接选择不适合的语言, 用 node 是错, 换到 go 赛道继续错, 作者是想为社区做出多大贡献猜不透, 但公司内 KPI 升职加薪的作用应该更实事求是. pemelo 当年做的早, 随着手游行业爆发, 吸引(骗)来了不少小白.

那年代的游戏团队, 不只是 go 的在摸索, 整个行业团队里, 多数都是技术不合格的. 因为原本没那么多游戏公司/团队/项目, 而是随着智能手机的发展, 大概 2012 国内一些团队创业成功, 开启了游戏创业潮, 然后大量资金人员涌入. 本来没那么多游戏行业的人才, 资金/项目突然爆发增长, 对应的人力也爆发增长, 不只是技术的人, 制作人/策划/美术, 都缺人, 大量成立的团队里的人力, 只能是拔苗助长的方式, 良莠不齐, 弱鸡居多.
游戏行业不像 web 领域那样, 不同公司不同业务不同规模, 但主要的通用的基础设施都是 web 前后端数据库之类的这些, 社区范围更大, 不管哪种语言也都用这套, 所以 web 领域的整体社区技术比较容易一脉下来形成不同的子派别, 卷这些的社区领袖人多水平也不错, 就容易弄得工程. 游戏则不同, 不论公司大中小, 几乎每家一套自己的, 这其中很多所谓的主程自己不具备开发底层和框架的能力, 就拿着以前公司师傅师爷的祖传代码拿来稍微改改.

而且当年好像真有脑残的大项目技术负责人拎不清, 用 go 做大型 mmorpg, 完全没考虑过 gc 甚至都没做个像样的压测, 一开服压力上来了就卡得不要不要的, 这种挖大坑很难有机会去优化, 线上运营口碑凉了项目直接就凉了

> 江湖不是技术来技术去 是打打杀杀 人情世故 天变了

@ugpu 其实除了元素数量太时 gc 的 cpu 压力, 以及其他类型的强 cpu 压力类的项目, go 还真是都能做. 街篮那种非重度 fps+类 moba 的, 房间人数不多, 也没有农药那种满地图建筑/怪物/兵之类的各种压力, 用 go 都绰绰有余. 那些中小游戏甚至便单机的游戏就更不在话下了. 所以很多团队用 go 是非常合理的技术选型, 跟人情世故没啥关系, 不用这么委屈自己

@librasolo #36

leaf 看上去甚至比 zinx 还差一些, 可能 zinx 毕竟要做课程所以毕竟略带着点"学院派"的工整. leaf 的年代更早点, 那时候 go 社区里轮子少, 国内 go 社区也非常活跃, 论坛和技术群都大把人, 随便写点什么宣传下, star 就上来了.
但那个年代的玩具项目多. 游戏行业的 go 服务端更是属于很多团队在摸索中的状态, 不能怪社区水平, 而是历史局限性

@shellus #32
能对框架选型发问的用户, 绝大部分人不是用来做大型游戏, 这类需求的主要部分其实就是个网络库. 性能需求不大, golang 足够, 而且相比于 c++或者 rust, 开发效率爽死

真要是做大型游戏, 基本都自家团队内解决选型和研发问题了, 自家负责技术的人如果连框架架构的能力都没有的话还做毛的大型游戏, 如果大项目还要外面咨询选型的说明这项目从立项就凉了 80%了, 除非中间把技术的人换掉

@guanzhangzhang #33

Call 是请求需要对方响应, Notify 是只发消息不需要对方响应, Call 是同步的, CallAsync 是异步的.
client/server 两端都可以主动发起 Call/Notify.
arpc 是涵盖了传统游戏服务器网络库和 rpc 模式的, 所以支持的业务场景更广更好用.

要不你先看下 arpc 的例子吧, 有提问这功夫, 花几分钟看下 Readme 早就懂了都可以开始写逻辑了:
https://github.com/lesismal/arpc?tab=readme-ov-file#quick-start

@guanzhangzhang #29

如果你们客户端使用的引擎语言支持标准 js, 可以试试用 arpc, 处理你说的"同步"这种问题, 比 msgHandler 简单方便多了.

@guanzhangzhang #29

客户端的交互, 绝大多数项目, 本质上都是异步的.
因为客户端发消息基本上是在 eventloop 主线程触发的, 如果不是异步那就要卡渲染了, 客户端引擎的 eventloop 线程里的操作不应该有阻塞. 除非有特定需求是不需要主线程逻辑触发, 才可以考虑异步线程去同步 IO 的模式, 不影响 eventloop 主线程就行.

如果想"同步"代码, 要依赖不同的游戏引擎, 或者说, 主要是依赖你编写这部分逻辑使用的语言以及这个语言对"同步"支持的程度.
这里说的"同步"不是指同步 IO, 而是指类似协程这些让代码顺序看上去同步的语言特性. 比如 lua 可以用协程, js 可以用 Promise 甚至 async await? 一些引擎自带的语言并非标准语言而是变体, 那么则要看这些具体语言的特性了.

传统的游戏客户端服务端网络协议主要是命令号, 命令号对应 handler, 但每个 msg 和可能收到的响应不方便一一对应, 所以即使是协程/Promise 之类的看上去"同步"代码, 传统游戏协议也不方便把发送的 msg 和响应对应起来做这个同步.

arpc 的 js client 是默认支持了 Promise, 并且本身是通过 rpc 的方式实现的协议, 每个 call 都与响应一一对应, 所以可以这样用, 这样看上去就比较方便了:
https://github.com/lesismal/arpc/blob/master/examples/webchat/chat.html#L81

@asuraa 再补充一下, nginx 的多进程也有不均衡的问题, 比如很多连接均匀连到不同的 worker 进程上, 但是很多断开了, 剩下的大量连接分布在少量 worker 进程上, 仍然是不均衡的.

@asuraa BTW, nbio 每个 conn 上一个执行队列配合通用协程池的方案, 对于其他语言也是适用的. 传统 c++框架, 为了保证时序, 多数是逻辑单线程, 对于有状态和多连接交互类并且 cpu 高消耗的业务就未必能充分发挥 cpu 了, 都可以考虑我这种方式优化.
nginx 这种为了提升 cpu 利用率搞 fork 多进程, 因为业务是 web 类, 在 nginx 这一层面连接之间没什么交互, 多进程的方式又可以避免多线程的锁竞争, 是非常合理的. 但游戏类业务多数涉及交互广播之类的, 就不太适合 fork 多进程的方式了

@asuraa #24

> 1.2048 这个值是有考究的

硬件配置差别很大, 1c1g/16c64g/36c/512g, 对于这点协程数量的压力完全不同, 所以不论什么吋间规格都用 2048 写死了, 真没什么解释的必要.

> 2.worker 分配不均匀问题

可以参考下我的 nbio 里的实现:
https://github.com/lesismal/nbio/blob/master/conn.go#L185
原理是, 每个 conn 上一个执行队列, 每个 job 入队列并判断是不是队首, 如果是队首, 就用通用的协程池去异步循环处理挨个取出直到没有任务; 如果不是队首, 说明已有协程在循环执行, 则入队后直接返回并等待被执行即可. 这种实现下, 协程池的部分是不受限制的, 如果对协程池 size 没有限制就直接 go func(), 如果对协程池 size 有限制, 则协程池实现的部分限制即可.
游戏服务, 通常对最大在线量本身就有限制, 在 Acceptor 或者 login 的部分就可以做限制, 而且通常单节点在线量不会超大, 例如单节点 5k-5w 在线量, 通常都是 1w 以内, 而这种在线量在 8c16g 的机器上即使对应的每个连接一个异步任务的协程也压力不大, 而且 go func()执行完当前任务队列没任务后即可退出所以不需要持续占用协程, 再考虑实际并行和下游基础设施连接池之类的, 临时异步任务并发度对应的协程数量也多数小于实际连接数.
协程池的实现大概几种, 早期 ants 那种自己用 cond_t+队列或者 chan 配合 idle time idle size 的常驻协程方案并没有性能优势而且常驻协程的释放不及时, 而且 cond_t+毒烈或者 chan 的性能都有些损失, 除了可以限制协程数量, 绝大多数场景不如 go func().
字节家的 workerpool 是 size 限制 + list + go func() , 新任务判断当前协程池 size 并发度, 如果没达到限制就直接 go func()去循环执行 list 队列里的 job, 如果达到 size 限制里就入 list 队列等待被执行, 每个 go func()循环执行直到 list 队列里没有 job 里就退出. 这种方案是通用协程池, size 设置为 1 则也可以直接作为我上面说的 nbio 里每个 conn 的执行队列的方案, nbio 每个 conn 的执行队列没有用 list 而是用 slice, 是因为考虑单个 conn 任务数量不会太大所以 slice len 也不会太大, 所以用 slice 做队列复用并且省去了 pool get/put 之类的额外逻辑, 相比于 list 可能略有优势.
较高版本的 go, runtime 协程复用很好了, 如果不考虑 size 限制, 其他协程池实现基本都不如直接 go func()性能好, 字节家的这种 go func()好处是只比 go func()多了一点点逻辑但非常接近 go func()了, 但也有个缺点, 就是对 list 队列 size 没有限制, 如果下游阻塞并且上游不断有新的 job 进来, 理论上是存在无限增长的风险的.
lxzan https://github.com/lxzan/concurrency 与字节的类似, 用于队列的数据结构略有不同.
nbio 的协程池为了更均衡, 达到 size 限制前直接 go func(), 达到 size 了, 用 chan 做队列, chan 的好处是满了就阻塞了可以让上下游自动均衡, 规避了字节家 workerpool 的缺陷:
https://github.com/lesismal/nbio/blob/master/taskpool/taskpool.go
golang runtime, 例如 8c16g 这种配置, 通常的场景下, 10w 个协程数量都算还好, 压力不大. 而且 nbio 的协程池 size 默认是按核心数初始化, 多数也是跑不满 size 的. 而且用户也可以自己随便配置用什么协程池, 因为不管用什么协程池, nbio 的每个 conn 已经保证了自己的有序所以不需要协程池去保证顺序

> 3.代码估计没看仔细，是只有获取没创建的才需要初始化加锁的，后续获取是不需要的

这个确实没仔细看, 只是简单扫了几眼, 你说的是对的

> 这模块我们自己项目也在用，我们一百多万 dau ，跑的好好的。不过代码是比较简单，大家相互讨论印证也没问题。挺好的技术交流

因为 golang 本身性能还不错, 即使框架代码一般, 对于绝大多数的非性能和开销敏感的业务而言也是过剩的.
但这并不意味着这种框架本身优秀.
而且如 OP 在#4 和我在#11 说的, 简单游戏业务, 游戏脚手架就那几个简单的组建, 网络库的部分算是大头的了, 其他的太多现成的甚至标准库直接就够用了, 真的挺简单的 😂😂😂

> 还是 sqlx ，看到 gen 类型的框架我就头痛

@securityCoding sqlx 也是挺麻烦的, 一些没必要的搞得太多, 懒得浪费时间学它, 所以我自己搞了个. 性能最好的肯定是生成代码的这类了, 但用起来也是真不爽