perl - Perl 中中型数据的最佳 IPC 机制是什么？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




我正在用 Perl 设计一个多层应用程序，我想知道我可用的各种 IPC 机制的优缺点。我正在考虑处理中等大小的数据，通常为几十 KB，但最多可达几兆字节，并且负载很轻，最多每分钟几百个请求。

我主要关心的是可维护性和性能(按此顺序)。我认为我不需要扩展到不止一台服务器，也不需要从我们的主平台 (RHEL) 上移植，但我想这是需要考虑的。

我可以想到以下选项:

临时文件 - 简单，可能是速度和存储要求方面最差的选择

UNIX 域套接字 - 不可移植，不可扩展

Internet 套接字 - 可移植、可扩展

管道 - 便携，不可扩展 (?)

考虑到可扩展性和可移植性不是我的主要关注点，我需要了解更多。什么是最好的选择，为什么？如果您需要其他信息，请发表评论。

编辑:我将尝试在回复 ysth's questions 时提供更多详细信息 (警告，后面是文字墙) :

读者/作者是一对一的关系，还是更复杂的关系？

如果读者不在或很忙，你希望作者怎么办？

反之亦然？

关于您想要的用途，您还有哪些其他信息？

在这一点上，我正在考虑采用三层方法，但我不确定每一层有多少进程。我想我需要在左侧有更多的流程，而在右侧需要更少的流程，但也许我应该有相同的数字:

.---------。 .---------。 .-------.
|请求 | -----> |业务 | -----> |数据 |
|经理 | <----- |逻辑 | <----- |层 |
`---------' `----------' `---'

这些名称仍然是通用的，可能不会以这些形式出现在实现中。

请求管理器 负责监听来自不同接口(interface)的请求，例如 Web 请求和 CLI(响应时间很重要)和电子邮件(响应时间不太重要)。它执行日志记录并管理对请求的响应(以适合于请求类型的格式呈现)。

它将有关请求的数据发送到 业务逻辑它根据业务规则执行日志记录、授权等。

业务逻辑(如果需要)然后从 请求数据。数据层 ，它可以(通常)与内部 MySQL 数据库或我们团队控制之外的其他一些数据源(例如，我们组织的主要 LDAP 服务器或我们的 DB2 员工信息数据库等)进行通信。这主要只是一个包装器，它以统一的方式格式化数据，以便在业务逻辑中更容易处理。

然后信息流回请求管理器以供呈现。

如果，当数据向右流动时，阅读器很忙，对于交互式请求，我只想等待一段合适的时间，如果在这段时间内没有访问，则返回超时错误(例如“稍后再试”)。对于非交互式请求(例如电子邮件)，轮询系统可以简单地退出并在下一次调用时重试(可能每 1-3 分钟一次)。

当数据向另一个方向流动时，不应出现任何等待情况。如果其中一个进程在尝试返回左侧时死亡，我真正能做的就是登录并退出。

无论如何，这非常冗长，而且由于我仍处于早期设计阶段，因此我可能仍然有一些令人困惑的想法。我提到的一些内容可能与 的问题无关。使用哪个 IPC 系统 .我对设计的其他建议持开放态度，但我试图将问题限制在范围内(例如，也许我应该考虑将其分解为两层，这对 IPC 来说要简单得多)。你怎么看？

Answer 1

如果您目前不确定您的确切要求，请尝试考虑一个您可以编码的简单接口(interface)，任何 IPC 实现(无论是临时文件、TCP/IP 还是其他)都需要支持。然后，您可以选择特定的 IPC 风格(我将从最容易和/或最容易调试的任何东西开始——可能是临时文件)并使用它来实现接口(interface)。如果结果太慢，请使用例如实现接口(interface)TCP/IP。实际上实现接口(interface)并不涉及太多工作，因为您基本上只是将调用转发到一些现有的库。

关键是您要执行一项高级任务(“将数据从程序 A 传输到程序 B”)，这或多或少与执行方式的细节无关。通过建立接口(interface)并对其进行编码，您将主程序与更改隔离 如果您需要更改实现。

请注意，您不需要使用任何重量级的 Perl 语言机制来利用具有接口(interface)的想法。你可以简单地拥有例如3 个不同的包(用于临时文件、TCP/IP、Unix 域套接字)，每个包都导出相同的方法集。选择要在主程序中使用的实现相当于选择要使用哪个模块 use .