Uber 时序数据库M3DB初探

Uber M3 是一个已在优步使用多年的指标平台。 M3 可以在较长的保留时间内可靠地存储大规模指标。本篇文章抛砖引玉，带大家了解一下M3DB，同时M3也可以做为Prometheus后端存储，旨在为Prometheus指标提供安全，可扩展且可配置的多租户的存储。

组件介绍

M3 Coordinator

M3

Coordinator 是一种服务，用于协调上游系统（如 Prometheus 和 M3DB ）之间的读写操作。它是用户可以部署以访问 M3DB 的优势的桥梁，例如长期存储和与其他监控系统（如

Prometheus ）的多 DC 设置。

M3DB

M3DB 是一个分布式时间序列数据库，提供可扩展存储和时间序列的反向索引。它经过优化，具有成本效益和可靠的实时和长期保留指标存储和索引。

M3 Query

M3 Query 是一种服务，它包含一个分布式查询引擎，用于查询实时和历史指标，支持多种不同的查询语言。它旨在支持低延迟实时查询和可能需要更长时间执行的查询，聚合更大的数据集，用于分析用例。

Aggregator

M3 Aggregator 是一种作为专用度量聚合器运行的服务，它基于存储在 etcd 中的动态规则提供基于流的下采样。它使用领导者选举和聚合窗口跟踪，利用 etcd 来管理此状态，从而可靠地为低采样度量标准发送至少一次聚合到长期存储。这提供了成本有效且可靠的下采样和汇总指标。这些功能也存在于 M3 Coordinator 中，但专用聚合器是分片和复制的，而 M3

Coordinator 则不需要并且需要谨慎部署和以高可用性方式运行。还有一些工作要使用户更容易访问聚合器，而无需他们编写自己的兼容生产者和消费者。

高可用方案 : Quorum

Read/Write

Uber M3DB 在高可用方面采用的是 Quorum Write/Read 方式。下面是 Quorum 算法的介绍。

Quorum 机制详细描述

在有冗余数据的分布式存储系统当中，冗余数据对象会在不同的机器之间存放多份拷贝。但是同一时刻一个数据对象的多份拷贝只能用于读或者用于写。

该算法可以保证同一份数据对象的多份拷贝不会被超过两个访问对象读写。

分布式系统中的每一份数据拷贝对象都被赋予一票。每一个读操作获得的票数必须大于最小读票数（read quorum）（Vr），每个写操作必须获得获得的票数必须大于最小写票数（write quorum）(Vw）才能读或者写。如果系统有V票（意味着一个数据对象有V份冗余拷贝），那么最小读写票数(quorum)应满足如下限制：

1. Vr + Vw >

   V

2. Vw > V/2

第一条规则保证了一个数据不会被同时读写。当一个写操作请求过来的时候，它必须要获得Vw个冗余拷贝的许可。而剩下的数量是V-Vw 不够Vr，因此不能再有读请求过来了。同理，当读请求已经获得了Vr个冗余拷贝的许可时，写请求就无法获得许可了。

第二条规则保证了数据的串行化修改。一份数据的冗余拷贝不可能同时被两个写请求修改。

根据用户对数据的一致性的要求，M3DB 提供了不同程度的强度。在写多读少的场景中，write consistency 可以配置成one，read consistency 则需要配置成 all 以获取确保最新和最全的数据。在读多写少的情况，write consistency 可以配置成 all，read consistency 则可以配置成 one。这样，所有 replicas 的数据是一致的。

Write consistency

levels

• One:

   Corresponds to a single node

  succeeding for an operation to succeed.

• Majority:

   Corresponds to the majority

  of nodes succeeding for an operation to succeed.

• All:

   Corresponds to all nodes succeeding

  for an operation to succeed.

Read consistency

• One

  : Corresponds to reading from a single

  node to designate success.

• UnstrictMajority

  : Corresponds to reading from the

  majority of nodes but relaxing the constraint when it cannot be met,

  falling back to returning success when reading from at least a single node

  after attempting reading from the majority of nodes.

• Majority majority of nodes to designate success.

•  Corresponds to reading from all of

  the nodes to designate success.

以上是一个有三个备份的 M3DB 集群，每个节点中拥有三个分片。假设用户配置的 write

consistency 是 all，则每次用户写入 M3DB 都需要将数据确认成功写入到三个节点在返回成功，有一个节点失败或者无响应，写入请求都会返回失败。如果配置是 majority，则两个节点写入成功，写入请求将会返回成功。同理，one 的情况，只要任意一个节点写入成功，写入请求就会返回成功。

根据不同 write

consistency level，我们需要配置相应的 read consistency level，以确保准确性和完成行。

One => All | All => One | Majority => Majority。All => One 场景最简单，由于写入时候确保各个节点的一致性，我们可以读取任意一个节点数据即可。在

One => All 的场景中，M3DB 需要对所有节点进行读操作，比较版本，选取最新版本的数据和整合所有数据，将结果返回。同理，Majority => Majority 场景选用类似操作。

根据上面这个配置，在 write consistency = all 的情况下，允许最多两个节点挂掉，M3DB 仍可服务。

在 write consistency = majority 的情况下，允许最多一个节点挂掉。在 write consistency = one 的时候，任何节点都必须在线且健康，才能保证服务可用性和准确性。

阿里云时序时空数据库TSDB 1元购！立即体验

：

https://promotion.aliyun.com/ntms/act/tsdbtry.html?spm=5176.149792.775960.1.dd9e34e2zgsuEM&wh_ttid=pc