什么是多线程并发服务器

有多个 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 程序那样。

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

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

如果是客户端开发的同学，字典中是没有“高并发”这个名词。这验证一句老话，隔行如隔山。客户端开发，特别是手机应用开发，更多地是考虑如何优化应用的性能，降低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框架能支撑到多大的并发量，而是我们想要抗住很大的并发量，怎么优化现有框架。总之这个问题不是这么简单的活到老学到老多看看技术类书籍结合自己的能力在进行改进

不同于顺序服务器， 并发服务器 就要能在一个时间为多个客户端提供服务。 例如，一个 聊天服务器 可能服务一个特定的客户端数小时 不同于顺序服务器， 并发服务器 就要能在一个时间为多个客户端提供服务。 例如，一个 聊天服务器 可能服务一个特定的客户端数小时 ──在停止为这个客户端服务之前服务器不能等待， 除非是在等待一下个客户端到来之前的间隙才能等待。── 在停止为这个客户端服务之前服务器不能等待， 除非是在等待一下个客户端到来之前的间隙才能等待。 >

一般的提法是1000并发，指同时在线数，即1000个客户和服务器保持着连接。可能一整天都能保持这个状态，因此不带上具体多久。

如果每秒1K个请求，每个请求都是写入 *** 作，数据大小是4K，那么这是典型的数据库应用。每秒需要写入的数据量是1K4K=4M。单机下普通配置的mongodb可以应付这样的压力。可否找一下那些地方成为瓶颈了。看看磁盘忙不忙，mongo的CPU高不高。

1，进程：子进程是父进程的复制品。子进程获得父进程数据空间、堆和栈的复制品。
2，线程：相对与进程而言，线程是一个更加接近与执行体的概念，它可以与同进程的其他线程共享数据，但拥有自己的栈空间，拥有独立的执行序列。
两者都可以提高程序的并发度，提高程序运行效率和响应时间。
线程和进程在使用上各有优缺点：线程执行开销小，但不利于资源管理和保护；而进程正相反。同时，线程适合于在SMP机器上运行，而进程则可以跨机器迁移。
答案二:
根本区别就一点：用多进程每个进程有自己的地址空间(address space)，线程则共享地址空间。所有其它区别都是由此而来的：
1。速度：线程产生的速度快，线程间的通讯快、切换快等，因为他们在同一个地址空间内。
2。资源利用率：线程的资源利用率比较好也是因为他们在同一个地址空间内。
3。同步问题：线程使用公共变量/内存时需要使用同步机制还是因为他们在同一个地址空间内。
网上的答案的 版本怎么想怎么都太学术了。我当时看到过一个比喻特别的好， 我就模仿者把它说下来哈，有错误希望支持哈：
多进程的服务器就好比是
立体的交通系统（立交桥）虽然说建造的时候花费比较大，消耗的资源比较多，但是真要是跑起来不会交通堵塞。但是汽车在上面跑，相互通信就是个很费事儿问题（进程间通信比较麻烦）；多线程就好比是平面的交通系统，造价低，但是很容易交通堵塞，
但是也有好处同步的时候方便。
在网络服务器方面：
单进程 < 多进程(单线程)< 多进程（多线程）
在游戏方面的应用：
I、多线程服务器，玩家数据缓存和向DB的存储我们可以开一个线程单独去做，这样不会有什么大的问题。日志和网络上面说过可以很容易切割出去，主要就是对游戏逻辑的切割。
A：按场景分线程，一个线程管理若干个场景。这样配置灵活，一个线程可以管理若干个小场影，除非有个场景人多到一个CPU跑不下来，一般的游戏都会满足需求。缺点则是不在同一线程的Object在做逻辑交互时，必须用异步，如果用到了脚本，那么这里的复杂度和性能要值得注意。如果项目中出现单个服务器解决不鸟的问题(例如战场服务器)，似乎就成了多线程多进程的庞大架构。
B：将某些功能切割到其它线程，例如Object的管理和查找，NPCAI的寻路，这种方式貌似在做逻辑需要分离到别的线程模块功能时有点麻烦，如果直接上锁等待肯定不是最好的方式,所以这些逻辑必须变成异步。
2、多进程服务器,其实这里的多进程和场景多线程改成了多进程。这里玩家数据缓存和向DB的存储我觉得用一个单独的DB服务器。多进程服务器可以在GameServer和GameClient之间加一个Gate，因为在跨服场景不需频繁断线连接。多进程服务器所有的通讯都依靠网络，有些逻辑必须有网络延迟的消耗。优点是配置灵活，在物理机器性能不够时可以通过扩充物理机器来解决
服务器还有有一个很蛋疼的问题就是过载： 下面介绍一下产生的原因和解决办法：
服务器过载：
原因是高优先级处理阶段对CPU的不公平抢占。所以，如果限制高优先级处理阶段对CPU的占用率，或者限制处理高优先级的CPU个数，都可以减轻或者消除收包活锁现象。具体的可以采用以下的方法：
方法一、采用轮询机制
为了减少中断对系统性能的影响，在负载正常的情况下采用“下半处理”的方法就非常有效，而在高负荷情况下，采用这个方法仍然会造成活锁现象，这时可以采用轮询机制。虽然这个方法在负载正常的情况下会造成资源的浪费和响应速度降低，但在网络数据频繁到达服务器时就要比中断驱动技术有效的多。
方法二、减低中断的频率
这里主要有两种方法：批中断和暂时关闭中断。批中断可以在超载时有效的抑制活锁现象，但对服务器的性能没有什么根本性的改进;当系统出现接收活锁迹象时，可以采用暂时关闭中断的方法来缓和系统的负担，当系统缓存再次可用时可以再打开中断，但这种方法在接收缓存不够大的情况下会造成数据包丢失。
方法三、减少上下文切换
这种方法不管服务器在什么情况下对性能改善都很有效，这时可以采用引入核心级(kerne1—leve1)或硬件级数据流的方法来达到这个目的。核心级数据流是将数据从源通过系统总线进行转发而不需要使数据经过应用程序进程，这个过程中因为数据在内存中，因此需要CPU *** 作数据。
硬件级数据流则是将数据从源通过私有数据总线或是虽等DMA通过系统总线进行转发而不需要使数据经过应用程序进程，这个过程不需要CPU *** 作数据。这样在数据传输过程中不需要用户线程的介入，减少了数据被拷贝的次数，减少了上下文切换的开销。

在java5以前实现多线程有两种方法（继承Thread类和实现Runnable接口）
它们分别为：
使用new Thread()和new Thread(Runnable)形式
第一种直接调用thread的run方法，所以，往往使用Thread子类，即new SubThread()。
第二种调用
Runnable的run方法。
第一种：
new Thread(){}start();这表示调用Thread子类对象的run方法，new Thread(){}表示一个Thread的匿名子类的实例对象，子类加上run方法后的代码如下：
new Thread(){
public void run(){
}
}start();
第二种：
new Thread(
new Runnable(){}
)start();
这表示调用Thread对象接受的Runnable对象的run方法，new Runnable(){}表示一个Runnable的匿名子类的实例对象,
runnable的子类加上run方法后的代码如下：
new Thread(new Runnable(){
public void run(){
}
}
)start();

---