我打算为客户端写一个'彗星'服务器来'流''数据。我过去已经增强了一个以利用多核CPU，但现在我从头开始。我打算使用epoll / kqueue或libevent来为服务器供电。
我一直在考虑的问题之一是要使用哪种服务器设计？我有几个选项，因为我计划使用多进程模型来利用所有CPU核心。
设计＃2是最复杂的。设计＃3很简单，但涉及到我需要的额外硬件，无论设计如何，因为我将在多台机器上运行并且无论如何都需要负载均衡器。设计＃1有一个雷鸣般的群体问题，但我认为雷鸣群对8个进程并不是一个大问题，但当客户经常连接和断开连接时它会变得很大（这应该是罕见的，因为这是一个彗星服务器）。
正如我所看到的，＃2很复杂，并且由于主设备和设备之间的描述符传递而需要2个额外的系统调用。每个接受的奴隶进程。这个开销是否比雷鸣般的群体问题更好？如果我有8个进程唤醒并执行接受，我可能会看到8个接受调用，因为我选择了设计＃1？
我的设计选择有哪些优缺点？你会推荐什么？
答案 0 :(得分：0)
如果它不是进程而是线程我会去选项2.无论如何对于进程这对我来说看起来很昂贵，所以我们要在1到3之间进行选择。
如果有可能以某种方式估计预期的负载，我宁愿选择1。你能设定一个睡眠牧群大小的上限，会说预先准备好的过程吗？您需要多快才能接受新连接？
所以，如果你要去汤姆·杜恩森的方式，并把大群快速带到红河下来到堪萨斯州，你可能需要选择第三种方式。所以无论如何资源都可用......
答案 1 :(得分：0)
如果您的目标是制作一个非常大规模的高吞吐量HTTP守护程序， ＃1，＃2和＃3都不合适。如果你想获得可扩展性，你最好使用具有多线程的1到m或m到n模型，就像nginx / lighttp那样。
事实上， 如果你希望程序在一秒钟内处理不到一百个连接，那么 ＃1，＃2和＃3可能没有任何明显的区别。
但是，如果您可以通过将流程切换到线程来扩展您的程序，我会选择＃2，因为它可以轻松集成到1到m或m到n的处理模型中