我正在设计Perl中的多层应用程序，我想知道各种IPC机制的优缺点。我正在考虑处理中等大小的数据，通常是几十千字节，但高达几兆字节，负载非常轻，每分钟最多几百个请求。
我主要关注的是可维护性和性能（按此顺序）。我不认为我需要扩展到多个服务器，或者从我们的主平台（RHEL）移植，但我认为这是需要考虑的事情。
我可以考虑以下选项：
考虑到可扩展性和可移植性不是我主要关注的问题，我需要了解更多信息。什么是最好的选择，为什么？如果您需要其他信息，请发表评论。
编辑：我会尝试提供更多详细信息以回应ysth's questions （警告，文字墙随后） ：
此时，我正在考虑采用三层方法，但我不确定每层中有多少个进程。我认为我需要在左侧采用更多流程，在右侧采用更少流程，但也许我应该全面拥有相同数量的流程：
.---------. .----------. .-------. | Request | -----> | Business | -----> | Data | | Manager | <----- | Logic | <----- | Layer | `---------' `----------' `-------'
这些名称仍然是通用的，可能不会以这些形式进入实现。
请求管理器负责监听来自不同接口的请求，例如Web请求和CLI（响应时间很重要）和电子邮件（响应时间不太重要）。它执行日志记录并管理对请求的响应（以适合请求类型的格式呈现）。
它将有关请求的数据发送到业务逻辑，后者根据业务规则执行日志记录，授权等。
业务逻辑（如果需要）然后从数据层请求数据，该数据可以与（最常见的）内部MySQL数据库或我们团队控制之外的其他数据源进行通信（例如，我们组织的主要LDAP服务器，或我们的DB2员工信息数据库等）。这主要是一个包装器，它以统一的方式格式化数据，以便在业务逻辑中更容易处理。
然后，信息将流回请求管理器进行演示。
如果，当数据流向右侧时，阅读器正忙，对于交互式请求，我只想等待一段合适的时间，如果我无法访问该数量，则返回超时错误时间（例如“稍后再试”）。对于非交互式请求（例如电子邮件），轮询系统可以简单地退出并在下次调用时再次尝试（可能每1-3分钟一次）。
当数据向另一个方向流动时，不应有任何等待情况。如果其中一个进程在尝试返回左侧时已经死亡，我所能做的就是登录并退出。
无论如何，这是非常冗长的，因为我还在早期设计中，我可能仍然有一些混淆的想法。我提到的一些内容可能与使用哪个IPC系统的问题相关。我对设计的其他建议持开放态度，但我试图将问题限制在范围内（例如，也许我应该考虑折叠到两层，这对IPC来说要简单得多）。你有什么想法？
答案 0 :(得分：6)
如果您目前不确定您的确切要求，请尝试考虑一个可以编码的简单接口，任何 IPC实施（无论是临时文件，TCP / IP还是无论如何）需要支持。然后，您可以选择特定的IPC风格（我会从最简单和/或最简单的调试开始 - 可能是临时文件）并使用它来实现接口。如果结果太慢，请使用例如TCP / IP。实际上，实现接口并不需要太多工作，因为您实际上只是将调用转发到某个现有库。
重点是您要执行高级任务（“将数据从程序A传输到程序B”），这或多或少独立于其执行方式的细节。通过建立界面并对其进行编码，您可以在需要更改实施时将主程序与更改隔离。
请注意，您不需要使用任何重量级的Perl语言机制来充分利用具有接口的想法。你可以简单地例如3个不同的包（用于临时文件，TCP / IP，Unix域套接字），每个包都导出同一组方法。选择要在主程序中使用的实现等于选择use的哪个模块。
答案 1 :(得分：4)
除此之外，临时文件还有其他问题。我认为网袜确实是最好的选择。它们有很好的文档记录，正如您所说，可扩展且可移植。即使这不是核心要求，您也几乎可以免费获得。套接字很容易处理，同样有大量的文档。您可以在库中构建数据共享机制和协议，而不必再次查看它！
答案 2 :(得分：4)
临时文件（以及相关内容，如共享内存区域）可能是一个不好的选择。如果您想在一台计算机上运行服务器而在另一台计算机上运行客户端，则需要重写应用程序。如果您选择任何其他选项，至少语义基本相同，如果您需要在以后切换它们。
但我唯一真正的建议是不要自己写这个。在服务器端，您应该使用POE（或Coro等），而不是自己在套接字上执行select。此外，如果您的界面将是RPC-ish，请使用CPAN中的JSON-RPC-Common/之类的内容。
最后，有IPC :: PubSub，它可能适合你。
答案 3 :(得分：3)
UNIX域套接字可以在unices中移植。它不比管道便携。它也比IP套接字更有效。
无论如何，你错过了一些选项，例如共享内存。有些人会将数据库添加到该列表中，但我会说这是一个相当重要的解决方案。
消息队列也是可能的，尽管您必须更改内核选项才能处理如此大的消息。否则，他们有很多东西的理想界面，恕我直言他们被大大少用了。
我普遍认为，使用现有解决方案比构建自己的解决方案更好。我不知道您问题的具体细节，但我建议您查看CPAN的IPC部分
答案 4 :(得分：2)
有很多不同的选择，因为大多数选项在某些特定情况下更好，但是您没有真正提供任何可以识别您案例的信息。
读者/作者是一对一的关系，还是更复杂的东西？ 如果读者不再在那里或忙碌，你想对作家发生什么？反之亦然？ 您对预期用途有何其他信息？
答案 5 :(得分：2)
对于“交互式”请求（在等待响应时保持连接打开（异步或非异步）：HTTP + JSON。JSON::XS非常快。每个人都可以说HTTP并且很容易实现负载平衡，调试，......
对于排队的请求（“请执行此操作，谢谢！”）：Beanstalkd和Beanstalk::Client。使用JSON序列化beanstalk队列中的请求。
Thrift也可能值得根据您的申请进行调查。