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

我可以想到以下选项：

>临时文件 – 简单,可能是速度和存储要求方面最糟糕的选择
> UNIX域套接字 – 不可移植,不可扩展
>互联网套接字 – 便携,可扩展
>管道 – 便携式,不可扩展(？)

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

编辑：我将尝试提供更多细节以回应ysth’s questions(警告,文本墙随后)：

>读者/作者是一对一的关系,还是更复杂的东西？
>如果读者不再在那里或忙碌,你想对作家发生什么？
>反之亦然？
>您对所需用途有哪些其他信息？

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

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

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

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

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

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

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

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

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

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