Eva*_*ice 5 c# multithreading ipc data-access-layer multiprocessing
我有多层应用程序架构,有4个部分:
客户/服务器层:
客户端/服务器层处理与使用自定义第2层协议实现的另一台计算机的异步网络通信.由于通信中内置的设计约束,它需要保持独立并能够异步地轮询/推送数据到数据层.
中间层:
目前使用数据库实现中间层.一个表包含可以调用的所有可能标签(大约120,000).第二个表包含第一个表的中间缓存,其中仅包含正在使用的值,这需要不断更新,并在请求新的项集合时刷新.第三个表是发送集合更新的位置,仅在请求挂起时包含数据.
监控层:
监视器层是一个多线程单片应用程序.它根据连接的监视器数量生成n个客户端实例.它管理所有客户端实例之间的全局状态,因为它们中的一个或多个可以共享相似/相同的状态.它创建所需值的唯一列表,管理在客户端需要不同标签集时发送更新请求,并管理重复更新.
显然,这并不理想.如果一个实例出现故障,可以将其余部分关闭.我想要做的是删除中间层,将其替换为监视器层,并使所有内容都作为监视器进程的子进程生成,以便在出现问题时可以随意重新生成(例如,通信心跳停止,客户端崩溃)等).
数据库看起来太沉重,不够专业,无法处理IPC(进程间通信).该程序是在极端时间限制下编写的,因此利用数据库是"简单的解决方案",期望它将来会发生变化.我非常喜欢谷歌Chrome的多进程架构的强大功能,但我对它们如何将所有进程绑定在一起(管道,tcp,？)知之甚少.
所以:
我是否可以期望在数据库中使用IPC作为中间层可以显着提高性能？
什么形式的IPC在Windows系统上是理想的？
是否有可用的交叉平台(读取Linux)替代解决方案,如果将开发转移到Mono,可以使用它？
我在哪里可以找到有助于开始的资源/示例？
注意:我知道这个系统的体系结构似乎不必要地复杂,但它作为更大系统的前端存在.此应用程序也是关键任务,因此稳定性胜过效率.
更新:
我在最初的问题中忘了提到.数据库数据/索引在引导时直接从ramdisk加载.已对数据库本身编制索引以获得最佳性能.需要频繁写入的表或值不会编入索引,但其余数据都是索引.
我正在寻找一种替代方法来衡量,因为数据库的优化已经达到极限,我认为还有很大的改进空间.
一旦我有时间绘制它,我就会上传一些架构图.
是的。数据库很可能涉及硬盘驱动器，而硬盘驱动器是任何计算机中最慢的部分，因此不使用硬盘驱动器可能会带来性能优势。
我会选择Zeromq / zmq。它是一个面向消息的框架，支持多种通信模式。例如 PUB/SUB 或 REQ/REP 等。更多示例请参见此处
zmq 是跨平台的，而且速度快得惊人。
| 归档时间： |
|
| 查看次数： |
800 次 |
| 最近记录： |