Xargin

If you don't keep moving, you'll quickly fall behind

怎样降低沟通成本(1)

几十~几百人规模的小公司,业务、研发、产品、市场等等角色的沟通成本并不是特别高。在公司创业早期,一个人身兼数职,沟通成本就更低了。有事情,大家拉到会议室,简单学一下金字塔原理,碰到问题很快就能得到解决方案。 游戏界有一个很经典的案例,早期从北方暴雪跳槽出来的几个人,都是会写代码的美工,他们只用了 12 个人,在很短的时间内以极高的效率做出了 torchlight 这个游戏,完成度很高,令人惊叹。 公司扩张到千人时,沟通瓶颈就开始比较明显了,即使将所有人的 schedule 全部用会议塞满,还是难以快速有效地得到结论,所有人看起来都很忙,项目延期更是常事。大公司在和小公司在竞争的时候,

go-redis 和 redis server 版本错位导致的高延时问题一例

公司内有多个 go-redis 的 client 和多种 redis cluster 版本,业务压测发现即使只访问 redis 的接口也可能会延迟达到秒级,非常反直觉。 我们用不同版本的 go-redis 和不同版本的 redis cluster 来简单做个压测,redis 命令用简单的 get,kv 大小都是一个字节,这里把数据先放出来: Client 版本 Server 版本 平均延迟 qps v6 5.0

memory ballast 和 gc tuner 成为历史

memory ballast 和 auto gc tuner 是为了解决 Go 在没有充分利用内存的情况下,频繁触发 GC 导致 GC 占用 CPU 过高的优化手段。 memory ballast 通过在堆上分配一个巨大的对象(一般是几个 GB)来欺骗 GOGC,让 Go 能够尽量充分地利用堆空间来减少 GC 触发的频率。 uber 后来分享的 auto gc tuner

为什么要旗帜鲜明地反对 orm 和 sql builder

这个问题在五六年前和前同事讨论过,没想到这么多年过去了,又要跟其他工程师再讨论一遍,有点恍如隔世。 因为我比较懒,所以记录一篇文章,以后碰到类似的问题就不再掺和了。 toC 场景的系统大多要面对较高的 QPS,即使是小型/中型公司使用 MySQL,没有那么高的查询量,单表数据在百万量级也属常见。 无状态的服务当前用 k8s 的 HPA 能力能够做到很好的扩容,结合基本的优化知识,大多数问题能够较好地被初/中级工程师解决。但 DB 一直是非常脆弱的一环,只要一个工程师不慎将不带索引的查询代码带上线 ,就会导致线上事故。这样的事故在各家公司都不少。哦,当然,公司为了自己的形象考虑,这样的低级事故一般是不对外说的。

Go 语言的 GC 实现分析

注:本文只作了解,不建议作为面试题考察。 武林秘籍救不了段错误 包教包会包分配在各种流传甚广的 C 语言葵花宝典里,一般都有这么一条神秘的规则,不能返回局部变量: int * func(void) { int num = 1234; /* ... */ return # } duang!当函数返回后,函数的栈帧(stack frame)即被销毁,引用了被销毁位置的内存轻则数据错乱,重则 segmentation fault。 经过了八十一难,终于成为了 C 语言绝世高手,还是逃不过复杂的堆上对象引用关系导致的 dangling
京ICP备15065353号-1