具有历史数据完整性的实时事件存储系统设计

Question

我正在创建一个系统，它使用Java服务器从各种渠道收集实时数据，并将这些数据存储在NoSql数据库中。我有N个节点，每个节点负责自己的一组信道。

我的要求之一是数据完整性。有鉴于此，我需要处理接下来的两起案件：

1. 当PC被关闭，或者JVM在下一个启动系统上出现->故障时，系统应该离线并创建工作，以缩小数据历史间隔。
2. 当NoSql存储不可用时，->系统应该将数据保存在某个地方(实时数据或间隙时间数据)。

所以，我的问题是：

• 如何跟踪每个节点的脱机时间？
• 我应该在心跳时使用一些内部存储(比如SqlLite)吗？
• 我是否应该在心跳时使用原始数据库？
• 管理这类案件的一般办法是什么？

提前感谢

Answer 1

在起草任何体系结构之前，首先要记住的是帽子定理，它说，您不能拥有一个具有高性能、高一致性和分区的系统--至少应该牺牲其中一个参数来支持另外两个参数。在我看来，你似乎想要所有这些，这是不可能的，所以你需要决定什么对你的业务领域更重要。

由于我不知道您的系统的所有细节+我甚至不知道什么是业务领域，我所能建议的只是一种通用的方法来满足您的需求。考虑到上述所有因素，以下是一种一般做法：

1. REST (或API )。显然，它将为客户端请求提供服务。这里的主要思想是，它将对所有请求返回相同的响应，告诉他们我们接受了处理请求。在这个步骤中，我们将消息推送到message。

2. Message (Kafka，RabbitMQ等)。--这是我们存储异步处理请求的地方。

3.您的应用程序.--它们将侦听message中的队列，每当消息在那里时，应用程序就会使用它进行处理。处理完成后，应用程序会将结果存储在DB中。

4.DB.只存储应用程序执行的处理结果。

这样做的想法是，如果您的message关闭--客户端将立即收到消息无法处理的通知。如果应用程序关闭，消息将不会丢失，因为它们在队列中。如果DB关闭-消息将仍然在队列中，因为应用程序将无法使用它。请注意，如果您正确地执行所有操作，您的队列就不太可能关闭。如今的消息经纪人真的(真的很像)速度快，规模也很好，例如，Kafka在Linkedin处理了数十亿条信息，对他们来说一切都很好。

希望这能帮上忙！