在Perl中,中型数据的最佳IPC机制是什么？

我正在设计Perl中的多层应用程序,我想知道各种IPC机制的优缺点.我正在考虑处理中等大小的数据,通常是几十千字节,但高达几兆字节,负载非常轻,每分钟最多几百个请求.

我主要关注的是可维护性和性能(按此顺序).我认为我不需要扩展到多个服务器,或者从我们的主平台(RHEL)移植,但我想这是需要考虑的事情.

我可以想到以下选项:

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

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

互联网套接字 - 便携,可扩展

管道 - 便携式,不可扩展(？)

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

编辑:我会尝试提供更多细节以回应ysth的问题 (警告,文本墙随后):

读者/作者是一对一的关系,还是更复杂的东西？

如果读者不再在那里或忙碌,你想对作家发生什么？

反之亦然？

您对预期用途有何其他信息？

在这一点上,我正在考虑采用三层方法,但我不确定每层中有多少个进程.我认为我需要在左侧有更多的进程而在右侧有更少的进程,但也许我应该在全面拥有相同的数字:

 .---------.          .----------.        .-------.
 | Request |  ----->  | Business | -----> | Data  |
 | Manager |  <-----  |  Logic   | <----- | Layer |
 `---------'          `----------'        `-------'

这些名称仍然是通用的,可能不会以这些形式进入实现.

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

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

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

然后,该信息将流回请求管理器以进行演示.

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

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

无论如何,这是非常冗长的,因为我还处于早期设计阶段,我可能仍然有一些混乱的想法.我提到的一些内容可能与使用哪种IPC系统的问题相关.我对设计的其他建议持开放态度,但我试图将问题限制在范围内(例如,也许我应该考虑折叠到两层,这对IPC来说要简单得多).你的想法是什么？

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

关键是您要执行高级任务("将数据从程序A传输到程序B"),这或多或少独立于其执行方式的细节.通过建立接口并对其进行编码,可以将主程序与需要更改实现的事件中的更改隔离开来.

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