我的主要关注点是可维护性和性能(按顺序)。 我不认为我需要扩展到超过一个服务器,或者从我们的主平台(RHEL)进行端口转移,但我认为这是需要考虑的事情。
我可以想到以下选项:
- 临时文件 - 简单,可能是速度和存储需求方面最差的选择 - UNIX域套接字 - 不可移植,不可扩展 - Internet套接字 - 可移植,可扩展 - 管道 - 可移植,不可扩展(?)
考虑到可扩展性和可移植性不是我的主要关注点,我需要学习更多。哪个是最佳选择,为什么?如果您需要其他信息,请评论。
编辑: 我会尝试在ysth的问题的回复中提供更多详细信息(警告,下面是一堵文字墙):
- 读者/作者是否处于一对一关系,还是更加复杂?
- 如果读者不在或忙碌,您希望发生什么情况?
- 反之亦然?
- 您有关所需用途的其他信息是什么?
此时,我正在考虑三层方法,但我不确定每个层次中将有多少个进程。我认为我需要在左侧拥有更多的进程,而在右侧则需要较少的进程,但也许我应该在各方面都有相同数量:
.---------. .----------. .-------. | 请求管理器 | -----> | 业务逻辑 | -----> | 数据层 | `---------' `----------' `-------'这些名称仍然是通用的,可能不会以这些形式实现。 请求管理器负责监听来自不同接口的请求,例如 Web 请求和 CLI(响应时间很重要)以及电子邮件(响应时间不那么重要)。它执行日志记录并管理对请求的响应(以适合请求类型的格式呈现)。
它将有关请求的数据发送到业务逻辑,后者根据业务规则执行日志记录、授权等操作。
如果需要,业务逻辑随后从数据层请求数据,该数据层可以与内部 MySQL 数据库或我们团队无法控制的某些其他数据源(例如我们组织的主要 LDAP 服务器或我们的 DB2 员工信息数据库等)进行通信。这主要是一个包装器,以统一的方式格式化数据,以便在业务逻辑中更容易处理。
然后信息流回请求管理器进行呈现。
如果数据向右流动时,读者正在忙碌,对于交互请求,我希望只需等待适当的时间,如果在这段时间内无法获得访问权限,则返回超时错误(例如,“稍后再试”)。对于非交互式请求(例如电子邮件),轮询系统可以简单地退出,并在下一次调用时再次尝试(这可能是每1-3分钟一次)。
当数据向另一个方向流动时,不应该有任何等待情况。如果其中一个进程在尝试向左移动时死亡,我实际上只能记录并退出。
总之,那很啰嗦,而且由于我仍处于早期设计阶段,我可能仍然有一些混乱的想法。我提到的一些内容可能与使用IPC系统的问题不相关。我对设计的其他建议持开放态度,但我试图将问题限制在范围内(例如,也许我应该考虑折叠到两个层级,这对于IPC来说更简单)。你有什么想法?