面试官:“你是怎么思考优化策略的?”我:“我。。。”
本文最后更新于2 天前,其中的信息可能已经过时,如有错误请发送邮件到2156936367@qq.com

前言

优化策略很重要,前面MySQL、MongDB、包括负载均衡…..很多很多东西都需要优化,这个是很重要的,关系整个服务架构的性能,接下来就好好学习一下优化策略到底需要干些啥玩意

之前学的那些优化策略,真的看着配置就烦死了,很打击我的学习兴趣。今天学完Redis的优化,老师讲到不需要记住每一个配置到底咋写,需要的是整个优化策略的一个思路,又想到学长在腾讯面试种问到优化策略,我就觉得这玩意也太重要了。

我一改往日的复制粘贴操作(将课件中的配置直接粘贴到笔记),Redis 的优化笔记就显得和往日完全不同了,几乎没有配置,而是所有的Redis 整个优化策略方向的一个思考,比如从哪开始优化、优化的权衡……让整个优化的这个思考过程非常清晰。

因此,我像写这么一篇文章来讲讲优化策略的一个思考路线

1. 明确业务目标

我们知道业务就ToB、ToC、ToG 业务,不管是哪一个业务,业务都会有要求,我们可以用 SLA 来衡量这个要求

不同的业务有不同的 SLA,这个其实就是我们的一个指标

优化没有指标,那就不用优化,否则就是盲目调参

我们根据指标可以从多方面入手:性能相关的QPS、TPS、RT、p99 延迟;稳定性相关的可用性、RTO、RPO、ERROR;资源成本相关的CPU、内存、磁盘、机器;用户体验相关的…….等等

比如说,接口慢,我们不说优化一下接口的延迟,而是说把接口p99 2s 降到 500ms 以下,我们要有一个量化的的指标,不是凭感觉

2. 定位瓶颈

我们优化不是所有都要优化,而是优化那些不满足 SLA 的一些指标,找出整个系统中低于 SLA 的节点,如何找到这些节点?

还好我最近学了很多架构方面的东西,对整个互联网架构还是蛮熟悉的,其实就是分析用户的请求链路(这个不了解的可以先去我的上一篇文章看一下整个互联网架构)

我们可以在整个链路中找出拖累整个业务的节点,这些就是需要优化的

下面就是每个节点常见的一些问题:

层级常见问题
网络层带宽不足、跨地域访问、DNS 慢、连接数过多
Nginx / 网关层worker 配置不合理、连接数不够、限流缺失
应用层代码逻辑慢、线程池耗尽、接口串行调用
缓存层缓存穿透、击穿、雪崩、热 key、大 key
数据库层慢 SQL、索引失效、锁等待、连接池不足
MQ 层消息堆积、消费者太少、消费逻辑慢
系统层CPU 高、内存不足、IO 高、文件句柄耗尽
架构层单点、强依赖、没有降级、容量不足

当然,问题肯定不只这么多,只要有一个节点有问题,我们就去这个节点里面深挖,找出并优化那个瓶颈

3. 优化策略的思路

1. 减少请求量

最好的优化就是让系统做有用功

我们可以限流、缓存、去重、防止重复提交、静态资源…..通过这些减少数据库的压力,因为请求最终是到达数据库的,我们可以在它到达之前设置重重关卡

2. 缩短处理链路

链路越长,延迟越高,故障点就越多

我们可以串行改并行、同步改异步、阻塞改非阻塞、I/O多路复用用epoll、MQ消息队列做异步解耦削峰填谷减少远程调用、核心链路与非核心链路拆开…….

3. 垂直优化

垂直优化也就是提高单节点能力

我么可以提升CPU、内存、磁盘、网络性能、增大连接池、MySQL加索引…..反正就是使劲给一个机器造成最牛逼的

4. 横向优化

当单机优化到一定程度,就要考虑分布式扩展优化了

比如Nginx负载均衡、主从复制、集群、分库分表、多副本、k8s自动扩缩容

5. 缓存

这个就很熟悉了

业务访问模式、数据结构、key设计、命令使用、缓存命中、内存、网络、持久化、主从、集群……

这里不过多赘述了

6. 数据库

数据库通常是系统最容易成为瓶颈的地方

SQL语句、索引、表结构、读写分离、分库分表、锁、冷热数据分离……

一般先优化SQL 和索引,然后做读写分离、最后就是分库分表

7. MQ

高峰流量不能全部直接打到后端,实现异步、解耦、削峰填谷

8. 限流、降级、熔断

我们优化不只是让整个业务跑的快,还有就是碰到大流量如何扛住

可以限流、降级、熔断、隔离、超时、重试(防止重试风暴)

9. 容量规划

上面说到大流量,我们需要规划好,防止大促QPS暴涨,系统直接炸了,因此做好容量规划很重要,峰值QPS可能是平时的10倍以上

10. 可观测性

没有监控,就没有优化,优化前必须知道系统现在怎么样,其实也就是SLI

监控三大指标:Metrics 指标、Logs 日志、Tracing 链路追踪

四大黄金信号:流量、延迟、错误、饱和度

其实定位瓶颈这个过程靠的就是监控

系统慢,看一些指标Metrics(CPU、内存、IO、网络、数据库、Redis….)、链路追踪Tracing 找到慢在哪个节点,然后看日志Logs有没有异常啥的,然后看数据库,最后肯定可以找到瓶颈,然后针对性优化,方案权衡,压测验证

4. 选择方案时看权衡

所有优化都有代价,一定要体现“权衡意识”。

优化不是越复杂越好,要考虑收益、成本、风险和业务一致性要求。

5. 验证结果

优化必须可验证,优化后的效果是否真实。

6. 防止回退

上线前要压测,线上要灰度,观察核心指标,如果指标不符合预期,要能快速回滚。

总结

优化其实就是 我们将SLI 和 SLA 对比,再根据监控去链路找瓶颈,找到后针对性优化,然后选择方案权衡,最后验证发布,防止回退

觉得有帮助可以投喂下博主哦~感谢!
暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
Hello! I'm 臭企鹅!