网络编程中设计并发服务器,使用多进程和多线程,有什么区别?

进程是任务管理起里面可以看到的一个程序，就属于一个进程；线程是一个进程，也就是一个程序同时可以执行多少个任务。像多线程下载，有的网站不支持多线程下载，用迅雷或者QQ旋风就会被屏蔽掉；还有多线程破解等等。。。

并发出现在计算机系统的不同层面上，硬件异常处理程序、进程和Linux信号处理程序，以及应用程序中。

当一个应用正在等待来自慢速I/O设备（如磁盘）的数据到达时，内核会运行其他进程，使CPU保持繁忙。每个应用都可以按照类似的方式，通过交替执行I/O请求和其他有用的工作来利用并发。

和计算机交互的人要求计算机有同时执行多个任务的能力。如在打印一个文档时，调整一个窗口的大小。现代视窗系统利用并发来提供这种能力。每次用户请求某种 *** 作（如单击鼠标）时，一个独立的并发逻辑流被创建来执行这个 *** 作。

应用程序能够通过推迟其他 *** 作和并发地执行他们，并用并发来降低某些 *** 作的延迟。如一个动态内存分配器可以通过推迟合并，把它放到一个运行在较低优先级上的并发合并流中，在有空闲的CPU周期时充分利用这些空闲周期，从而降低单个free *** 作的延迟。

一个慢速的客户端可能会导致服务器拒绝为所有其他客户端服务，对于一个真正的服务器来说，可能期望它每秒为成百上千的客户端提供服务，由于一个慢速客户端导致拒绝为其他客户端服务，这是不能接受的。一个更好的办法是创建一个并发服务器，它为每个客户端创建一个单独的逻辑流。这就允许服务器同时为多个客户端服务，避免单个慢速客户端独占服务器。

现代计算机系统都配备了多核处理器，多核处理器包含有多个CPU，被划分为并发流的应用程序通常在多核机器上比单核机器上运行得快，因为这些流会并行执行，而不是交错执行。
使用应用级并发的应用程序成为并发程序（concurrent program）。现代 *** 作系统提供了三种基本的构造并发程序的方法。

做网站的话，服务器要分前端和后端的，还有cache、负载平衡、网络带宽和存储系统等问题要考虑，不是单讲一台服务器就能说清楚的。
只讨论一台服务器的话，3650双路加4G内存支持到5万并发是容易达到的，即使针对业务流比较复杂的情况，也能满足很大程度的需要。
但是考虑到存储子系统，比如4块sas硬盘raid0，可能只能达到5000数量级的并发请求。如果是以另外的光纤盘阵来支持存储则可以显著提高硬盘传输带宽的性能。
最后还要考虑到你的网络带宽，对大多数网站来说，通常这才是最大的瓶颈所在。也就是说即使你的cpu、内存、硬盘都没问题，也会因为租用的网络带宽限制而影响最大的并发数。
还有一点，经过优化的网站程序对结果也有很大影响。事实上很多网站的访问体验很糟糕，其实不是因为硬件的原因，而是程序写的太烂。
很抱歉我本想以单台服务器来讲，但是说着说着又变成讲网站架构了。不如举个例子吧，如果你在这台服务器上运行discuz或动网之类的服务，在没有特别高峰的情况下，5万并发是没有问题的。

极域远程控制可以支持多台电脑的远程控制，具体支持的数量取决于所使用的版本和授权情况。一般来说，极域远程控制的标准版和专业版可以支持最多100台计算机的远程控制，而企业版可以支持数千台计算机的远程管理。此外，还可以通过极域远程控制的集中管理器来对多个极域远程控制服务器进行集中管理和监控，从而更加方便地进行大规模的远程控制和管理。需要注意的是，使用极域远程控制进行远程控制时，应当遵循相关的安全规范和 *** 作流程，以确保远程控制的安全和稳定。

有多个 CPU 可用。单核机器上多线程的优势不明显。
线程间有共享数据。如果没有共享数据，用模型 3b 就行。虽然我们应该把线程间的共享数据降到最低，但不代表没有；
共享的数据是可以修改的，而不是静态的常量表。如果数据不能修改，那么可以在进程间用 shared memory，模式 3 就能胜任；
提供非均质的服务。即，事件的响应有优先级差异，我们可以用专门的线程来处理优先级高的事件。防止优先级反转；
latency 和 throughput 同样重要，不是逻辑简单的 IO bound 或 CPU bound 程序；
利用异步 *** 作。比如 logging。无论往磁盘写 log file，还是往 log server 发送消息都不应该阻塞 critical path；
能 scale up。一个好的多线程程序应该能享受增加 CPU 数目带来的好处，目前主流是 8 核，很快就会用到 16 核的机器了。
具有可预测的性能。随着负载增加，性能缓慢下降，超过某个临界点之后急速下降。线程数目一般不随负载变化。
多线程能有效地划分责任与功能，让每个线程的逻辑比较简单，任务单一，便于编码。而不是把所有逻辑都塞到一个 event loop 里，就像 Win32 SDK 程序那样。

您好楼主希望对您有帮助高并发对后台开发同学来说，既熟悉又陌生。熟悉是因为面试和工作经常会提及它。陌生的原由是服务器因高并发导致出现各位问题的情况少之又少。同时，想收获这方面的经验也是摸着石头过河，需要大量学习理论知识，再去探索。

如果是客户端开发的同学，字典中是没有“高并发”这个名词。这验证一句老话，隔行如隔山。客户端开发，特别是手机应用开发，更多地是考虑如何优化应用的性能，降低App的卡顿率

在这个“云”的时代，提高分布式系统并发能力的方式，方法论上主要有两种：垂直扩展（ScaleUp）与水平扩展（ScaleOut）。

1)垂直扩展

提升单机处理能力。垂直扩展的方式又有两种：

增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

提升单机架构性能，例如：使用Cache来减少I/O次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

2)水平扩展

只要增加服务器数量，就能线性扩充系统性能。虚拟化技术的出现，让水平扩展变得轻松且简单。现在的云主机几乎是虚拟主机，而不是物理主机。这样的话，线性扩充也就是分分钟的事，前提是要有足够的物理主机支撑。

Web框架层

Web框架层就是我们开发出来的DjangoWeb应用程序。它负责处理>

WSGI层

WSGI不是用于与程序交互的API，也不是真实的代码，WSGI只是一种接口。它只适用于Python语言，其全称为WebServerGatewayInterface。其定义了web服务器和web应用之间的接口规范。

Web服务器层

Web服务层作用是主要是接收>

特别是Nginx,它的出现是为了解决C10K问题。Nginx依靠异步事件驱动架构来帮助其处理大量的并发会话，由于其对资源的轻量利用和伸缩自如的特性，它成为了广受欢迎的web服务器。

Django框架注重的数据交互。所以考虑的问题是Django适不适合于高并发的场景。

它是一个经过大型网站规模验证的框架。Instagram支撑上亿日活，所以Django能适用于高并发场景。所以不是想着Django框架能支撑到多大的并发量，而是我们想要抗住很大的并发量，怎么优化现有框架。总之这个问题不是这么简单的活到老学到老多看看技术类书籍结合自己的能力在进行改进

---