目录

摘要:

influxdb官方集群说明:

假设和要求

假设

要求

聚类设计

集群元数据 - CP

写 - 美联社

写入失败

提示切换

反熵修复

解决冲突

删除大段历史数据

可调查询一致性

结论

分析:

freetsdb方案:

总结:

---

摘要:

调研influxdb的集群, 研究如何做集群模式.

influxdb官方集群说明:

InfluxDB Clustering Design - neither strictly CP or AP | InfluxData

翻译后是这样的:

警告！请注意，此博客已有 1 年多的历史，请查看最新的InfluxDB Clustering并阅读有关InfluxDB Enterprise的更多信息。

几周前，我暗示 InfluxDB 集群设计将发生一些重大变化。这些更改是由于我们在过去 3 个月中对将在 0.9.0 中发布的集群设计进行的测试而产生的。简而言之，我们将采取的方法行不通。它不可靠或可扩展，并且为我们不需要为我们的用例提供的保证做出了牺牲。

六周前，我们后退了一步，重新评估了我们的整个集群方法。我们研究了我们需要提供的保证类型，更重要的是，我们研究了对我们无关紧要的保证。最后，我们重新审视了有关分布式系统、共识和冲突解决的文献。我们意识到我们可以构建一个更简单的系统，通过放宽时间序列数据用例不需要的约束来实现我们的可伸缩性和最大吞吐量的目标。

最终结果是将在 InfluxDB 的下一个构建中的集群实现。它专为吞吐量而设计，并将 CP 系统与 AP 系统结合用于主要写入路径。作为一个整体，它被设计为高度可用并最终保持一致。请继续阅读以获取非常详细的设计说明。非常感谢您的反馈。说分布式系统很困难将大大低估挑战。我们知道这需要迭代，但这种设计是我们构建的基础。

假设和要求

在进入具体设计之前，我们需要为我们所针对的时间序列用例列出一些关键要求。还有一些关于如何使用数据库的假设，这将使我们能够大大简化设计。

假设

• 时间序列数据几乎总是新数据（或历史回填），它们是客户提供的信息的关键，并且是不可变的。在我们的例子中，每个点都与测量名称、标签和时间戳相关联。
• 如果多次发送相同的数据点，则客户端刚刚发送两次的数据完全相同
• 删除很少发生。当它们确实发生时，几乎总是针对大量冷写的旧数据
• 对现有数据的更新很少发生，有争议的更新永远不会发生
• 绝大多数写入都是针对具有最近时间戳的数据
• 规模至关重要。许多时间序列用例处理 TB 或 PB 范围内的数据集大小
• 能够写入和查询数据比拥有高度一致的视图更重要
• 许多时间序列都是短暂的。经常有时间序列只出现几个小时然后就消失了，例如一个新主机启动并报告了一段时间然后被关闭

请注意，我们主要讨论具有大范围删除的插入的假设。有争议的更新不会出现，这使得解决冲突成为一个更容易处理的问题。稍后再详细介绍，让我们谈谈具体要求。

要求

• 水平可扩展——设计最初应该能够支持几百个节点，但无需完全重新架构即可扩展到几千个节点。读取和写入应随节点数量线性扩展。
• 可用——对于读写路径，支持 AP 设计。时间序列不断变化，我们很少需要对最新数据有完全一致的看法。
• 应该能够支持数十亿个时间序列，其中单个序列由测量名称加上标签集组合表示。这源于短暂的时间序列假设。
• 弹性——节点应该能够离开并且新节点可以加入集群。对于 0.9.0，这不需要是自动的，但设计应该在未来的版本中促进这一点，而无需重新架构。

要求非常简单。主要是您对一个为最终一致性而设计的水平可扩展分布式系统所期望的。InfluxDB 作为一个整体还有其他要求，但这些是驱动集群设计的要求。

如果您觉得这些要求和假设不合适，请告诉我们。但这些清楚地表明 InfluxDB 并非设计为通用数据库。如果这是你需要的，那就去别的地方。InfluxDB 专为时间序列、指标和分析数据而设计，这些数据是高吞吐量的插入工作负载。

聚类设计

新的集群设计由两个系统组成：一个用于存储集群元数据的 CP 系统和一个用于处理写入和读取的 AP 系统。本节将介绍每一个的设计，最后用一节展示两者如何在配置的集群中协同工作。

集群元数据 - CP

集群元数据系统是存储集群元数据的 Raft 集群。具体来说，它存储：

• 集群中的服务器 – 唯一 ID、主机名（如果它正在运行集群元数据服务）
• 数据库、保留策略和连续查询
• 用户和权限
• 分片组 - 开始和结束时间，分片
• Shards – 唯一的分片 id，具有分片副本的服务器 id

任何此类数据的更新都必须通过集群元数据服务运行。该服务是一个简单的 HTTP API，由Hashicorp Raft 实现支持，使用BoltDB作为底层存储引擎。

集群中的每台服务器都在内存中保存此集群元数据的副本。每个都将定期刷新整个元数据集以获取任何更改。对于进来的请求，如果有缓存未命中（比如它还不知道的数据库），它将向 CP 服务请求相关信息。

