公司内部写 kafka 的 consumer 和 producer 使用的是社区流行的 sarama 这个库，这个库应该 bug 挺多的，之前有云厂商建议用户不要使用该 lib 的文档：为什么不推荐使用Sarama Go客户端收发消息？ 不过用都用了，随便换也不好，碰到问题了还是要先定位一下，然后再去看到底是不是 lib 本身的质量问题导致。贸然就说这是 lib 的 bug 会让人鄙视。 现在就碰到这么个场景： 部门内有一个 kafka 的 message

最近和一些前同事聊天，有些同事已经离开了大公司，一少部分还留在大公司里和年轻人们内卷。思来想去，我个人应该之后也不会去国内的大公司了(希望不是 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