TiKV 在京东云对象存储元数据管理的实践

京东云对象存储是在 2016 年做为公有云对外公开的，主要特色是可靠、安全、海量、低成本，应用于包括一些经常使用的业务场景，好比京东内部的京东商城视频/图片云存储，面向京东云公有云外部的开发者的服务，和面向政府、企业的私有云服务，甚至混合云服务。

本文将介绍京东云对象存储服务的架构演进，以及迁移到 TiKV 的经验。

1、对象存储简介

首先举例说明一下这里的“对象 (Object)”概念。好比咱们把一张照片看成一个“对象”，除了照片自己的二进制数据，它还应该包含一些元信息（照片数据长度、上次修改时间等）、涉及用户的数据（拍摄者、拍摄设备数据等）。对象存储的特色是这些数据不会频繁地修改。

若是是数量比较少的图片存储，咱们可能会用相似 LVM 之类的东西，把一个节点上的多个磁盘使用起来，这种方法通常适用于数量级在 1M ~ 10M 的图片。随着业务的增加，图片会愈来愈多甚至有视频存储，所以咱们采用分布式文件系统来存储，这种方法是基于 DFS 的架构（以下图所示）。

这种方法的前提是单机容量受限，必须把数据放在多台机器上存储，而且用一个或多个独立的 node 存储元数据，而且元数据会维持树状目录的结构，拆分比较困难。可是这个架构通常适合存储到 10 亿级别的对象，同时存在两个比较大的问题：

• 数据分布式存储在不一样的节点上，若是存在一个中心的 master 节点的数据是相对有限的，那么这个机器就不太可能无限扩张下去。
• 元数据管理是树状结构，它自己并不适合作分布式存储，而且目录结构须要屡次访问，不适合把它放到 SSD上，而更适合放在内存里，而后通常受权一个 master 节点 list。HDFS 基本也是这样。
  

那么若是要求作千亿级的对象存储，如何实现呢？最容易想到的办法是将元数据分布式存储，再也不像文件系统中那样存储在单独的机器上，是一个树状结构，而是变成一个平坦结构。

2、对象存储元数据管理系统

回到上面的举例，针对一个图片对象咱们主要有四类操做：上传（Put）、下载（Get）、删除（Delete），Scan。Scan 操做相对比较传统 ，好比查看当前有多少图片对象，获取全部图片名称。

1. 元数据管理系统 v1.0

上面是一个最简单、原始的方案，这里 Bucket 至关于名字空间（Namespace）。不少人最开始设计的结构也就是这样的，但后期数据量增加很快的时候会遇到一些问题，以下图。

第一个问题是，在初期数据量比较小的时候，可能只分了 4 个 Bucket 存储，随着业务增加，须要从新拆分到 400 个 Bucket 中，数据迁移是一个 Rehash 过程，这是一件很是复杂且麻烦的事情。因此，咱们在思考对象存储连续的、跨数量级的无限扩展要怎么作呢？下图是一个相对复杂的解决方案，核心思想是把绝大部分数据作静态处理，由于静态的存储，不管是作迁移仍是作拆分，都比较简单。好比天天都把前一天写入的数据静态化，合到历史数据中去。

针对第二个问题，若是单个 Bucket 数据量很大，那么在往 Stable Meta（上图中黄色部分）作静态化迁移时须要作深度拆分，单个 Bucket 的对象的数量很是多，在一个数据库里面存储不下来，须要存储在多个数据库里面，再创建一层索引，存储每一个数据库里面存储那个区间的数据。同时，咱们在运行的时候其实也会出现一个 Bucket 数量变多的状况，这种是属于非预期的变多，这种状况下咱们的作法是弄了一大堆外部的监控程序，监控 Bucket 的量，在 Bucket 量过大的时候，会主动去触发表分裂、迁移等一系列流程。

这个解决方案有两个明显的问题，第一数据分布复杂，管理困难；第二，调度不灵活，给后期维护带来很大的困难。

因此，咱们思考了这个事情本质实际上是作一个全局有序 KV，而且须要“足够大”，可以弹性扩张。这样系统架构就会变得很是简单（如上图所示）。 固然最终咱们找到了分布式 KV 数据库—— TiKV。

2. 基于 TiKV 的元数据管理系统

咱们前期调研了不少产品，最终选择 TiKV 主要缘由有如下四点：

• 全局有序 KV，可轻松⽔平扩展，功能上彻底可以满⾜对象存储元数据管理的需求。
• 通过一些测试，性能上很好，可以知足要求。
• 社区活跃，文档和工具相对比较完善。这一点也很重要，TiKV 目前已是CNCF（云原生计算基金会）的孵化项目，不少功能能够快速开发，产品迭代也很迅速。
• 相对于 TiDB Server 而言，TiKV
  的代码更加简单，并且咱们后续能够在 TiKV 的基础上作更多开发工做。

