我正在尝试提出一种架构，我们有一些在 python-Autobahn 上运行的流/RPC 客户端。我们有一个 crossbar 代理，它允许消费者应用程序获取 RPC/流并在数据库中处理这些值。目前，我们的策略是使用
[
N client (publishing stream /registering/calling RPC) —> Xbar1 —> a consumer application which takes care of all these data points by N clients and stored them in the DB
M client (publishing stream /registering/calling RPC) —> Xbar2 —> a consumer application which takes care of all these data points by M clients and stored them in the DB
]
如果我们有一对一映射，这种方法效果很好，但这也意味着我们无法独立扩展 Xbar 服务器和消费者应用程序的数量，因为如果我们这样做，我们将遇到以下问题
All client (publishing stream /registering/calling RPC) —> Xbar1 —> a consumer application which takes care of all these data points and stored them in the DB
达到 80% 的容量，我们必须启动一个新的 xbar 实例来平衡负载。
All client (publishing stream /registering/calling RPC) —> Xbar1 —> a consumer application which takes care of all these data points and stored them in the DB
Xbar2 —> a consumer application which takes care of all these data points and stored them in the DB
问题是我们不想在数据库中有重复的条目，因为如果我们根据负载扩大规模，相同的消息将由 Xbar1 和 Xbar2 处理，我们需要某种类型的服务来整合数据点并处理它们一次，我想听取一些想法并听取有关潜在的解决方案的信息。