关于并发你真的了解吗？

Posted 2020-09-25

关于并发你真的了解吗？（一）

本文仅代表带个人观点及理解，本人只是一个编程小菜鸟，如果有不对的地方。请大佬轻喷！

    前言：对于很多工作时间短或者编程经验不足的程序员来说，大多数会觉得并发这个词离自己太遥远，之所以知道并发也不过是因为受那些技术大佬成天讨论并发等问题耳濡目染罢了。更有甚者，一些所谓的"项目经理"。一边侃侃而谈"大数据"，"高并发处理"等等高级问题，一边理所当然的写出Select * 或者是毫无规范性的性能极差的代码。当然这也跟国内的大环境有一定的关系，导致很多程序员仅仅只想满足功能完成任务即可。实际上并发的处理是和我们日常工作息息相关的无论初级，中级，高级程序员。本文将从整体架构和日常工作，两个角度来分别讲解关于并发的两三事。只想了解日常工作中如何规范化的童鞋下拉到自己关心的部分查看阅读。

  说道并发，首先你需要了解几个词语：

 IIS连接数、IIS并发连接数、IIS最大并发工作线程数、应用程序池的队列长度、最大工作进程数调试

IIS连接数

一般购买过虚拟主机的朋友都熟悉购买时，会限制IIS连接数，这边先从普通不懂代码用户角度理解IIS连接数

顾名思义即为IIS服务器可以同时容纳客户请求的最高连接数，准确的说应该叫"IIS限制连接数"

这边客户请求的连接内容包括：

1、网站html请求，html中的图片资源，html中的脚本资源，其他需要连接下载的资源等等,任何一个资源的请求即一次连接（虽然有的资源请求连接响应很快）

2、如果网页采用框架（框架内部嵌套网页请求），那么一个框架即一次连接

3、如果网页弹出窗口（窗口内部嵌套网页请求），那么一个窗口一个连接

限制连接数即为虚拟主机供应公开的IIS连接数标准，如果购买的IIS连接数为50,那么我们不得不考虑网站的内容框架和访问量

如果网站图片够多，弹窗窗口随意（可能连时间选择框、简单条件筛选框也用弹出新窗口），加上不得已的打开新页面浏览内容，那么仅仅能容忍10个人同时操作也很正常，我不会把这个操作描述为很多网站说的"10同时在线"，这很容易让人误解，在用户的一次请求（表面上可能是刷新一次网页，实际上内部请求不止一次，事实上很少只有一次）都完成得到服务器响应完毕之后，连接全部会被释放，当然在你看到展示的页面之前，内部嵌套如果有请求图片等连接请求，连接会早早的被释放

事实上，很多企业门户网站访问量低的惊人，IIS连接数为50也是绰绰有余了

IIS并发连接数

其实，普通用户常说的"IIS链接数"就是这边的"最大并发连接数" ，我这边IIS默认最大并发连接数为：4294967295，这是一个很惊人的数字，难道这代表着网站能具有并发执行连接数为4294967295的能力？

这边我做几个假设：

1、很多虚拟主机供应商所说的无并发连接数限制真的成立吗？

2、每个连接的处理，IIS都会开启一个线程去处理，假设这个处理方式成立，那么4294967295个并发连接请求来了是否IIS会立即启动4294967295个线程去处理？

对于1：很显然不成立，最大并发连接数的设置绝对有上限

对于2： 这是很多朋友的误区，假设4294967295并发连接同时来了，IIS不会立即启动4294967295个线程去处理，因为这不现实，对于处理连接，IIS是有" 最大并发工作线程数 "限制的，这是我下面要介绍的，我从一些资料上查阅到， 该数字跟操作系统 相关，win7 系统的IIS的值是10（或者其他不确定），VS2012自带的IIS Express的值是80。对于w indows 服务器版本的系统 的具体值不清楚，即4294967295个并发连接来了后，（这边以win7下的10为例），iis第一时间只能启动10个工作线程去处理，那么其他42949672 85 必须排队，排队对用户的体验来说就是网页正在加载，但是什么都不显示，然后此时购买了据虚拟主机供应商所说的无并发连接数限制的客户就要开始狂暴了，为何购买了所谓的"无限并发连接数"，还是会一直在加载的情况，我只能说这就是IIS处理能力有限的问题了

当然服务器没有直接返回" HTTP Error 503. The service is unavailable."应该也算是一些你花更多钱的安慰吧，因为你只购买了IIS连接数为50的话，那么第50+1个连接请求操作得到的就直接是"HTTP Error 503. The service is unavailable."了

另外，如果web服务器的硬件设备够爽朗（牛逼），那么IIS的工作线程也会处理的更快，那么响应的用户等待的时间也会更短（前提是你的IIS连接数够大哦，否则就直接503了哦）

总的来说，最大并发连接数，影响了排队的数量，

很多时候需要我们评估自己的网站的最大并发连接数，然后来进行设置最佳数量

IIS最大并发工作线程数

