Web服务器（WS）（比如apache2或者nginix（或者像tomcat（TC）这样的容器）会创build一个新的进程来处理接收到的请求，我担心的是支持大量并行用户（比如20K +并行用户）的服务器。
我认为负载平衡发生在Web服务器的另一端（如果它用于Tomcat等）。 所以从理论上讲，一个Web服务器应该接受所有（20K +）传入请求，然后才能将负载分发给支持它的其他服务器。
所以，问题是：Web服务器（WS）在一个进程中处理所有这些请求，或者巧妙地产生其他进程来帮助共享工作（我知道“客户端 – 服务器”绑定发生 – client_host：random_port plus server_host： fixed_port ）。
参考资料：在阅读本文之前： 用Apache来面向Tomcat我认为这是一个完成所有聪明工作的单一过程。 但是在这篇文章中提到了MPM（多处理模块）
它结合了两个世界中最好的，有一组subprocess，每个进程有一组独立的线程。 有些网站正在使用此技术运行10K +并发连接。
而且随着线程的产生，如上所述，线程变得越来越复杂。 （这些不是通过调用服务方法为每个单独请求提供服务的tomcat线程，而是Apache WS上的线程来处理请求并将其分发到节点进行处理。
如果有人使用MPM。 所有这些工作如何进一步的解释将是伟大的。
像 –
（1）随着儿童进程的产生，确切的作用是什么。 是subprocess只是为了调解的请求到tomcat或更多的事情。 如果是这样，那么在subprocess得到TC的响应后，subprocess是否将响应转发给父进程或直接发送给客户端（因为它可以从父进程得知client_host：random_port ，我不确定这是否允许在理论，虽然subprocess不能接受任何新的请求，因为只能绑定到一个进程的fixed_port已经绑定到父进程。
（2）由subprocess或父进程共享什么样的负载。 再次，它几乎必须和（1）中的一样。 但是我不确定的是，即使在理论上，如果一个线程可以直接发送请求到客户端。
Apache历史上使用prefork模式的处理。 在这个模型中，每个请求==单独的操作系统（OS）进程。 这叫做“prefork”，因为Apache在内部分发了一些备用的进程和进程请求。 如果preforked进程的数量不够 – Apache叉新。 优点：进程可以执行其他模块或进程，不关心他们做什么; 缺点：每个请求=一个进程，使用太多的内存和操作系统分支也可能是缓慢的请求。
Apache – 工人MPM的其他模型。 几乎与prefork相同，但使用的不是OS进程，而是OS线程。 线程 – 就像轻量级的过程。 一个OS进程可以使用一个内存空间运行多个线程。 工人MPM使用更少的内存和创建新的线程快速。 缺点：模块需要支持线程，模块崩溃可能会崩溃所有操作系统进程的所有线程（但是这对你并不重要，因为你只使用Apache作为反向代理）。 其他缺点：在线程之间切换时CPU 切换上下文 。
所以是的，在你的情况下工人比prefork好得多，但是…
但是我们有Nginx 🙂 Nginx使用其他模式（顺便说一下，Apache也有事件MPM）。 在这种情况下，你只有一个进程（好吧，可以是几个进程，见下文）。 怎么运行的。 新的请求上升特殊事件，OS进程唤醒，接收请求，准备应答，写回答和睡眠。
你可以说“哇，但这不是多任务处理”，是对的。 但是这个模型和简单的顺序请求处理有一个很大的区别。 如果你需要写大数据来减慢客户端速度，会发生什么？ 在同步的方式你的过程需要等待确认数据接收，并只处理新的请求。 Nginx和Apache事件模型使用异步模型。 Nginx告诉操作系统发送一些数据写入这个数据到OS缓冲区，并…睡觉，或处理新的请求。 当操作系统发送数据 – 特殊事件将被发送到nginx。 因此，主要的区别 – Nginx不等待I / O（像连接，读取，写入），Nginx告诉操作系统他希望操作系统发送事件给Nginx，而不是任务准备就绪（socket连接，数据写入或者新数据准备读取在本地缓冲区中）。 此外，现代操作系统可以与HDD（读/写）异步工作，甚至可以直接从HDD发送文件到TCP套接字。
当然，这个Nginx进程中的所有数学运算都将阻止这个进程，并停止处理新的和现有的请求。 但是，当主要工作流程与网络工作（反向代理，转发请求到FastCGI或其他后端服务器），再加上发送静态文件（异步） – Nginx可以在一个操作系统进程中同时处理数千个请求！ 另外，因为一个进程的OS（和一个线程）–CPU将在一个上下文中执行它。
我之前说过–Nginx可以启动少量的操作系统进程，每一个进程都会被操作系统分配给独立的CPU内核。 几乎没有理由分叉更多的Nginx操作系统进程（只有一个原因：如果你需要做一些阻止操作，但简单的反向代理与后端平衡 – 不是这种情况下）
所以，优点：更少的CPU上下文切换，更少的内存（与工作人员MPM相比），快速连接处理。 更多优点：Nginx创建为HTTP负载均衡器，并有很多选项（甚至更多的商业Nginx Plus）。 缺点：如果你在操作系统进程中需要一些硬性的数学运算，这个过程将会被阻塞（但是你所有的数学运算都是在Tomcat中进行的，所以Nginx只是平衡器）。
PS：打字错误会晚点来，过时。 另外，我的英语不好，所以修正总是欢迎:)
PPS：回答有关TC线程数的问题，在评论中被问（作为评语过长）：
最好的方法来了解它 – 使用压力加载工具来测试它。 因为这个数字取决于应用程序配置 响应时间不足以帮助解答。 例如，100％数学（100％cpu界限）200ms与数学50ms +睡眠等待数据库答案150ms之间的差距很大。
如果应用程序是100％的CPU绑定 – 可能每个核心一个线程，但在实际情况下，所有的应用程序也花了一些时间在I / O（接收请求，发送答案到客户端）。
如果应用程序使用I / O并需要等待来自其他服务（例如数据库）的答案，则此应用程序将花费一些时间进入睡眠状态，并且CPU可以处理其他任务。
因此，创建接近实际负载的请求数量并运行压力测试的最佳解决方案会增加并发请求的数量（以及TC工作人员的数量）。 找到可接受的响应时间并修复这个线程数量。 当然，之前需要检查它不是数据库故障。
当然，在这里我只谈论动态内容，从磁盘请求静态文件必须在tomcat之前（例如Nginx）处理。