初级后端的疑惑，如何估算接口 qps，以及 redis 占用多少容量， nginx 能抗多少并发

[waibunleung]

如题，参与公司业务开发中，经常会遇到这样的问题：

1. 这个业务入口会为接口带来多少的 qps 增长？
2. 这个接口能抗住多少 qps ？
3. 这个业务要上缓存的话，预计会带来多少缓存占用？
4. 现有的 redis 能抗多少并发？内存占用是否过高？是否需要增加机器？
5. 现有的 nginx 集群，能抗住多少并发？是否需要增加机器？
6. 业务上线预计会带来 1000qps 的增长，服务器资源(接口，缓存，数据库)是否能扛得住？
7. 这个业务的性能瓶颈在哪里？怎么查出来？ 等等

总结的问题就是，大佬们是如何进行业务的容量评估，性能评估，性能排查的？

希望能有大大能逐点解答一下上面的 7 个问题你们在工作中是怎么去分析的，身为菜鸟的我每次遇到这种问题，都头痛半天，然后还是去问大佬怎么怎么弄，但是几次下来也没有总结到套路，都快怀疑自己适不适合干下去了.... 所以想向各位请教下，学习一下大家都是怎么评估和排查问题的，想在这方面有点成长，万分感谢！

[waibunleung]

@Rocketer 就是想知道这种评估方法是，这感觉只回答到第 2 点，缓存之类的要怎么估算呢？希望能再给些指点

[waibunleung]

@LeeReamond 2，4 是基本功，那想问一下有什么方向去估算呢？能否给些方向说明一下？感谢~

[LeeReamond]

@waibunleung 我觉得你这样问没什么意思，问也问不出什么。我的意思是作为开发，常用的工具链最起码要搞熟，一般一个网络服务中有若干个子服务，比如网关、业务、缓存、（虚拟的）数据层，这些不用挨个罗列是所有人都知道的事，搞熟的意思最起码你要知道每个框架作为工具的负载能力，你比如你在调数据库业务的时候，你知道表有多大，什么储存方式，业务如何索引，集群的负载增幅是多少，那你应该能估算出单节点大概的时间范围，其他环节同理，遇到特殊情况完全估算不出的那不妨测一测。我的意思是这么简单的道理，为什么要问呢。

[waibunleung]

@LeeReamond 就你说的这个场景，「你比如你在调数据库业务的时候，你知道表有多大，什么储存方式，业务如何索引，集群的负载增幅是多少，那你应该能估算出单节点大概的时间范围」 比如数据库是 mysql，我知道表有 3000w 行，innodb 存储，索引覆盖了要查询的字段，集群的负载增幅我并没有理解到你想表达的是什么意思，当我不知道，那估算单节点的时间范围是怎么估算的呢？

[waibunleung]

@LeeReamond 也不是这样问没有意思，主要是你的回答我也没从里面看出什么经验总结来....你所说的基本功，我认同这一点，那既然是基本功，就肯定可以总结出一两点套路的

[LeeReamond]

@waibunleung 你当然无法从我的回答总结出经验，纸上谈兵谈不出兵，你跑一跑当然就有经验了。比如你这个例子里，正常开发对于不同数据库的负载能力心里有个量级，比如如果表内有 30 万行，大多数情况下我不会太在意搜索性能，而 3000 万行对于 mysql 单表来说属于稍大的量级，需要给予一些关注，同理如果是 oracle 那又是另一种情况，我是这个意思。具体说到存储的话，单表不说明问题，具体与分区分表和你的业务高度绑定，当然只有你自己知道多快，不过你写 sql 语句的时候通过估算复杂度可以估算出一个大概的量级，比如 a 语句会低延迟返回，b 语句需要花费若干秒，c 语句需要若干分钟等等，按数量级估算当然是开发的基本功。我说集群负载能力的意思是根据你集群方式的不同负载能力的增幅当然不是线性的。

同理关系型数据库是这样，对业务中其他环节你都应该有这样的估算，比如上述所谓 a 语句低延迟返回，这也是少数有可能造成其他环节瓶颈的业务，就需要更量化的分析。

[waibunleung]

@LeeReamond 我觉得问题就在于，「正常开发对于不同数据库的负载能力心里有个量级」 这个点不好把握，30w 行内不会在意性能，3000 万行予以关注可以理解，但是 3000 万行的单表，会引起我两个问题，
1.数据量一直增长到 3000 的过程中，查询请求也一路增长，我会一直担心数据库顶不住，因为虽然我能预估一个查询多久能返回，但是没法预估这张表能抗得住多少并发请求，就是我没有办法给出 「这种情况下，如果你再多开一个业务入口，流量上涨，更多的流量到达数据库之后，数据库会扛不住的」的结论给到运营或者老大
2. 「正常开发对于不同数据库的负载能力心里有个量级」这个量级是怎么得来的？或者说你是怎么知道 mysql 什么机器配置下能抗多少请求的呢？
还望再指点一二

[LeeReamond]

@waibunleung 不知道你写了这么多有什么好指点的，跟你聊真是浪费时间，多试就完事了

[waitingChou]

这个业务入口会为接口带来多少的 qps 增长？
===== 这个基于原有页面的曝光，和类似入口的点击率来估算，实在不放心可以灰度
这个接口能抗住多少 qps ？
===== 压测
这个业务要上缓存的话，预计会带来多少缓存占用？
===== qps 都有了，可以估一个占用上限出来。 当然，有些数据是公用的，只要缓存一份，有些用户独占的，看你访问用户数，再结合你的缓存过期时间来估算。比如缓存时间一天，一天内有 1 万用户访问这个接口，每个用户需要缓存数据量。
现有的 redis 能抗多少并发？内存占用是否过高？是否需要增加机器？
===== 看 redis 缓存的数据类型和数据大小，配合历史的 redis 监控图标数据来做分析估算，比如流量增加一半，假设 redis 线性增加会到一个什么量级。
现有的 nginx 集群，能抗住多少并发？是否需要增加机器？
=====这个没多少经验，暂不做回答。
业务上线预计会带来 1000qps 的增长，服务器资源(接口，缓存，数据库)是否能扛得住？
=====正常来说思路还是压测，但是如果考虑这么多，那为了真实需要在生产压测，风险比较高。
这个业务的性能瓶颈在哪里？怎么查出来？ 等等
===== 我个人两种思路，第一种直接看代码，分析这段代码有哪些外部调用 /依赖，然后再从中挑出风险最高的部分。 另外一种压测配合火焰图或者 benchmark 类工具实际运行分析。

[waibunleung]

@waitingChou 很好，给了不少方向！感谢感谢

[waibunleung]

@waitingChou 就是想要这样形式的回答，实在符合我的期待

[awanganddong]

这是架构师之路的大概介绍。
https://cloud.tencent.com/developer/article/1553360

技术层面就是对现有的组建进行性能分析。
比如我们语言是 php

一台服务器 256 个 php-fpm 进程， 每个 fpm 进程 1s 支持 3 个响应。那就是 256 * 3 就是单台 qps 上限。再乘以总服务器数。这个就是单台服务器能承载的 qps

还有就是对 mysql 的压测。mysql 理论上读+缓存。 写的话最好压测下 mysql 的极限。比如使用 mysql 压力工具。或者使用 update 手动压测。从 mysql 开始变慢算起。得到一个 mysql 写的 qps 。 读的话，一般从 mysql 连接数上入手。 一般 mysql 支持 2000-5000 左右的链接。 每次请求就打开一个 mysql 链接。 这块我现在还不太明晰，正实践中。