京东云对象存储是在 2016 年做为公有云对外公开的,主要特色是可靠、安全、海量、低成本,应用于包括一些经常使用的业务场景,好比京东内部的京东商城视频/图片云存储,面向京东云公有云外部的开发者的服务,和面向政府、企业的私有云服务,甚至混合云服务。node
本文将介绍京东云对象存储服务的架构演进,以及迁移到 TiKV 的经验。数据库
首先举例说明一下这里的“对象 (Object)”概念。好比咱们把一张照片看成一个“对象”,除了照片自己的二进制数据,它还应该包含一些元信息(照片数据长度、上次修改时间等)、涉及用户的数据(拍摄者、拍摄设备数据等)。对象存储的特色是这些数据不会频繁地修改。安全
若是是数量比较少的图片存储,咱们可能会用相似 LVM 之类的东西,把一个节点上的多个磁盘使用起来,这种方法通常适用于数量级在 1M ~ 10M 的图片。随着业务的增加,图片会愈来愈多甚至有视频存储,所以咱们采用分布式文件系统来存储,这种方法是基于 DFS 的架构(以下图所示)。网络
这种方法的前提是单机容量受限,必须把数据放在多台机器上存储,而且用一个或多个独立的 node 存储元数据,而且元数据会维持树状目录的结构,拆分比较困难。可是这个架构通常适合存储到 10 亿级别的对象,同时存在两个比较大的问题:架构
那么若是要求作千亿级的对象存储,如何实现呢?最容易想到的办法是将元数据分布式存储,再也不像文件系统中那样存储在单独的机器上,是一个树状结构,而是变成一个平坦结构。运维
回到上面的举例,针对一个图片对象咱们主要有四类操做:上传(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 主要缘由有如下四点:
在上线以前,咱们主要进行了如下几方面的测试:
经过上面的测试咱们认为 TiKV 不管是从性能仍是系统安全性的角度,都能很好的知足要求,因而咱们在 TiKV 基础之上,实现了对象元数据管理系统 v2.0,以下图所示。
将 v1.0 中一堆复杂的数据库和逻辑结构用 TiKV 替代以后,整个系统变得很是简洁。
不少用户可能直接将 MySQL 迁移到 TiDB 上,这个迁移过程已经很是成熟,可是因为迁移到 TiKV 前人的经验比较少,因此咱们在迁移过程当中也作了不少探索性的工做。
1. 迁移方案
上图是咱们设计的迁移方案,首先线上的数据都必须双写,保证数据安全。第二,咱们将存量数据设置为只读以后迁移到 TiKV 中,同时迁移过程当中的增量数据直接写入 TiKV,天天将前一日的增量数据作静态化处理,而后与 MySQL 中的数据对比,验证数据正确性。另外,若是双写失败,会启用 MySQL backup。
下面详细介绍实际操做过程当中的相关细节。
2. 切换
在存量数据切换方面,咱们首先将存量数据静态化,简化迁移、数据对比、回滚的流程;在增量数据切换方面,首先将增量数据双写 TiKV & MySQL,而且保证出现异常状况时快速回滚至 MySQL,不影响线上的业务。值得一提的是,因为 TiKV 在测试环境下的验证结果很是好,因此咱们采用 TiKV 做为双写的 Primary。
整个切换 过程分为三个步骤:
3. 验证
数据验证过程最大的困难在于增量数据的验证,由于增量数据是天天变化的,因此咱们双写了 MySQL 和 TiKV,而且天天将增量数据进行静态化处理,用 MySQL 中的记录来验证 TiKV 的数据是否可靠(没有出现数据丢失和错误),以下图所示。
由于同时双写 MySQL 和 TiKV 可能会出现一种状况是,写入 TiKV 就成功了,可是写入 MySQL 失败了,这两个写入不在同一个事务中,因此不能保证必定同时成功或者失败,尤为是在业务量比较大的状况下。对于这种不一致的状况,咱们会经过业务层的操做记录,来判断是因为业务层的问题致使的,仍是由 TiKV 致使的。
目前 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浅析