这个在上面有所涉及，简单的说就是IIS在并发连接请求过来时的处理机制，它会更机智的以某个数量级为单位来分批处理，让没有处理连接请求排队等待，用户浏览器中对于排队等待的响应就是"正在加载"，这比页面直接显示" HTTP Error 503. The service is unavailable. "更加能让人接受，但是切勿气急败坏的怒点刷新按钮，因为点的越多，你的请求在排队队伍中越靠后。

当然很多朋友会说，为什么我有时候第一次刷不出来，重新多刷一次内容就出来了？ 

1、页面脚本哪个地方下载或者处理出了问题，导致页面显示异常或者直接不显示

2、你重新刷新的那个秒级别的操作，web服务器更快速的已经处理好了其他队列的请求或者他人放弃了对web服务器连接请求的操作

3、路由或者宽带网络运营商问题（不稳定）

4、浏览器或者本身电脑问题

那么现在问题来了，最大并发连接数，影响了排队的数量，那么有没有进步影响排队数量的设置? 有的：队列长度

队列长度

假设最大连接数设置为100，1000个并发连接请求过来了，首先900直接返回给客户"HTTP Error 503. The service is unavailable."

然后IIS先启动（假设最大并发工作线程数为10）10个线程处理请求，其他90个进入排队状态，如果此时如下操作：

找到网站的所属应用程序池，"右击高级设置"->"常规"->"列队长度"，设置为20

那么实际情况又会变成什么样子呢？只会有20个进入排队状态了，70（90-20）个请求也会立刻返回"HTTP Error 503. The service is unavailable"

iis默认队列长度设置是1000，范围在10-65535 之间

最大工作进程数

应用程序池一般默认最大工作进程数为1，可以找到网站的所属应用程序池，"右击高级设置"->"进程模型"->"最大工作进程数" 来修改设置

如果这个值大于 1，那么当有连接请求时会启动多个新的工作进程实例，可启动的最多进程数为您所指定的最大工作进程数，后续更多的请求将以循环的方式发送至工作进程，这个每个工作进程都能承担负载一些连接请求，当然是以消耗cpu等硬件做代价，这是值得的，如果web服务器cpu使用率很低但是又需要更高效的处理并发连接请求，为何不这么做呢？

如果网站中用到了依赖进程的Session和Cache等对象，则不能保存在服务器内存中，存储方式选用StateServer或者SQLServer会更好，另外多个工作进程切换时会有上下文复制，这也是资源消耗更多地方

最大工作进程数调试

最大工作进程数的设置方法：（拷贝）按照每工作进程能承载30个并发的原则来确定应用程序池的最大工作进程数。同时要注意，每个工作进程大约会占用200M左右的系统内存，在设置最大工作进程数的时候，要主要最大工作进程数与200M的乘积不要超过系统最大可用内存数。一般情况下，建议按照每次增加5个工作进程数的方式对最大工作进程数进行调整，调整完后对网站观察一段时间，如依然无法满足要求，再继续增加5个工作进程数。

关于并发你真的了解吗？（二）

 

对于一台服务器的公司来说如果您有提升并发处理的需求但是又不想增加服务器数量的话，以下方法有可能对您有所帮助：

1.如果web服务器cpu使用率很低但是又需要更高效的处理并发连接请求，您可以尝试设置最大工作进程数。

IIS作为Windows平台下Asp.Net网站发布的默认WEB服务器，在性能上是提供了比较大的弹性和可伸缩性，通过应用程序池工作进程数的设置，可以支持从几十到上万并发数量的访问。

在主流的主机上，每个应用程序池的单一工作进程，能够大约承受30-50个左右的并发，如果超出此并发数量，可能会出现IIS无法响应、或响应时间明显变长的问题。通过合理设置应用程序池的最大工作进程数，可显著提高IIS应对高并发的能力，减少网站响应时间。（具体设置方式可详见上一篇文章《关于并发你真的了解吗？（一）》博客园地址：http://www.cnblogs.com/xinwuhen/p/7049093.html）

2.建议使用 InProc 的Session保存机制

3.合理的资源回收机制：大多数应用系统都存在工作时间使用量高、非工作时间使用量低的情况，针对这种现象，在系统非忙时应合理的释放操作系统资源，因此，应合理设置应用程序池的【限制超时】和【回收时间间隔】属性。

4.程序优化（详见《关于并发你真的了解吗？（三）》）

5.数据库操作优化（详见《关于并发你真的了解吗？（三）》）

多服务器，对于多服务器的公司来说。以下方式可能对您有所帮助：

1.对于多台服务器来说，首先也要满足单独服务器优化配置。上面有讲述，这里需要注意对于多服务器Session的保存机制可以使用其他的方式下文有重点介绍。

2.您可能会遇到，某一台或者多台服务器已经超过了并发处理量。而其他服务器却还有很富余的并发处理能力的情况。

此种情况您可能需要分流操作，我知道的有三种分流：

