尝试设置 Graphite/Carbon 集群。我有一个弹性负载均衡器，用于引导集群中两个节点之间的流量，每个节点都有一个 Web 应用程序、中继和缓存。
在这个例子中，我向集群发送了 Metric1 的 1000 个计数。
下图所示：
问题
如上图所示，每台服务器大约保存了实际指标计数的一半。通过 Web 应用程序查询时，它仅返回实际计数的一半。根据这篇精彩的文章，这是预期行为，因为 Web 应用程序返回它看到的第一个结果。这意味着（并且有文档记录）节点上只应存储完整计数（在我的示例中，一个或两个节点应有 1000 个。）
所以我的问题似乎是计数的分片和复制不正确。在上面的例子中，当新的计数从网络进入时，它可以被重定向到 NodeA 或 NodeB。我假设计数可以通过任何中继进入集群。为了测试这个假设，我从集群中删除了负载平衡器，并将所有传入计数定向到 NodeA 的中继。这有效：完整计数出现在一个节点上，然后复制到第二个节点，并且完整计数从网络应用程序正确返回。
我的问题
似乎carbon-relay充当了应用程序级负载平衡器。这很好，但我担心当入站流量太大时，使用单个carbon-relay负载平衡器会成为瓶颈和单点故障。我更愿意使用实际的负载平衡器在集群的中继之间均匀分布传入流量。但是，carbon-relay似乎效果不佳，因此出现了上述问题。
- 为什么在上述场景中，中继集群将 Metric1 拆分到两个缓存之间？（当负载均衡器将输入分发到不同的中继时？）
- 我可以在 Graphite/Carbon 集群前使用弹性负载均衡器吗？我是否为此错误配置了集群？
- 如果不能，我是否应该将主服务器放在
carbon-relay其自己的盒子上以作为负载均衡器？
答案1
事实证明，我的配置DESTINATIONS实际上指向了carbon-caches 而不是另一个carbon-relay，这是由于端口号拼写错误。修复配置以实际表示问题中所示的图表似乎解决了问题：数据现在以完整形式出现在每个节点上（复制后）。
不过，顺便提一下，我现在遇到了 Web 应用程序渲染 API 结果不一致的问题，详情请见这个问题。它可能与上面详述的配置有关，也可能无关。
答案2
您遇到的是一个权限问题。使用 Whisper，每个时间序列数据库都需要由一个且唯一的 carbon-cache 守护进程拥有，否则您会遇到您所看到的一致性问题。carbon-relay 尝试通过向同一端点一致地发送相同的时间序列来解决此问题。您可以使用基于正则表达式的规则引擎或使用一致性哈希来执行此操作。
我的建议是不要过度设计问题，扩大规模直到无法再扩大，然后再扩大规模。我们有一个碳中继，每 60 秒处理 350,000 个指标，在一个 5 年历史的 Westmere EP 核心上没有任何问题。如果您使用一致性哈希，那么找出将指标路由到下游位置是一项非常低成本的操作。如果您使用大量正则表达式规则，那么就会有大量的字符串匹配，您可能会更快地遇到性能瓶颈。
Whisper 数据库的性能不是特别好。很有可能，在中继开始给您带来问题之前，您就会遇到 I/O 性能瓶颈。您完全是在过度思考您的架构。
如果您确实需要扩展超出单个节点所能提供的范围，您可以根据客户端配置管理逻辑路由到特定中继，也可以设置一个 ELB，路由到多个中继，每个中继都按照同一套规则运行，并将指标路由到相同的端点。我相信这需要您使用基于正则表达式的匹配，但如果您的中继是同一版本，一致性哈希也可能有效；我从未测试过这种方法。