Hulu如何扩展InfluxDB使其支持每秒百万TPS
185 浏览量
2021-01-06
23:54:31
上传
评论
收藏 366KB PDF 举报
Hulu如何扩展如何扩展InfluxDB使其支持每秒百万使其支持每秒百万TPS
导读：InfluxDB是最常用的时间序列数据库之一，大家广泛使用其开源版本。然而其开源版本缺乏一些高可用相关的特性，本文介绍Hulu在使用InfluxDB的过程中碰见的问题和解决方案，十分值得一读。
随着Hulu的持续增长，时间序列数据库已成为公司监控系统的关键部分。 这可以像机器性能指标或应用程序本身的数据一样简单处理。 由于我们拥有的数据量很大，因此创建一个支持冗余和可扩展的体
系结构至关重要。
为什么时间序列数据很重要？为什么时间序列数据很重要？
时间序列数据使我们能够评估趋势，以便发现问题并采取措施。
下图用于确定最近的内存泄漏，该问题会影响在特定数据中心运行的应用程序版本。
Graphite 架构架构
最初，每个开发团队都有自己的时间序列数据解决方案。 由于大多数团队都有类似的需求，这种情况无疑是浪费资源的。 为了解决这个问题，我们建立了原始的时间序列数据管道，该管道为整个工程团
队提供了时间序列数据库。
该管道基于Graphite，并将数据存储到OpenTSDB。 在高峰时，该Graphite集群的吞吐量为每秒140万个指标。 在维持这一流程的同时，我们遇到了许多问题，这些问题随着我们继续增长而变得越来越
常见。
其中许多问题源于为Hulu所有开发团队提供数据管道共享服务， 这样就需要支持巨大吞吐量和基数，其他问题是来自于可伸缩性的固有问题。
数据管道遇到的挑战数据管道遇到的挑战
使用方经常且无意间会在其标准名称空间中发送唯一数据，例如时间戳或另一个唯一标识符。 例如：
stats.application.dc1.1557471341.count 1 1557471341
stats.application.dc1.1557471345.count 1 1557471345
stats.application.dc1.1557471346.count 1 1557471346
这导致了命名空间中基数爆炸式增长，从而影响了接收速度和整个管道的稳定性。尽管可以阻止这些行为，但是这样做非常困难，因为需要匹配有问题的指标，而不能影响合法指标。
由于吞吐量的限制，我们在创建规则的复杂性和数量方面受到限制，因为必须针对接收到的每个指标使用所有规则进行评估。这需要在指标数据涉及的许多节点上以滚动的方式完成。因此通常很少会添加条件来阻止有问题的指标，一般倾向于让应用程序停止发送指标。不幸的是，在大多数情况下，花费的时间导致数据丢失。
检索数据时，许多用户会无意中运行很长时间或占用大量资源的查询，这最终将导致为其提供数据的后端超时并宕机。没有叫停这种行为的限制，这也影响了整个系统的稳定性。
发送的指标也是有问题的。由于格式并没有标准化，因此找出哪个服务正在发送特定指标需要进行大量猜测，而在我们实际需要这样做时非常困难。
最后，由于我们的设置，所有指标都被发送到了两个数据中心之一。如果发生故障，则整个数据中心的指标将无法访问。此外，由于我们只有一个统一的接口来检索这些指标，因此我们优先于一个数据中心。这是有问题的，因为如果用户向第一个优先级数据中心发送了一个指标，但随后决定使用另一个数据中心，由于第一个数据中心已经存在命名空间，因此将无法访问他们的新指标，从而导致问题。
InfluxDB初始架构初始架构
为了解决这些问题，我们决定基于InfluxDB从头开始重新构建统计数据管道。 对于我们的第一次尝试，我们创建了两个集群，在两个主要数据中心（DC1和DC2）中各有一个。 两个群集将包含相同的数据。
在此基础上构建了一个指标中继群集。 所有指标都将发送到中继群集。 该集群的唯一目的是将收到的所有指标推送到两个InfluxDB集群中。 这样就可以从任何数据中心检索所有指标，从而完全消除了在Graphite体系结构中遇到的指标可用性问题。 我们在每个数据中心都有指标中继层。
资源评论