写 - 美联社

为了处理读取和写入，我们利用时间序列数据几乎总是新的不可变数据这一事实。这意味着我们可以绕过诸如矢量时钟之类的冲突解决方案或将其推送到客户端。我们倾向于接受写入和读取而不是强一致性。

需要注意的是，分片组和分片是在 CP 系统中创建的。在正常操作期间，这些将在它们将数据写入其中之前创建好。但是，这意味着如果一个节点与 CP 系统分离的时间过长，它将无法写入数据，因为它没有分片组定义。

例如，让我们看看当写入进来时会发生什么。假设我们有一个由 4 个服务器组成的集群：

数据归服务器 2-3 所有。

为了确定哪个服务器拥有数据，我们查看该点的时间戳以查看它属于哪个分片组。如果分片组不存在，我们调用 CP 集群元数据服务来获取或创建该点的时间范围的分片组。

从元数据服务返回的分片组中应该有分片，并且这些分片应该分配给集群中的服务器。因此，集群元数据服务负责布置数据在集群中的位置。将尽可能提前创建分片组，以避免在新的时间范围出现时大量写入冲击集群元数据服务。

一旦我们有了分片组，我们就根据分片数量对测量名称和标记集进行哈希处理，以查看数据点应该写入组中的哪个分片。请注意，这不是一致的散列算法。我们不关心一致性哈希的原因是，一旦分片组对写入变得冷，我们就不需要担心在调整大小的集群中平衡这些。虽然获得更多的读取可扩展性就像将写分片的冷复制到集群中的其他服务器一样简单。

数据的关键是测量名称、标记集和纳秒时间戳。例如，假设分片存在于服务器 2、3 和 4 上：

接下来发生的事情取决于所请求的写入操作的一致性级别。不同的级别是：

• Any – 如果任何拥有数据的服务器接受写入，或者一旦接收服务器（在我们的示例中为 1）将数据写入为持久提示切换（稍后将详细介绍），则成功
• One – 一旦拥有数据的服务器之一 (2, 3, 4) 响应成功，则成功
• Quorum – 当 n/2 + 1 个服务器接受写入时成功，其中 n 是拥有分片副本的服务器数量
• 全部 - 当所有服务器（2、3、4）接受写入时成功

写入数据的请求是并行发出的，并且在达到请求的级别时将成功返回给客户端。

写入失败

当写入失败或部分成功时会发生什么？例如，假设您要求仲裁，但只能写入主机 2，而主机 3 和 4 超时。

在这一点上，我们利用了我们关于时间序列数据的一个关键假设：写入总是针对新数据，这些数据与客户端提供的信息无关。

我们向客户端返回部分写入失败。同时，可以通过提示切换在后台复制写入。然后客户端要么失败，要么再次发出请求，这只会覆盖现有值。但重要的是要注意，失败的部分写入最终可能会被吸收并完全复制。

提示切换

提示切换有助于从短期中断（如服务器重新启动或由 GC 暂停或导致系统过载的大型查询导致的临时不可用）中快速恢复。

在我们之前的示例中，当写入进入服务器 1 时，它会尝试将该点写入服务器 2、3 和 4。如果写入一致性为 Quorum 或更低，则写入可能对任何故障使用提示切换服务器。

例如，如果我们有一个仲裁级别的写入，则有 2 个具有分片（2、3 或 4）的服务器将必须接受写入。成功返回给客户端。然后让我们说由于某种原因服务器 4 超时。然后，服务器 1 会将数据点写入提示切换。

提示的切换是一个持久的写入队列，用于服务器丢失的任何写入。因此，服务器 1 现在将写入存储在服务器 4 的磁盘上。当服务器 4 恢复运行时，服务器 1 会将写入从其提示的切换队列推送到服务器 4。

我们应该设置提示切换队列的最大大小。还应限制来自提示切换队列的写入，以避免最近在中断后恢复的服务器过载。

如果提示的切换写入达到了它们的 TTL，或者如果服务器 1 填满了服务器 4 的队列，则服务器 4 将不得不通过反熵修复过程进行恢复。

反熵修复

反熵修复确保我们获得所有数据的最终一致性。集群内的服务器偶尔会交换信息以确保它们拥有相同的数据。反熵适用于服务器长时间停机并且提示切换无法缓冲所有必要写入的情况。

每个分片的Merkle 树将与拥有该分片的其他服务器进行比较。在这里，我们将再次使用时间序列假设：写入总是针对新数据，我们想要所有这些。

因此，如果两台服务器发现一个分片有不匹配的数据，它们将一起工作来遍历默克尔树以找到不匹配的数据点。他们将交换他们不同的数据，并且分片将是来自服务器的该分片的数据的联合。

时间序列数据中的另一个关键假设将帮助我们减轻比较的负担。具体来说，所有写入的数据都是针对最近的时间范围的，加载历史数据时除外。

因此，我们将不经常检查旧分片的一致性。也许一个小时或一天一次，它将是可配置的。完全修复是用户应该能够请求的东西（如 Cassandra 的节点修复工具）。

