浅谈服务器的两种架构

今天和人电话聊了很长的技术问题，人家是成都卧龙工作室的，技术应该是很行的，但是在几个问题上我们的见解不一。

一个单线程能不能形成几万的并发。

这个问题首先就是个错误的提法，换个说法：nginx是不是就可以达到几万的并发。

两个问题犯的是相同的错误。

所有的并发都是针对业务处理的，业务简单点，像对于一些静态网页的处理，或者是无IO的事务，单线程和nginx都是可以达到几万的并发的。

可是这兄弟对单线程能达到几万的并发还是表示不可想象。

前面一个单线程服务器博文就可以达到2W的并发，另外nginx的单进程模式其实就是单线程模式，对静态网页的处理轻松达到几W的并发。

另外一个问题就是服务器的架构。

服务器的的架构无非两种：

单线程事件模型，将事件与事务放在同一个线程中处理，用多进程方式进行负载分担，如nginx。

多线程模型，将事件与事务分隔开来，或者事件也分隔开来。

你能说上面的模型哪个好哪个不好么。

长期接触过搞服务器的人，各种各样的有，我发现经常有这样的一个情况，就是喜欢自我满足，比如，上次一个朋友硬说nginx比apache好，还从事件模型，缓存，架构上把nginx给我狠狠的补了一回课，结果我问了一句，你看过apache的代码么，你对apache了解多少。

如果有朋友坚持认为nginx比apache好的，无非是因为nginx的事件模型可以多路复用，那么负载，伸缩性，模块动态处理这些有没有了解过呢，有争议的朋友可以在评论里说说。

有人常用多线程模型，就觉得要比单线程好，觉得单线程的服务器很低级，对单线程的服务器嗤之以鼻，却又说不出让人信服的道理，我觉得人不能停留在一个既定的认识水平上，而应该去往深处探索，而不是为了工作而工作。

这样想来，卧龙的游戏服务器想必是个多线程模型。

回到正题，之前有篇架构博文里画了一个图，图中土黄色的管子代表高性能的模块，红色的管子代表低性能的模块，这个图可以明确什么是瓶颈，现在咱们再举个数据：

高性能的模块每秒处理能力为1W， 低性能的模块每秒处理能力为1K，如图

如果要让服务器的处理能力达到1W，先说说第二种模型，则业务层的线程至少要有10个，如图

而如果采用第一种模型，则通过分担负载的方式让每个进程的负载均匀降低，用10个进程就可以了，如图

这样看来，两种模型能干相同的事，还能说孰优孰劣么，只能说大家更熟悉哪一种模型了，可能第二种模型里涉及到线程的同步，互斥，然后内存的分配与管理上要复杂一些，从架构上来说，应该尽量避免这样的做法，因这无论从开发周期还是测试周期，都会延长，容易陷入一些复杂的应用场景中。

其实这两种模型我都经历过，前几年喜欢用第二种，设计过一些多线程的技术方案比如内存池，曾经以为这些很不错，自从上一个项目用了第一种方案后，就发现其实单线程的优点还是有很多的，人员的开发分工上也简单很多，架构逻辑、进程的控制、扩容管理、灾难恢复上都要简单很多。

这样想来，其实nginx选择这样的单纯线程其实不是并无道理的吧。