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

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

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

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

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