为了在 linux 上开发高度网络密集型的服务器应用程序，首选哪种架构？这个想法是这个应用程序通常会在具有多核（虚拟或物理）的机器上运行。考虑到性能是关键标准，选择多线程应用程序还是多进程设计的应用程序更好？我确实知道从多个进程共享资源和同步访问这些资源需要大量的编程开销，但如前所述，整体性能是关键要求，因此我们可以忽略这些事情。编程语言将是 C/C++。
我听说即使是多线程应用程序（单进程）也可以利用多个内核并在不同的内核上独立运行每个线程（只要没有同步问题）。而这个调度是由内核完成的。如果是这样，多线程应用程序和多进程应用程序在性能上没有太大区别吗？Nginx 采用多进程架构，速度确实很快，但多线程应用程序能获得相同的性能吗？
谢谢。
Linux 上的进程和线程彼此非常相似——主要区别在于整个虚拟内存是共享的，而信号处理等某些方面也不同。
这使得线程之间的上下文切换成本更低（不需要昂贵的 MMU 重新加载等），但不一定会导致速度差异很大（尤其是在线程创建之外）。
对于设计一个高度网络密集型的应用程序，基本上唯一的解决方案是使用事件架构（否则你会用大量的进程/线程使系统陷入困境，并且花费更多的时间来管理它们而不是实际运行工作代码），你对套接字上的 I/O 做出反应，并根据哪些套接字表现出活动来执行适当的操作。
关于在这种情况下面临的问题的著名文章是“C10k 问题”，可从http://www.kegel.com/c10k.html获得——它描述了不同的 I/O 方法，因此尽管有点过时，但它是一个很好的介绍。
不过，在深入研究类似反应器的设计之前要小心——它们可能会变得笨拙和复杂，所以看看你是否不能使用提供更好抽象的库/语言（Erlang 是我个人最喜欢的，带有协程的语言像 Go 一样也很有用）。
如果您的线程彼此独立地完成这项工作，那么在 linux 下，根本没有理由不使用多个进程。多个进程会增加您的内存使用量，因为每个进程都有自己的私有内存空间，但另一方面，在独立线程之间共享内存空间是更糟糕的决定。线程与进程之间的上下文切换通常对进程而不是线程做得更好，尽管它有点依赖于架构和代码。进程是安全的，不会被锁和互斥体序列化。在 Linux 中，进程更易于管理和交互。这是一个您可能会感兴趣的好文档（http://elinux.org/images/1/1c/Ben-Yossef-GoodBadUgly.pdf）。