多线程或多处理

Question

我正在为Linux设计一个专用的syslog-processing守护进程，它需要健壮且可扩展，我正在讨论多线程与多进程。

多线程的明显反对意见是复杂性和令人讨厌的错误。 由于IPC通信和上下文切换，多进程可能会影响性能。

“Unix编程的艺术”讨论了这个here。

您会推荐基于流程的系统（如Apache）还是多线程方法？

Answer 1

它们都可能以自己的方式复杂而复杂。

你可以做任何一件事。在宏伟的计划中，你选择哪个并不重要。重要的是你做得多好。因此：

做你最有经验的事。 或者，如果您领导一个团队，请做团队最有经验的人。

---线程！---

我做了很多线程编程，我喜欢它的部分内容，部分内容我不喜欢。我学到了很多东西，现在通常可以编写一个多线程的应用程序而不会有太多的痛苦，但它必须以非常具体的方式编写。即：

1）必须使用非常明确定义的数据边界编写100％线程安全的数据边界。否则，无论发生什么情况都会发生，而且可能不会出现调试器问题。加上调试线程代码就像窥视Schrodinger的框...通过查看，其他线程可能有也可能没有有时间处理更多。

2）必须用强调机器的测试代码编写。许多多线程系统只在机器受到很大压力时显示它们的错误。

3）必须有一些非常聪明的人拥有数据交换代码。如果有任何方法可以创建一个快捷方式，一些开发人员可能会成功，你将有一个错误的错误。

4）必须有一个全能的情况，将以最小的麻烦重置应用程序。这是因为某些线程问题导致生产代码中断。简而言之：节目必须继续。

---交叉处理！---

我对基于流程的线程的经验较少，但最近在Windows中做了一些跨进程的东西（IPC是Web服务调用...... WOO！），它相对干净简单，但我这里也遵循一些规则。总的来说，进程间通信将更加无错误，因为程序很好地接收来自外部世界的输入......并且这些传输机制通常是异步的。总之...

1）明确流程边界和沟通机制。只要边框清晰，并且在这些边界处有大量验证和错误检查代码，就可以通过TCP或Web服务或管道或任何其他方式发送消息/事件。

2）为瓶颈做好准备。代码宽恕非常重要。我的意思是，有时候你无法写入那个管道。您必须能够在没有应用程序锁定/抛出异常的情况下重新排队并重试这些消息。

3）一般来说会有更多代码，因为跨越流程边界传输数据意味着您必须以某种方式对其进行序列化。这可能是问题的根源，尤其是当您开始维护和更改该代码时。

希望这有帮助。

Answer 2

取决于您要使用的编程语言（以及哪些库）。 我个人会选择多线程，因为我知道与线程相关的问题（以及如何解决它们）。

如果您想在多台计算机上运行守护程序并在其中分配负载，则多处理可能会对您有所帮助，但我不认为这是一个主要问题。

Answer 3

你遗漏了太多细节。实际上，就你已经说过的内容而言，选择是无关紧要的，多线程没有比多处理更多的错误;你错过了为什么这些技术有这样的声誉。如果您不共享数据，那么就没有太多问题（当然，可能还有其他一些问题，但我们需要详细信息来决定这些问题）。此外，无论如何，在UNIX等操作系统上，平台都非常轻量级。

但是，还有其他问题需要考虑吗？你将运行什么样的系统？您绝对不希望在单处理器系统上生成多个进程，因为您不会获得太多好处，具体取决于您可以指定的其他一些细节。如果您描述了您试图解决的问题的性质，我们可以进一步提供帮助。

Answer 4

如果您想要稳健性，请使用多处理。

进程将共享它们之间的日志记录负载。迟早，日志记录请求将遇到错误并使记录器崩溃。使用多处理，您只会丢失一个进程，因此只会丢失一个日志记录请求（由于该错误，您无法进行处理）。

多线程很容易崩溃，因为一个致命错误会导致您的单个进程。

多处理在某些方面在技术上更具挑战性，因为您必须平衡工作负载而不是进程，这可能需要使用共享内存。

Answer 5

您是否需要在频繁更新且IPC过于昂贵的实例之间共享更新数据？在那种情况下，多线程可能更好。否则，你必须权衡单独进程的稳健性或线程创建/通信的简易性对你来说是否更重要。

Answer 6

一个问题是，是否有必要这样做。我不知道您的要求的详细信息，但使用select(2)的单线程应用程序可能符合您的需求，并且没有进程或线程的缺点。这要求您能够将所有I / O集中到一个中心位置，最有可能通过回调调度到其他模块，但这并不是那么难，除非你有很多想要自己创建的库我/ O并且不能以这种方式重组。

Answer 7

感谢大家的反馈。

我决定采用类似于Apache Web服务器的多进程架构。 这些过程将在多处理器/核心系统上很好地扩展。 通讯将使用管道或插座进行。

流程可以在流程池中使用，因此没有流程产生的成本。

与我获得的稳健性相比，性能损失可以忽略不计。

Answer 8

好吧，我们最终将它实现为一个多处理系统，带有用于IPC的管道和一个根据需要生成进程的簿记员。类似于Apache httpd。它运作得很好。