80后聊架构 参与线程究竟能不能优化吞吐量

《架构师之路：架构设计中的100个常识点》四：功能与裁减性，线程数与吞吐量

之前聊了，啥时刻应该优化延时(Latency)，啥时刻应该优化吞吐量(Throughput)。

画外音：短视频二维码附在文末。

有一些评论，值得和大家裁减探讨下：

1. 延时和吞吐量，是评价啥的目的？

再次强调一下，在功能优化中：

performance和scalability，评价维度并不一样。

前端架构，为什么聊performance更多？

前端FE，Android，IOS的童鞋，经常说优化performance，很少说优化scalability。

紧缩资源，缓存图片，异步加载，Webpack代码拆分，PWA等等这些技术，都是优化performance的，服务好一个用户，让一个用户速度快。

后端架构，要不要优化performance，当然要。数据库访问200ms，引入缓存20ms，速度更快了。

后端架构，为什么聊scalability会更多？

由于系统难点不在于1个用户的延时是200ms还是20ms，难的是：

而这些，就是scalability的领域。

这，是后端架构设计的外围，是scalability相关的常识点，也是我在“100个架构常识点”里要重点讲的内容。

2. 线程数和吞吐量，究竟是什么相关？

我在短视频里举例：“参与线程数是提高吞吐量的方法之一，1个线程1秒钟处置5个恳求，吞吐量是5，参与到10个线程，吞吐质变成50”。

有好友指出我说的不对，说参与线程数，有时刻能优化吞吐量，有时刻不能优化吞吐量。

这位好友说的对，我表白不严密，那么疑问来：

上方稍微开展具体说下。

首先，上班线程数是不是设置得越大越好？

答案显然能否认的。

第二个疑问，调用sleep()函数的时刻，线程能否不时占用CPU？

不占用，休眠时会把CPU让进去，给其余须要CPU资源的线程经常使用。

不止sleep，一些阻塞调用，例如网络编程中的：

都会让出CPU资源。

第三个疑问，单核CPU，设置多线程有没无心义？单核CPU，设置多线程能否提高并发功能？

即使是单核，经常使用多线程也是无心义的，大少数状况也能提高并发。

第四个疑问，经常出现服务线程模型是怎样的？

了解经常出现的服务线程模型，有助于了解服务并发的原理，普通来说互联网经常出现的服务线程模型是：IO线程与上班线程经过义务队列解耦模型。

画外音：还有一种是无锁纯异步，可参考lighttpd的复线程形式，这种模型齐全无锁，但无法应用多核长处。

这类线程模型，示例如下：

如上图，很多Web-Server与服务框架都是经常使用这样的一种“IO线程与Worker线程经过队列解耦”类线程模型：

这个线程模型运行很广，其特点是，上班线程外部是同步阻塞口头义务的，因此可以经过参与Worker线程数来参与并发才干。

画外音：纯异步模型未来再聊。

“IO线程与上班线程经过队列解耦”类线程模型，上班线程的上班形式是怎样样的？

了解上班线程的上班形式，对量化剖析线程数的设置十分有协助：

上图是一个典型的上班线程的处置环节，从开局处置start到完结处置end，该义务的处置共有7个步骤：

剖析整个处置的期间轴，会发现：

如何量化剖析，并正当设置上班线程数呢？

经过上方的剖析，Worker线程在口头的环节中：

经适量化剖析，例如打日志启动统计，可以统计出整个Worker线程口头环节中这两局部期间的比例，例如：

获取的结果是，这个线程计算和期待的期间是1：1，即有50%的期间在计算（占用CPU），50%的期间在期待（不占用CPU）：

当当当当！！！

论断来了：

N核主机，经过口头业务的复线程剖析出本地计算期间为x，期待期间为y，则上班线程数（线程池线程数）设置为N*(x+y)/x，能让CPU的应用率最大化。

普通来说，非CPU密集型的业务（加解密、紧缩解紧缩、搜查排序等业务是CPU密集型的业务），瓶颈都在后端数据库访问或许RPC调用，本地CPU计算的期间很少，所以设置几十或许几百个上班线程是能够优化吞吐量的。

你，学废了吗？