最近和一些前同事聊天，有些同事已经离开了大公司，一少部分还留在大公司里和年轻人们内卷。思来想去，我个人应该之后也不会去国内的大公司了(希望不是 flag)，有些阶段性的问题也是时候该有答案了。 刚毕业的时候年轻的我曾经问了当时公司 mentor 两个问题，一是为什么明明活儿干完了到时间却不能下班；另一个是为什么企业要用这些虚无缥缈的工时来作为员工的工作态度来进行考核。当时的 mentor 自己也没想明白，他说大家都是这样的，你别搞特殊。 这令我非常尴尬，学生时代我的考卷就没有在考试结束的时候交的，既然半小时、一小时就可以把这些事情搞定，为什么非得屁股粘板凳上陪着各位同学呼吸考场的脚臭味。企业里的潜规则却把按时下班也当成了搞特殊，让我想起了没人愿意当刺儿头的日本文化。 不过日本的职场应该也不是十年前的样子了，还有这样的电视剧能上映： 我们的主流文化时至今日依然鼓励奋斗而不是偷懒，连按时下班可能都会被划到不够奋斗的落后分子里，要以最后走出办公室为荣。上进奋斗并持续不断地加班再加班，哪怕整个社会已经陷入到生产过剩的经济危机里去。辛苦生产的牛奶，

几十~几百人规模的小公司，业务、研发、产品、市场等等角色的沟通成本并不是特别高。在公司创业早期，一个人身兼数职，沟通成本就更低了。有事情，大家拉到会议室，简单学一下金字塔原理，碰到问题很快就能得到解决方案。 游戏界有一个很经典的案例，早期从北方暴雪跳槽出来的几个人，都是会写代码的美工，他们只用了 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 一直是非常脆弱的一环，只要一个工程师不慎将不带索引的查询代码带上线 ，就会导致线上事故。这样的事故在各家公司都不少。哦，当然，公司为了自己的形象考虑，这样的低级事故一般是不对外说的。