对于写入热的分片，我们将只对早于一些可配置时间的数据进行比较。例如，我们只会对分片中超过 5 分钟的数据运行哈希比较。

解决冲突

只有当用户对现有数据点执行更新时，冲突解决才会发挥作用。我们处理冲突解决的方案很简单：价值越大越好。如果是在一个或多个服务器上丢失数据的情况，那么最终的集合应该是来自所有服务器的数据的并集。

这使我们进行冲突解决的开销非常低。不需要任何矢量时钟。

鉴于此，更新和删除操作应设置 ALL 的一致性级别，以确保它们成功且不会丢失。如果 ALL 没有响应，则可能会在反熵修复启动时恢复删除或覆盖更新。

这意味着持久删除和更新不是高度可用的。我们的假设是这两种操作都很少见。

该方案需要注意的是，保留策略强制执行的数据保留实际上最终会保持一致。每个节点将在本地对其分片执行保留策略。

删除大段历史数据

如果使用 ALL 一致性级别，则通过正常写入路径运行的删除操作不具有高可用性。但是，删除旧历史数据的完整分片的删除可能更容错。

这是因为删除分片通过集群元数据服务。请记住，分片是按时间排序的连续数据块。删除大量旧历史数据的最有效方法是删除整个分片或分片组。

这些操作是针对 CP 集群元数据服务执行的。请求可以进入集群中的任何服务器，并将相应地进行路由。

可调查询一致性

集群的初始版本将检查每个分片都有副本的单个服务器，从而形成有效的一致性级别ONE。更高版本将启用可调级别的一致性。

结论

最后，您可能会问，这种设计属于CAP范围内的哪个位置？答案是它既不是纯CP也不是纯AP系统。有一部分是 CP，但来自该系统的数据最终在整个集群中是一致的。也有部分是 AP，但如果这些节点和 CP 系统之间有足够长的分区，那将不再可用。

关于集群设计，我们可以谈论更多的事情。特别是关于如何处理每个失败案例。关于集群元数据的删除和更新，我们可以涵盖更多深入的细节。在接下来的几个月里，我们将努力记录这些事情并详细充实每个案例。生产环境中的这些情况比它是 CP 还是 AP 更重要，我们将努力提供尽可能多的信息和数据。

此设计基于 InfluxDB 中的三个集群迭代。我们基于我们认为可以接受的权衡取舍，并专注于我们用例中一些最重要的部分：水平可扩展性和低写入开销。欢迎反馈、想法甚至挑战！

分析:

influxdb将cluster闭源作为商业卖点. 以上为开发者对于集群的需求的限定, 可以看出influxdb实现的cluster是针对特定的需求非常特化. 

此外值得注意的是, influxdb的开发者直到测试阶段才发现此前的集群模式存在设计上的问题, 从而不得不再次重新设计集群模式, 并且特意砍掉一部分的需求以满足集群的特性.

freetsdb方案:

腾讯开发的兼容influxdb的集群版, 目标在于替换influxdb的商业版本. 当前发布到了0.1.2.

GitHub - freetsdb/freetsdb: An Open-Source Distributed Time Series Database, and the BEST Open-Source replacement for InfluxDB Enterprise.

https://github.com/freetsdb/freetsdb/archive/refs/tags/v0.1.2.tar.gz

官方说明:

*[English](README.md) ∙ [简体中文](README-zh-Hans.md)*

# FreeTSDB

## An Open-Source Distributed Time Series Database, and the BEST Open-Source replacement for InfluxDB Enterprise.

FreeTSDB是一个开源的分布式时间序列数据库，是InfluxDB企业版的开源替代，增强了代码健壮性、补齐集群等高可用能力、100%兼容InfluxDB生态和接口。

## 性能

FreeTSDB与InfluxDB性能一致，比如，在阿里云ECS（16 vCPU 32 GiB, Ubuntu 18.04 64bit），FreeTSDB的写性能是**386985.67 point/sec**，大约是阿里云InfluxDB服务(16核64G ：~ 150000 point/sec)的**2.58倍**。


 

## 文档

* FreeTSDB编译

* 快速启动FreeTSDB

* [快速启动FreeTSDB集群](docs-cn/get-started-cluster.md)

* FreeTSDB常用基础操作

* FreeTSDB配置优化

* FreeTSDB常见问题汇总

## 架构


## 技术资料

* 极客时间: [《分布式协议和算法实战 - 攻克分布式系统设计的关键难题》](https://time.geekbang.org/column/intro/279)

* 机械工业出版社: [《InfluxDB原理与实战》](https://item.jd.com/12857280.html)

*  [《为什么是InfluxDB | 写在《InfluxDB原理和实战》出版之际》](https://mp.weixin.qq.com/s/44DD2fJyXQnAF9_I4-4RUQ)

*  [《我想和你聊聊：FreeTSDB不只是InfluxDB集群》](https://mp.weixin.qq.com/s/zvbv42fjiQAHQYGBOjANIA)

 

## 联系我们

* **FreeTSDB技术交流QQ群**：663274123

* **微信**：（包括但不局限于咖啡、聊天、吐槽）


 

总结:

因influxdb的集群不开源, 以freetsdb为研究重点