Java 分布式数据存储体系结构

目前我有两个独立的应用程序

首先是RESTfulAPI

第二种是数据存储，它可以处理原始数据并将处理后的数据存储在文件系统上。此数据按文件夹分组，文件夹ID按用户ID分组

这些应用程序使用queueCount队列通过消息队列（ActiveMQ）连接

使用嵌入式文件服务器也通过此队列发送文件

我想将此数据存储分布到多个节点上

1） 第一变体

在n个节点中的每个节点上设置ActiveMQ和当前存储应用程序。 创建将为这些碎片提供查询的主节点。 这样，不同用户的数据将存储在不同的节点上

2） 第二

使用存储应用程序设置n个节点。为ActiveMQ设置一个实例。在ActiveMQ中创建n*queueCount队列。使用存储节点对应队列中的消息

但这两种变体都不完美，也许你可以给我一些建议？ 提前谢谢

更新：

---

基于uuid均匀分布数据的最佳方法是什么？

为什么不使用像hdfs这样的分布式文件系统来分布数据存储。通过这种方式可以覆盖复制、分发数据，甚至可以使用hadoop发送作业来并行处理数据

@vvsh，您正在尝试的是具有负载平衡的分布式存储（但我不明白您计划如何将特定用户的文件保留在特定节点上，同时获得均衡的负载分布）。无论如何，在我进一步深入之前，你所尝试的机制很难以一种稳定的方式实现，相反，考虑使用评论中提到的一些基础结构，它们可能不符合你的要求，但会做得更好。 现在，为了实现均匀分布，您的体系结构本质上需要某种中心辐射模型，其中中心（在您的情况下是主服务器）将从单个队列收集负载，其中多个JMS客户端在多个线程上运行。主服务器基本上必须执行循环调度（如果文件大小相当恒定，或者文件大小和净总调度到节点，则可以根据文件号选择不同类型的方案）

持久化代理必须在每个节点上运行，才能实际获取文件、处理它们并持久化到数据存储中。主机和代理之间的通信可以通过web服务或直接套接字（取决于您需要的性能），与代理之间基于Q的通信可能会阻塞JMS服务器

观察到的一点是，文件可以放在另一个位置，如文档/CMS，通过减少网络负载和JMS持久性负载，只有ID可以传递给主机和代理

---

上述机制需要考虑异常、故障和重新调度，即保证交付、水平扩展、并发处理和性能优化。在我看来，您最好使用一些经过验证的基础设施，但如果您真的想这样做，上述体系结构将完成任务。

因为我想分配负载，数据处理可能会使处理器负载过重，我需要更多节点来同时处理多个不同的用户。请使用第一个选项，即使用一个队列。如果负载非常高，因此发布率高于使用率，则可以轻松附加使用者，从而进行扩展。顺便说一句，我最近遇到了twitter风暴，它看起来非常适合这样的拓扑。如果ActiveMQ包含同样多的队列，那就好了？这对it性能不是没有问题吗？我会使用一个队列，正如您在这里看到的，发布者和消费者可以来来去去，但是队列是静态的，除非您要进行备份。每个消费者有一个队列是一个很大的开销。是否有某种方法可以从一个队列中为不同的消费者使用不同类型的消息？例如，基于某个标题？我希望均匀分布数据，而不是加载。每个节点都将处理自己的数据。你能解释一下“平均分布数据”是什么意思吗？例如，我有1000个用户和10个节点。我希望每个节点包含大约100个用户的数据，因为每个用户将拥有几乎相同的数据量。与上述相同的机制将起作用，只是您将有特定的用户到节点映射，而不是循环。出于好奇，您是在生产中实现这一点，还是为了知识/学习而进行测试？没有分布式体系结构的应用程序已经准备好，可以在谷歌云中的测试服务器上运行。但这是我的个人项目，我不知道它是否会出版。