一个95分位延迟要求5ms的场景,如何做性能优化

组内的数据系统在承接一个业务需求时无法满足性能需求,于是针对这个场景做了一些优化,在此写篇文章做记录。

业务场景是这样:调用方一次获取某个用户的几百个特征(可以把特征理解为属性),特征以 redis hash 的形式存储在持久化 KV 数据库中,特征数据以天级别为更新粒度。要求 95 分位的延迟在 5ms 左右。

这个数据系统属于无状态的服务,为了增大吞吐量和降低延迟,从存储和代码两方面进行优化。

存储层面

存储层面,一次调用一个用户的三百个特征原方案是用 redis hash 做表,每个 field 为用户的一个特征。由于用户单个请求会获取几百个特征,即使用hmget做合并,存储也需要去多个 slot 中获取数据,效率较低,于是对数据进行归一化,即:把 hash 表的所有 filed 打包成一个 json 格式的 string,举个例子:

// 优化前的特征为 hash 格式
hash key : user_2837947
127.0.0.1:6379> hgetall user_2837947
1) "name"    // 特征1
2) "薯条"     // 特征1的值
3) "age"    // 特征2
4) "18"     // 特征2的值
5) "address" // 特征3
6) "China"   // 特征3的值

// 优化后的特征为 string json格式
string key: user_2837947
val:
{
  "name":"薯条",
  "age":18,
  "address":"China"
}

特征进行打包后解决了一次请求去多个 slot 获取数据时延较大的问题。但是这样做可能带来新的问题:若 hash filed 过多,string 的 value 值会很大。目前想到的解法有两种,一种是按照类型将特征做细分,比如原来一个 string 里面有 300 的字段,拆分成 3 个有 100 个值的 string 类型。第二种是对 string val 进行压缩,在数据存储时压缩存储,读取数据时在程序中解压缩。这两种方法也可以结合使用。

如果这样仍不能满足需求,可以在持久化 KV 存储前再加一层缓存,缓存失效时间根据业务特点设置,这样程序交互的流程会变成这样:

一个95分位延迟要求5ms的场景,如何做性能优化


 

代码层面

接着来优化一下代码。首先需要几个工具去协助我们做性能优化。首先是压测工具,压测工具可以模拟真实流量,在预估的 QPS 下观察系统的表现情况。发压时注意渐进式加压,不要一下次压得太死。

然后还需要 profiler 工具。Golang 的生态中相关工具我们能用到的有 pprof 和 trace。pprof 可以看 CPU、内存、协程等信息在压测流量进来时系统调用的各部分耗时情况。而 trace 可以查看 runtime 的情况,比如可以查看协程调度信息等。本次优化使用 压测工具+pprof 的 CPU profiler。

下面来看一下 CPU 运行耗时情况:

右侧主要是 runtime 部分,先忽略

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值