《架构师之路：架构设计中的100个知识点》四：性能与扩展性，线程数与吞吐量
之前聊了，啥时候应该优化延时(Latency)，啥时候应该优化吞吐量(Throughput)。
画外音：短视频二维码附在文末。
有一些评论，值得和大家扩展讨论下：
- 有人说，延时与吞吐量是一回事，说延时下去了，吞吐量自然就上来了；
- 有人说，增加线程数，吞吐量就上来了；
- 有人说，增加线程数，吞吐量未必上来；
1. 延时和吞吐量，是评估啥的指标？
再次强调一下，在性能优化中：
- 一个用户慢，就去优化延时。
- 多个用户扛不住，就去优化吞吐量。
- 延时，是偏性能（performance）的指标。
- 吞吐量，是偏扩展性（scalability）的指标。
performance和scalability，评估维度并不一样。
前端架构，为什么聊performance更多？
前端FE，Android，IOS的童鞋，经常说提升performance，很少说提升scalability。
压缩资源，缓存图片，异步加载，Webpack代码拆分，PWA等等这些技术，都是提升performance的，服务好一个用户，让一个用户速度快。
后端架构，要不要提升performance，当然要。数据库访问200ms，引入缓存20ms，速度更快了。
后端架构，为什么聊scalability会更多？
因为系统难点不在于1个用户的延时是200ms还是20ms，难的是：
- 数据库里有1亿个用户时，系统扛不扛得住；
- 10万个用户同时访问时，系统扛不扛得住；
而这些，就是scalability的范畴。
这，是后端架构设计的核心，是scalability相关的知识点，也是我在“100个架构知识点”里要重点讲的内容。
2. 线程数和吞吐量，到底是什么关系？
我在短视频里举例：“增加线程数是提高吞吐量的方法之一，1个线程1秒钟处理5个请求，吞吐量是5，增加到10个线程，吞吐量变成50”。
有朋友指出我说的不对，说增加线程数，有时候能提升吞吐量，有时候不能提升吞吐量。
这位朋友说的对，我表达不严密，那么问题来：
- 啥时候增加线程数能提升吞吐量，啥时候不能？
- 设置线程数的依据是什么，是不是越大越好？
- 线程数设为多少，吞吐量能最大？
下面稍微展开详细说下。
首先，工作线程数是不是设置得越大越好？
答案显然是否定的。
- 服务器CPU核数有限，能够同时并发的线程数有限，单核CPU设置1000个工作线程没有意义；
- 线程切换有开销，如果线程切换过于频繁，反而会使性能降低；
第二个问题，调用sleep()函数的时候，线程是否一直占用CPU？
不占用，休眠时会把CPU让出来，给其他需要CPU资源的线程使用。
不止sleep，一些阻塞调用，例如网络编程中的：
- 阻塞accept()，等待客户端连接；
- 阻塞recv()，等待下游回包；
都会让出CPU资源。
第三个问题，单核CPU，设置多线程有没有意义？单核CPU，设置多线程能否提高并发性能？
即使是单核，使用多线程也是有意义的，大多数情况也能提高并发。
- 其一，多线程编码可以让代码更加清晰，例如：IO线程收发包，Worker线程进行任务处理，Timeout线程进行超时检测；
- 其二，如果有一个任务一直占用CPU资源在进行计算，此时增加线程并不能增加并发，例如以下代码会一直占用CPU，并使得CPU占用率达到100%：
while(1){ i++; }- 其三，通常来说，Worker线程一般不会一直占用CPU进行计算，此时即使CPU是单核，增加Worker线程也能够提高并发，因为这个线程在休息的时候，其他的线程可以继续工作；
第四个问题，常见服务线程模型是怎样的？
了解常见的服务线程模型，有助于理解服务并发的原理，一般来说互联网常见的服务线程模型是：IO线程与工作线程通过任务队列解耦模型。
画外音：还有一种是无锁纯异步，可参考lighttpd的单线程模式，这种模型完全无锁，但无法利用多核优势。
这类线程模型，示例如下：
如上图，很多Web-Server与服务框架都是使用这样的一种“IO线程与Worker线程通过队列解耦”类线程模型：
- 有少数几个IO线程监听上游发过来的请求，并进行收发包（生产者）；
- 有一个或者多个任务队列，作为IO线程与Worker线程异步解耦的数据传输通道（临界资源）；
- 有多个工作线程执行真正的任务（消费者）；
这个线程模型应用很广，其特点是，工作线程内部是同步阻塞执行任务的，因此可以通过增加Worker线程数来增加并发能力。
画外音：纯异步模型未来再聊。
“IO线程与工作线程通过队列解耦”类线程模型，工作线程的工作模式是怎么样的？
了解工作线程的工作模式，对量化分析线程数的设置非常有帮助：
上图是一个典型的工作线程的处理过程，从开始处理start到结束处理end，该任务的处理共有7个步骤：
- 从工作队列里拿出任务，进行一些本地初始化计算，例如http协议分析、参数解析、参数校验等；
- 访问cache拿一些数据；
- 拿到cache里的数据后，再进行一些本地计算，这些计算和业务逻辑相关；
- 通过RPC调用下游service再拿一些数据，或者让下游service去处理一些相关的任务；
- RPC调用结束后，再进行一些本地计算，怎么计算和业务逻辑相关；
- 访问DB进行一些数据操作；
- 操作完数据库之后做一些收尾工作，同样这些收尾工作也是本地计算，和业务逻辑相关；
分析整个处理的时间轴，会发现：
- 其中1，3，5，7步骤中（上图中粉色时间轴），线程进行本地业务逻辑计算时需要占用CPU；
- 而2，4，6步骤中（上图中橙色时间轴），访问cache、service、DB过程中线程处于一个等待结果的状态，不需要占用CPU；
如何量化分析，并合理设置工作线程数呢？
通过上面的分析，Worker线程在执行的过程中：
- 有一部计算时间需要占用CPU；
- 另一部分等待时间不需要占用CPU；
通过量化分析，例如打日志进行统计，可以统计出整个Worker线程执行过程中这两部分时间的比例，例如：
- 执行计算，占用CPU的时间（粉色时间轴）是100ms；
- 等待时间，不占用CPU的时间（橙色时间轴）也是100ms；
得到的结果是，这个线程计算和等待的时间是1：1，即有50%的时间在计算（占用CPU），50%的时间在等待（不占用CPU）：
- 假设此时是单核，则设置为2个工作线程就可以把CPU充分利用起来，让CPU跑到100%；
- 假设此时是N核，则设置为2N个工作线程就可以把CPU充分利用起来，让CPU跑到N*100%；
当当当当！！！
结论来了：
N核服务器，通过执行业务的单线程分析出本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N*(x+y)/x，能让CPU的利用率最大化。
一般来说，非CPU密集型的业务（加解密、压缩解压缩、搜索排序等业务是CPU密集型的业务），瓶颈都在后端数据库访问或者RPC调用，本地CPU计算的时间很少，所以设置几十或者几百个工作线程是能够提升吞吐量的。
你，学废了吗？
