字节跳动自研强一致在线 KV &表格存储实践 - 上篇

本文选自“字节跳动基础架构实践”系列文章。

“字节跳动基础架构实践”系列文章是由字节跳动基础架构部门各技术团队及专家倾力打造的技术干货内容，和大家分享团队在基础架构发展和演进过程中的实践经验与教训，与各位技术同学一起交流成长。

自从 Google 发布 Spanner 论文后，国内外相继推出相关数据库产品或服务来解决数据库的可扩展问题。字节跳动在面对海量数据存储需求时，也采用了相关技术方案。本次分享将介绍我们在构建此类系统中碰到的问题，解决方案以及技术演进。

由于篇幅受限，本系列文章分为上下两篇，上篇会涵盖整体结构，接口和一部分关键技术，下篇会涵盖另一部分关键技术和表格层相关内容。下篇会在明天更新，欢迎大家持续关注。

背景

互联网产品中存在很多种类的数据，不同种类的数据对于存储系统的一致性，可用性，扩展性的要求是不同的。比如，金融、账号相关的数据对一致性要求比较高，社交类数据例如点赞对可用性要求比较高。还有一些大规模元数据存储场景，例如对象存储的索引层数据，对一致性，扩展性和可用性要求都比较高，这就需要底层存储系统在能够保证数据强一致的同时，也具有良好的扩展性。在数据模型上，有些数据比如关系，KV 模型足够用；有些数据比如钱包、账号可能又需要更丰富的数据模型，比如表格。

分布式存储系统对数据分区一般有两种方式：Hash 分区和 Range 分区。Hash 分区对每条数据算一个哈希值，映射到一个逻辑分区上，然后通过另外一层映射将逻辑分区映射到具体的机器上，很多数据库中间件、缓存中间件都是这样做的。这种方式的优点是数据写入一般不会出现热点，缺点是原本连续的数据经过 Hash 后散落在不同的分区上变成了无序的，那么，如果需要扫描一个范围的数据，需要把所有的分区都扫描一遍。

相比而言，Range 分区对数据进行范围分区，连续的数据是存储在一起的，可以按需对相邻的分区进行合并，或者中间切一刀将一个分区一分为二。业界典型的系统像 HBase。这种分区方式的缺点是一、对于追加写处理不友好，因为请求都会打到最后一个分片，使得最后一个分片成为瓶颈。优点是更容易处理热点问题，当一个分区过热的时候，可以切分开，迁移到其他的空闲机器上。

从实际业务使用的角度来说，提供数据强一致性能够大大减小业务的负担。另外 Range 分区能够支持更丰富的访问模式，使用起来更加灵活。基于这些考虑，我们使用 C++ 自研了一套基于 Range 分区的强一致 KV 存储系统 ByteKV，并在其上封装一层表格接口以提供更为丰富的数据模型。

架构介绍

系统组件

整个系统主要分为 5 个组件：SQLProxy, KVProxy, KVClient, KVMaster 和 PartitionServer。其中，SQLProxy 用于接入 SQL 请求，KVProxy 用于接入 KV 请求，他们都通过 KVClient 来访问集群。KVClient 负责和 KVMaster、PartitionServer 交互，KVClient 从 KVMaster 获取全局时间戳和副本位置等信息，然后访问相应的 PartitionServer 进行数据读写。PartitionServer 负责存储用户数据，KVMaster 负责将整个集群的数据在 PartitionServer 之间调度。

集群中数据会按照 range 切分为很多 Partition，每个 Partition 有多个副本，副本之间通过 Raft 来保证一致性。这些副本分布在所有的 PartitionServer 中，每个 PartitionServer 会存储多个 Partition 的副本，KVMaster 负责把所有副本均匀的放置在各个 PartitionServer 中。各个 PartitionServer 会定期汇报自身存储的副本的信息给 KVMaster，从而 KVMaster 有全局的副本位置信息。Proxy 接到 SDK 请求后，会访问 KVMaster 拿到副本位置信息，然后将请求路由到具体的 PartitionServer，同时 Proxy 会缓存一部分副本位置信息以便于后续快速访问。由于副本会在 PartitionServer 之间调度，故 Proxy 缓存的信息可能是过期的，这时当 PartitionServer 给 Proxy 回应副本位置已经变更后，Proxy 会重新向 KVMaster 请求副本位置信息。

分层结构

如上图所示是 ByteKV 的分层结构。

接口层对用户提供 KV SDK 和 SQL SDK，其中 KV SD