目前我有两个单独的应用程序。
首先是 RESTful API。
其次是数据存储，可以处理原始数据并将处理后的数据存储在文件系统上。此数据按文件夹和文件夹 ID 分组，按用户 ID 分组。
这些应用程序通过消息队列 (ActiveMQ( 使用 queueCount 队列进行连接。
文件也使用嵌入式文件服务器通过此队列发送。
我想将此数据存储分布在多个节点上。
1( 第一个变体
在n个节点中的每一个节点上设置ActiveMQ和当前存储应用程序。创建将向这些分片提供查询的主节点。这样，不同用户的数据将存储在不同的节点上。
2( 第二
使用存储应用程序设置 n 个节点。 为 ActiveMQ 设置一个实例。在 ActiveMQ 中创建 n*queueCount 队列。使用来自存储节点的相应队列的消息。
但是这两种变体都不完美，也许您可以给我建议？提前致谢
更新：基于 uuid 均匀分布数据的最佳方法是什么？
为什么不使用像 hdfs 这样的分布式文件系统来分发数据存储。通过这种方式，可以覆盖复制，分发数据，甚至可以使用 Hadoop发送作业以并行处理数据。
@vvsh，您正在尝试的是具有负载平衡的分布式存储(但我不明白您计划如何将特定用户的文件保存在特定节点上，同时获得均匀的负载分配(。无论如何，在我进一步讨论之前，您尝试的机制很难以稳定的方式实现，相反，请考虑使用评论中提到的一些基础设施，它们可能不是 100% 符合您的要求，但会做得更好。
现在，为了实现均匀分布，您的架构本质上需要是某种中心辐射型模型，其中中心服务器(在您的例子中是主服务器(将从单个队列中收集负载，其中多个 JMS 客户端在多个线程上运行。主服务器基本上必须执行轮询调度(如果文件大小相当恒定或文件大小和调度到节点的净总数相当恒定，则可以根据文件编号选择不同类型的方案(。
持久性代理必须在每个节点上运行，才能实际获取文件、处理文件并在数据存储中保留文件。主服务器和代理程序之间的通信可以通过 Web 服务或直接套接字进行(具体取决于您需要的性能(，与代理程序的基于 Q 的通信可能会阻塞您的 JMS 服务器。
一个观察点是，文件可以暂存到另一个位置，如文档/CMS，并且只有 ID 可以传达给主节点和代理，从而减少网络负载和 JMS 持久性负载。
上述机制需要处理异常、故障和重新调度，即保证交付、水平扩展、并发处理和针对性能进行优化。在我看来，最好使用一些经过验证的基础设施，但如果你真的想这样做，上面的架构将完成工作。