关于系统瓶颈的面试问题

[yyyfor]

求教一下各位大佬，

面试老是被问到系统瓶颈的问题，如果现在正常运行的系统，要改造提高 10(甚至 100)倍的 qps，会遇到哪些问题、瓶颈？

关于这类的问题，应该如何去分析和描述？

[murmur]

全年提升 100 倍 qps 也就阿里腾讯能有这个级别
其余的第一时间考虑不是错峰么，能错峰为啥要全年 qps 拉这么满
最典型的例子，12306 优化了多少年，最终不还是靠错峰解决的问题，现在的双十一 双十二也都是错峰抢购

[yuedingwangji]

@lewis89 大佬呀

[liuxu]

@lewis89

#7 我补充一点，不知道对不对

限制单机，100k 的 get 。
由于 redis 从内存读，所以内存没有限制。
主要是 cpu，假如单机 cpu 不够的话此问题无解，除非升级 cpu 。
带宽问题需要保证，一个 get 10 字节，100k * 10 = 1MB/s = 10Mbps，100 个字节就需要 100Mbps 。
linux 可使用端口一般默认为 32768 - 60000 之间，可以通过 sysctl(/etc/sysctl.conf)修改 net.ipv4.ip_local_port_range 增加更大范围，1024-65535 。但这样会存储一个问题，假如 3306 被 redis 分配掉，你再想启动 mysql，只能手动释放这个端口，然后启动 mysql 。这里只是举例，这种负载情况自然不建议单机起多服务。
由于大量短连接会造成系统大量 TIME_WAIT 的端口，导致端口不可用，可以通过 sysctl(/etc/sysctl.conf)的 net.ipv4.tcp_tw_reuse 来快速重用。
大量链接下系统 nofile 会快速占用，debian 系默认通常为 1024，通过修改 ulimit(/etc/security/limits.conf ）的 nofile 解决，需要注意的是它是用户的 pam 限制，需要给启动 redis 的用户增加此选项，可直接修改全局文件全部增加即可。
关于 redis 磁盘落地问题，使用三星的 1T pcie 4.0 接口的 nvme ssd，顺序读写基本在 3GB/s 以上，随机 4k 读写可达到 500k 以上，是读和写，感谢时代。
网络拥塞问题，debian 系可以直接修改 /etc/sysctl.conf 文件的 net.core.default_qdisc=fq 和 net.ipv4.tcp_congestion_control=bbr 来抢占发包。rhel 系自行升级内核到 4.10 以上，我说的就是辣鸡 centos 。
由于现在 aio 一般使用 epoll，C10K 导致大量上下文切换，可以使用最新 linux 内核 5.1 以上，使用 io_uring，根据有关评测，系统调用只有 epoll 的 1/10 。


同时回答楼主，扩展到 10 倍或者 100 。做横向集群扩展的时候，压力在 LB 的 hash 均匀分配和性能上。同时可拆分业务，通过 LB 或者 DNS 分配到不同子集群。

[liuxu]

@lewis89 你不用发这么多问号，不同业务有不同的处理办法。#8 的业务是发送短信，短信任务入队列削峰是正确的方式，现代短信发送一遍是 http 做接口调用，不仅有单机 100k 接收请求问题，还有单机 100k 发送 http 请求问题。

[lewis89]

@liuxu #23 关键人家只有 5 个线程，并发能力只有 5..

[lewis89]

@liuxu #23 5 个线程并发能打垮的系统，我还没见过 .. 我的垃圾树莓派 pi 都能 web 读并发到 100 以上

[liuxu]

@lewis89 根据你说的饿了么订单这类及时任务，拆分业务，分表，是唯一选择。可以从 DNS，LB，业务才分，hash 分表，数据库集群解决，我没说有问题。

[liuxu]

@lewis89 线程和并发不一定是 1 对 1 关系，同步任务是 1 对 1，现代 aio 下，协程 epoll 可以做到单线程多并发。

[togou]

看傻了

[lewis89]

@liuxu #22 另外 bbr 这种快启动也不是万能的，最好的办法还是根据包的大小来设置窗口跟窗口扩大缩小的策略，不过大部分场景 基本上都是小包..

[lewis89]

@liuxu #27 有几个人会自己用 非阻塞式 IO 配合 epoll 关键字 自己手写多路复用，而且还要考虑写的 buffer 满了一大堆问题，另外用异步的更少见，有的异步甚至就是用线程池模拟出来的，一般默认 5 个线程就是 5 个阻塞式的 IO

[liuxu]

@lewis89 bbr 当让不是万能的，满负荷下 bbr 还可能降低发包能力，但不至于自己设置窗口扩大缩小的策略吧，能改窗口，又觉得没几个人能手写 epoll，看来你是写 C/C++，做驱动开发的吧。应用层开发不会动 tcp 协议层，现代所有业务开发语言都支持异步和协程，很简单的语法糖。你说的手写异步模型超纲了，再说下去我就要开始改电路，处理 INT 中断，做真异步了，告辞

[young1lin]

我做个补充。

看你现有的系统是哪种了，单体，前后端分离单体，SOA 还是微服务架构。

Redis 在 Get 小数据时，十万并发是勉强能支撑住的，如果是 Get 超大的对象，那可能就不行了。要增加十倍或者一百倍就有些骚操作了。用 Codis 或者官方提供的 Cluster 方案，将原来的数据拆分到多个 Redis 实例上。Redis 6 的多线程就是增加了接受请求的线程而已，不是以前的复用同一个线程，Set 和 Get 操作还是以前的单线程执行。一般现在都是 NUMA 架构，然后你可以进行绑核这种骚操作。

我建议你看下《微服务架构设计模式》这本书，X 、Y 、Z 轴扩展。应用水平扩展，拆分成服务，最好是无状态服务（当然这是最好的情况）水平扩展没什么障碍，Z 轴就是根据用户请求来进行绑定某些机器，例如粘性 session 。

其实还有前端的 Cache 、DNS 、登录的无状态化、动静分离、F5 、LVS 、一致性 Hash 、业务 /数据 /系统隔离、七种负载均衡办法，面试官应该想听到的是这些。

[lewis89]

@young1lin #32 ryzen 的服务器版本还没流行吧，怎么 NUMA 已经成为标配了.. 不过多个物理 CPU 的服务器 确实存在 NUMA 的问题..

[OldCarMan]

不错不错，感觉看了场高端局交流比赛。

[Lemeng]

问到了

[pavelpiero]

@OldCarMan +1

[lesismal]

真热闹，我也补充一些吧

前面的各位都只是说到丢给 redis，但是单就 redis 也有击穿、穿透、雪崩各种说法，1s 几十万全丢给 redis，也只能说各位逮到个好玩意就往死里操，还是太暴力太浪费了

缓存和持久层其实都还是局部性原理的范畴，既然局部性原理，就再进一步，内存缓存，内存缓存这块跟 redis 放一块的话也有多种实现方式，比如：
1. 热点 key 的数据，定时或者发布订阅或者其他什么更新机制，服务节点 load 到自己的内存，请求来了直接返回自己内存缓存的
2. 同 key 访问加锁串行化，上一个请求回来后把结果带回来，其他等待锁的先检查是否有结果了，有了就直接拿结果、不落到 redis 了，相当于合并了到 redis 的请求。这个过程当然也可以结合或者改成内存缓存，比如内存的 1s 过期，内存没有、再 redis 、持久层之类的

高配点的机器，如果不是大 key 、value，几十万 qps 没啥压力，我自己的 i7 PC 测自己的 arpc 都能 40 多万 qps

[boobo]

mark 一下先...

[janxin]

这是思路问题，先看问题出在哪里然后根据问题对应解决。

常用方案是知识储备，分析解决问题是经验思路