创建在所有进程之间共享状态的多进程架构的最轻量级解决方案是什么

发布于 2025-01-07 05:18:35 字数 1547 浏览 1 评论 0原文

我的多层应用程序架构由 4 个部分组成：

网络服务器/客户端层
处理进程之间交互的中间数据层
监控层
由 n 个实例组成的客户端层

客户端/服务器层：客户

端/服务器层处理与使用自定义第 2 层协议实现的另一台计算机的异步网络通信。由于通信中内置的设计限制，它需要保持独立并能够异步轮询/推送数据到数据层。

中间层：

中间层目前是使用数据库实现的。一张表包含所有可以调用的可能标签（大约 120,000 个）。第二个表保存第一个表的中间缓存，仅包含正在使用的值，这需要不断更新，并在请求新的项目集合时刷新。第三个表是发送集合更新的位置，并且仅在请求挂起时包含数据。

监控层：

监控层是一个多线程整体应用程序。它根据连接的监视器数量生成 n 个客户端实例。它管理所有客户端实例之间的全局状态，因为其中一个或多个可能共享相似/相同的状态。它创建所需值的唯一列表，在客户端需要一组不同的标签时管理发送更新请求，并管理定期更新。

显然，这并不理想。如果一个实例出现故障，其他实例也会随之崩溃。我想做的是删除中间层，用监视器层替换它，并使所有内容都作为监视器进程的子进程生成，这样如果出现问题（例如通信心跳停止、客户端崩溃），它们可以随意重新生成， ETC）。

该数据库似乎太重并且不够专业，无法处理 IPC（进程间通信）。该程序是在极端的时间限制下编写的，因此利用数据库是“简单的解决方案”，预计它会在未来发生变化。我非常喜欢 Google Chrome 的多进程架构< /a> 但我对它们如何将所有进程连接在一起（管道，tcp，？）知之甚少。

所以：

在中间层使用 IPC 而不是数据库可以带来显着的性能提升吗？
我
哪种形式的 IPC 在 Windows 系统上是理想的？
如果开发转移到 Mono，是否有可用的跨平台（读取 Linux）替代解决方案可以替代它？
在哪里可以找到帮助入门的资源/示例？

注意：我知道这个系统的架构似乎不必要地复杂，但它作为一个更大系统的前端而存在。该应用程序也是关键任务，因此稳定性胜过效率。

更新：

我忘了在最初的问题中提及。数据库数据/索引在启动时直接从 ramdisk 加载。数据库本身已建立索引以获得最佳性能。需要频繁写入的表或值不会被索引，但其余数据会被索引。

我正在寻找一种替代方案来衡量，因为数据库的优化已达到极限，我认为有还有很大的改进空间。

一旦我有时间绘制一些架构图，我就会上传它们。

原文

I have multi-layered application architecture that has 4 parts:

A networking server/client layer
An intermediate data layer to handle interactions between processes
A monitoring layer
A client layer made up of n number of instances

Client/Server layer:

The client/server layer handles asynchronous network communications with another computer implemented using a custom Layer 2 protocol. Due to design constraints built into the communications, it needs to remain independent and able to poll/push data to the data layer asynchronously.

Intermediate Layer:

The intermediate layer is currently implemented using a database. One table holds all of the possible labels that can be called on (about 120,000). A second table holds an intermediate cache of the first table containing only the values in use, this requires constant updates and gets flushed when a new collection of items is requested. The third table is where collection updates are sent and only contains data when a request is pending.

The Monitor Layer:

The monitor layer is a multi-threaded monolithic application. It spawns n number of client instances based on how many monitors are attached. It manages global state between all client instances because one or more of them may share similar/identical state. It creates a unique listing of values needed, manages sending update requests when the clients need a different set of labels, and manages recurring updates.

Obviously, this isn't ideal. If one instance goes down it can take the rest down with it. What I'd like to do is remove the intermediate layer, replace it with the monitor layer, and make everything spawn as subprocesses of the monitor process so they can be respawned at will if something goes awry (ex. comms heartbeat stops, client crashes, etc).

The database just seems too heavy and not specialized enough to handle the IPC (Inter Process Communications). The program was written under extreme time constraints so utilizing a database was the 'easy solution' with the expectation that it would change in the future. I'm a big fan of the robustness of Google Chrome's multi-process architecture but I know little about how they tie all the processes together (pipes, tcp, ?).

So:

Could I expect a significant performance improvement from using IPC over a database for the intermediate layer?
What form of IPC would be ideal on a Windows system?
Is there a cross platform (read Linux) alternative solution available that could be used in its place if development were moved to Mono?
Where can I find resources/examples to help get a start?

Note: I understand that the architecture of this system seems unnecessarily complex but it exists as a front-end for a much larger system. This application is also mission critical so stability trumps efficiency.

Update:

I forgot to mention in the initial question. The database data/index is loaded directly from a ramdisk on boot. The database itself has been indexed for optimal performance. Tables or values that require frequent writes are not indexed but the rest of the data is.

I'm looking for an alternative to measure against because optimization of the db has been taken to its limit and I think there's still a lot of room for improvement.

I will upload a some diagrams of the architecture as soon as I get some time to draw them up.

分享到QQ

分享到微博