在上线以前，咱们主要进行了如下几方面的测试：

• 功能测试：测试 TiKV 的基本功能是否知足业务需求。
• 性能测试：测试了常规的 QPS、Latency (Avg, TP90, TP99) 等指标。
• 异常测试：其实咱们作数据存储的同窗每每最关注的是各类异常故障的状况，性能却是其次，并且分布式存储相比单机存储更为复杂。因此咱们测试了各类机器/磁盘/网络故障，业务异常状况。更进一步的，咱们将这些异常状况随机组合，并在系统内触发，再验证系统的正确性。
• 预发布环境验证：在大规模上线以前，咱们会在相对不过重要的、实际业务上跑一段时间，收集一些问题和可优化的部分，包括运维上的调优等。

经过上面的测试咱们认为 TiKV 不管是从性能仍是系统安全性的角度，都能很好的知足要求，因而咱们在 TiKV 基础之上，实现了对象元数据管理系统 v2.0，以下图所示。

将 v1.0 中一堆复杂的数据库和逻辑结构用 TiKV 替代以后，整个系统变得很是简洁。

3、业务迁移

不少用户可能直接将 MySQL 迁移到 TiDB 上，这个迁移过程已经很是成熟，可是因为迁移到 TiKV 前人的经验比较少，因此咱们在迁移过程当中也作了不少探索性的工做。

1. 迁移方案

上图是咱们设计的迁移方案，首先线上的数据都必须双写，保证数据安全。第二，咱们将存量数据设置为只读以后迁移到 TiKV 中，同时迁移过程当中的增量数据直接写入 TiKV，天天将前一日的增量数据作静态化处理，而后与 MySQL 中的数据对比，验证数据正确性。另外，若是双写失败，会启用 MySQL backup。

下面详细介绍实际操做过程当中的相关细节。

2. 切换

在存量数据切换方面，咱们首先将存量数据静态化，简化迁移、数据对比、回滚的流程；在增量数据切换方面，首先将增量数据双写 TiKV & MySQL，而且保证出现异常状况时快速回滚至 MySQL，不影响线上的业务。值得一提的是，因为 TiKV 在测试环境下的验证结果很是好，因此咱们采用 TiKV 做为双写的 Primary。

整个切换 过程分为三个步骤：

• 存量数据切换到 TiKV，验证读。
• 增量数据切换到 TiKV，验证读写。
• 验证 TiKV 中的数据正确性以后，就下线 MySQL。

3. 验证

数据验证过程最大的困难在于增量数据的验证，由于增量数据是天天变化的，因此咱们双写了 MySQL 和 TiKV，而且天天将增量数据进行静态化处理，用 MySQL 中的记录来验证 TiKV 的数据是否可靠（没有出现数据丢失和错误），以下图所示。

由于同时双写 MySQL 和 TiKV 可能会出现一种状况是，写入 TiKV 就成功了，可是写入 MySQL 失败了，这两个写入不在同一个事务中，因此不能保证必定同时成功或者失败，尤为是在业务量比较大的状况下。对于这种不一致的状况，咱们会经过业务层的操做记录，来判断是因为业务层的问题致使的，仍是由 TiKV 致使的。

4、业务现状及后续优化工做

目前 TiKV 在京东云对象存储业务上是 Primary 数据库，计划 2019 年年末会把原数据库下线。总共部署的集群数量为 10+，生产环境单集群 QPS 峰值 4 万（读写 1:1），最大的单集群数据量 200+亿，共有 50 余万个 Region，咱们元数据管理业务对 Latency 要求比较高，目前 Latency 能保证在 10ms 左右。另外，咱们正在测试 TiKV 3.0，预计 2019 年第四季度可以上线。

针对目前的业务运行状况，咱们后续还将作一些优化工做。

第一点是灾备，目前咱们是在业务层作灾备，后续可能会直接在 TiKV 层作灾备，也很期待 TiKV 以后的版本中可以有这方面的功能。

第二点是集群规模优化，由于对象存储是存储密集型的业务，咱们但愿压缩硬件成本，好比能够用到 8T 、10T 的磁盘，或者用更廉价的磁盘，这点咱们后续可能 PingCAP 研发同窗们一块儿考虑怎么优化提高。

第三点是 Region 调度优化，目前 TiKV 的调度总体比较复杂，这对于存储密集型的业务来讲就比较麻烦，尤为是数据量特别大的状况下，咱们并不但愿有一丝的波动就把数据迁移到其余机器上。

本文整理自崔灿老师在 TiDB TechDay 2019 杭州站上的演讲。

推荐阅读
干货 | TiDB Operator实践
干货 | DRDS 与TiDB浅析

---