【发布时间】：2014-12-12 01:34:19
【问题描述】：
我需要一些关于仅使用 Qt 类的 Qt 应用程序的建议。我可以接受 QtNetwork 和 QSql 模块作为解决方案，但不能接受 RabbitMQ 等“第三方”工具。
我将“事件存储作为队列”（参见Greg Young 第 46 页）与带有事件源的 CQRS 一起使用。我有一个简单的 SQL 表，用于存储具有唯一顺序 ID 的事件。因此，可以跟踪“跟踪进程”要使用的“事件存储指针”。
目标：我想运行多个进程来将事件处理为“将它们从队列中弹出”，确保它们只被处理一次......
在这个阶段，我只通过数据库（mySQL，SQLite）进行进程间通信，并设置一个共享表，将 TTL（生存时间）作为听到的节拍列表。 “TOP”进程充当工人。因此，如果它死了，TTL 超时，下一个接管。因此，TOP 工作人员会清除“陈旧的进程”。这有一些延迟，至少等于 TTL，例如。 5s 这不是最佳情况。
我现在想让其他进程也承担一些工作。我可以将“TOP”角色从 Worker 更改为 Dispatcher，但随后我需要与其他进程进行通信才能提供工作（例如 Process Events 100-200）。通过数据库进行调度在性能方面看起来不是一个好主意，因此我可以通过 QTcp** 类发出事件 ID 信号……这不是一个真正的问题。但是，随之而来的还有其他一些问题：当我的调度员死后会发生什么？一个进程扮演 Worker 和 Dispatcher 是一种好习惯吗？故障转移？冗余？可扩展性？
我确信必须有一些简单的解决方案，而不会让我头疼。负载均衡器？同样的问题也适用。负载均衡器只是一个调度程序。似乎我需要通过 TCP 在进程之间保持心跳。会更快......在这个阶段实施类似 RAFT 协议的东西是一种矫枉过正！不确定其他分布式设计模式或协议是否适用。我确实有一个 REST 框架……也许是 ATOM？ PubSubHubHub 和 WebHooks？不喜欢 WebSockets，因为我们需要持久化 TCP 连接...
欢迎提出想法、想法、建议！
【问题讨论】：
标签： c++ qt distributed cqrs event-sourcing