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

自动调整 GOGC 优化 GO 的 GC CPU 占用

Uber 最近发了一篇文章,主要讲的是在核心服务上动态调整 GOGC 来降低 GC 的 mark 阶段 CPU 占用。基本可以做到有效果,低风险,可扩展,半自动化。 Uber 当前的服务规模大概是几千微服务,基于云上的调度基础设施来进行部署。大部分服务是 GO 写的,这篇文章的作者是做 Maps Production Engineering,这个组之前帮一些 Java 系统调整过 GC 参数(这应该就是他们帮 Go 做优化想的也是怎么调整参数的出发点吧)