我主要关注的是可维护性和性能(按此顺序).我不认为我需要扩展到多个服务器,或者从我们的主平台(RHEL)移植,但我认为这是需要考虑的事情.
我可以想到以下选项：
>临时文件 – 简单,可能是速度和存储要求方面最糟糕的选择
> UNIX域套接字 – 不可移植,不可扩展
>互联网套接字 – 便携,可扩展
>管道 – 便携式,不可扩展(？)
考虑到可扩展性和可移植性不是我主要关注的问题,我需要了解更多信息.什么是最好的选择,为什么？如果您需要其他信息,请发表评论.
编辑：我将尝试提供更多细节以回应ysth’s questions(警告,文本墙随后)：
>读者/作者是一对一的关系,还是更复杂的东西？
>如果读者不再在那里或忙碌,你想对作家发生什么？
>反之亦然？
>您对所需用途有哪些其他信息？
在这一点上,我正在考虑采用三层方法,但我不确定每层中有多少个进程.我认为我需要在左侧有更多的流程,在右侧有更少的流程,但也许我应该全面拥有相同的数字：
.---------. .----------. .-------. | Request | -----> | Business | -----> | Data | | Manager | <----- | Logic | <----- | Layer | `---------' `----------' `-------'
这些名称仍然是通用的,可能不会以这些形式进入实现.
请求管理器负责监听来自不同接口的请求,例如Web请求和CLI(响应时间很重要)和电子邮件(响应时间不太重要).它执行日志记录并管理对请求的响应(以适合请求类型的格式呈现).
它将有关请求的数据发送到业务逻辑,业务逻辑根据业务规则执行日志记录,授权等.
业务逻辑(如果需要)然后从数据层请求数据,数据层可以与(最常见的)内部MySQL数据库或我们团队控制之外的某些其他数据源(例如,我们组织的主LDAP服务器,或我们的DB2员工信息数据库等).这主要是一个包装器,它以统一的方式格式化数据,以便在业务逻辑中更容易处理.
然后,该信息将流回请求管理器以进行演示.
如果,当数据向右流动时,阅读器正忙,对于交互式请求,我只想等待一段合适的时间,如果我在这段时间内无法访问,则返回超时错误(例如“稍后再试”).对于非交互式请求(例如电子邮件),轮询系统可以简单地退出并在下次调用时再次尝试(可能每1-3分钟一次).
当数据向另一个方向流动时,不应有任何等待情况.如果其中一个进程在尝试返回左侧时已经死亡,我所能做的就是登录并退出.
无论如何,这是非常冗长的,因为我还处于早期设计阶段,我可能仍然有一些混乱的想法.我提到的一些内容可能与使用哪种IPC系统的问题相关.我对设计的其他建议持开放态度,但我试图将问题限制在范围内(例如,也许我应该考虑折叠到两层,这对IPC来说要简单得多).你的想法是什么？
解决方法
不过,我唯一真正的建议是不要自己写这个.在服务器端,您应该使用POE(或Coro等),而不是自己选择套接字.此外,如果您的接口将是RPC-ish,请使用CPAN中的JSON-RPC-Common/.
最后,有IPC :: PubSub,它可能适合你.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。