2.1，集群 - 将并发请求分配到不同的服务器上，可以是业务服务器，也可以是数据库服务器。集群技术：多台服务器应看作为一个服务集群而不是单一的个体服务器。群集技术是使单个服务器实现物理和程序上的连接，并对服务器之间的通讯进行协调，以使它们能够执行共同的任务。即便某一台服务器停止运行，一个由进程台调用的故障应急程序会自动将该服务器的工作负荷转移至另一台服务器，以保证提供持续不断的服务。除故障应急程序外，某些形似的群集也使用负载平衡功能，该功能可使计算负载在联网的计算机间得以分配。

2.2，分布式 - 分布式是把单次请求的多项业务逻辑分配到多个服务器上，这样可以同步处理很多逻辑，一般使用与特别复杂的业务请求。分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。内聚性是指每一个数据库分布节点高度自治，有本地的数据库管理系统。透明性是指每一个数据库分布节点对用户的应用来说都是透明的，看不出是本地还是远程。在分布式数据库系统中，用户感觉不到数据是分布的，即用户不须知道关系是否分割、有无副本、数据存于哪个站点以及事务在哪个站点上执行等。

2.3，CDN - 在域名解析层面的分流，例如将华南地区的用户请求分配到华南的服务器，华中地区的用户请求分配到华中的服务器。

3.负载均衡设备（网上很多文章，不过多介绍）

4.使用消息队列。队列的使用除去了接收和发送应用程序同时执行的要求。减少并发处理数量的占用

5.缓存机制：将需要频繁访问的资源存放在缓存中不仅可以降低数据库压力而且还可以提高访问速度进而提高用户体验。适程度而定必要时可以考虑缓存服务器的搭建。

6.数据库分库分离活跃数据 ：可以自定义规则来判定哪些访问频繁的数据或者重要访问来访问单独库，即"重要数据特殊对待"。从而减轻主库压力。并且可以提高用户体验。

7.降低响应时间（详见《关于并发你真的了解吗？（三）》），总体分为降低程序执行时间，降低数据库操作时间。要知道即使是毫秒级的程序执行速度差异，在足够大的并发访问量下。差距也是异常惊人的。

8.Asp.Net的Session共享

Asp.Net提供了五种Session保存机制：

（1）Off 设置为不使用Session功能 性能 无

（2）InProc 置为将Session存储在进程内，就是ASP中的存储方式 性能 最好 

（3）StateServer 设置为将Session存储在独立的状态服务中。 性能损失10-15% 一般用于服务器集群使用

（4）SQLServer 设置将Session存储在SQL Server中。性能损失10-20%

（5）Custom 自定制的存储方案 性能 由实现方式决定（一般自定义方式编写不难，但是好的性能方案很难）

在Asp.Net程序的web.config配置文件中对Session的保存方式进行设置。如果不显示指定Session的保存方式，默认使用InProc的方式保存，即Session由提供服务的工作进程保存。

为了提高IIS对高并发的支持，可以增加应用程序池的工作进程数，IIS会根据内置的调度算法，将用户的请求在多个工作进程间动态分配，如果搭建了服务器集群和负载均衡，则用户请求会在多台机器的多个工作进程间进行动态分配。在上述情况下，如果Session的保存方式依然为InProc，则用户请求在多个工作进程间切换时可能出现Session丢失的情况，导致请求失败或出错。

为解决上述为，需要将Session的保存方式设置为共享即StateServer"、"SQLServer"或"Custom"方式。这三种方法中，"SQLServer"方式需要安装独立的SQLServer数据库，"Custom"方式需要自行实现相应的Session存储与检索过程，部署起来相对复杂，相对上述两种方式，"StateServer"方式在功能性和可实施性上最好，因此重点介绍此种Session共享机制。

设置步骤

 

1、 确定StateServer服务器。如果只有一台WEB服务器，可指定当前服务器为StateServer服务器。如果存在多台服务器集群，可指定集群中的一台符合较轻的服务器作为StateServer服务器。

2、 修改注册表，允许远程访问StateServer服务。 

端口默认为42424，可根据需要进行修改，下文均以42424为例。

3、 打开【管理工具】-【服务】，找到"Asp.Net State Service"，点击右键，选择【属性】

在弹出的【属性】窗口中，将【启动方式】改为"自动"，然后点击【启动】按纽启动服务

4、 打开待修改网站主目录下的web.config配置文件，搜索找到"<sessionstate>"配置节点，如果不存在配置节点，则在"<system.web>"节点下新建"<sessionstate>"配置节点，并将节点属性修改为：
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" />
其中"tcpip=*"后的主机IP地址和端口可根据实际情况修改。修改完后保存配置文件即可。

注意事项

 

1、 Session中保存的自定义对象必须显示标记为可序列化"[serializable]"。如果未显示标记为可序列化，则在访问页面时会报错。

2、 StateServer服务器必须为Windows Server操作系统，如Windows Server 2003或Windows Server 2008。