为关键任务系统实现分布式n生产者/1消费者服务

Question

我正在尝试为关键任务系统实现多生产者/1-使用者的分布式版本。我正在寻找基于RDBMS的现有方法的良好替代方案。

问题

该系统由服务器(50+)生产者组成，它们每秒持续生成数千个实例。每个实例都是一个定义良好、时间戳好、结构平坦的实例。每个实例由生产者存储到一个队列中。

另一方面，我有一个以FIFO方式消费实例的消费者。

生产者和消费者在通过TCP/IP专用网络连接的不同机器上运行。

为了完整起见，有两个强烈的要求。

1. 使用者不能使用同一资源两次。这是个错误。
2. 每一种资源都必须由消费者消费。如果一个资源丢失了，那就是损失。

此外，该解决方案必须在Linux和Windows服务器上运行。

电流逼近

在当前版本中，系统通过使用关系数据库作为数据总线来实现此解决方案。

有一个数据库服务器支持所有生产者和消费者。生产者将资源插入到确定的表中，使用者将消耗来自该表的资源，如上面的图像所示。

数据库服务器/JDBC事务模型允许控制插入/删除，以避免队列损坏。

目前的办法运作良好，但：

1. 介绍为不需要数据关系的任务维护整个关系数据库服务器的开销；
2. 关系数据库服务器必须适应关键任务的需要，当数据库服务器实例不专用时，在某些实际设置中很难实现这一点。

Alternatives

这里我列出了当前关系数据库服务器数据总线方法的一些替代方案：

专用轻量级关系数据库服务器

这似乎是最简单的方法:使用专用的轻量级关系数据库服务器，如HSQLDB、Apache或H2。

Pros

与MySQL、Oracle服务器甚至MySQL等关系数据库管理系统相比，它们的维护开销要小得多。此外，需要更少的代码更改和测试，因为它们基本上是SQL引擎，就像当前解决方案中使用的引擎一样。

Cons

它们是关系数据库服务器，因此仍然存在一定程度的开销来执行不依赖关系的任务。另一点是关键任务方面。在嵌入式和网络模式下，我们在内部使用Derby实现实时系统监控。它工作得很好，既不崩溃，也不损坏数据。但是，这种新使用的事务量/秒更高。

Redis服务器

乍一看，Redis看起来非常适合这个用例。在内存中，速度快，没有过多的数据关系，直进.广泛用作数据库，并报告为可靠。但不适用于Windows。正如文档中所说的，不建议在Windows上使用Redis。Microsoft端口不再维护，最后一次发布日期是2016年，所以把Redis附加到系统上看上去并没有混淆。

从零开始实现一种解决方案

最后，这是一个生产者-消费者问题。使用TCP或更优雅的东西(如Camel )实现网络服务，并在内部使用并发队列，加上一些本地持久性引擎，这将是一种耗时的、重新发明轮子的方法，但它仍然是一种选择。

这些都是我们目前正在考虑的替代方案。如果有人能提供一些见解或建议，我很感激。

Answer 1

看来你在找消息队列。根据您的技术堆栈，可能会对分布式队列的各种实现感兴趣，例如ZeroMQ或RabbitMQ。

有些方法，比如ZeroMQ，可以在没有message的情况下运行，这意味着生产者和消费者直接交谈，而不需要其他服务或数据库来编排/代理队列。与代理消息队列相比，无券商的操作管理要简单得多，而且易于理解、缩放和定制，但主要的缺点是，它缺乏经纪人通常提供的服务，因此如果参与者离线，那么消息可能会丢失。如果您需要可靠地处理消息，则需要设计您的生产者，以便能够在使用者不可用的情况下处理重试发送，您需要添加确认机制以完成成功传递，并且使用者需要被设计为幂等(能够检测重复消息并丢弃它们)。无代理的主要优点是您可以自由地实现应用程序所需的尽可能多或最小的代理行为，因此您不受特定代理行为的约束。

在使用过程中，代理消息队列(如RabbitMQ )要简单一些，因为代理在队列系统的结构中添加了持久性和消息传递可靠性层，而不是要求生产者和使用者实现这些层，但它增加了管理代理的复杂性和开销，并且代理增加了延迟，因此它可能不适合于毫秒级重要或目标可伸缩性级别超过代理系统中可以实现的目标可实现程度的情况。

执行不依赖关系的任务仍然存在一定程度的开销。

我建议你分析一下你的应用程序，看看这是否真的很重要。如果进程内SQL数据库不足以用于非并发应用程序，则很可能是因为您使用它的效率不高，而不是因为关系管理本身的性能问题。