滴滴从KV存储到NewSQL实战

0.导读

本文讲诉滴滴在分布式Nosql存储Fusion之上构建NewSQL的实践之路。详细描述Fusion-NewSQL的特性，应用场景，设计方案。

1.背景

Fusion-NewSQL是由滴滴自研的在分布式KV存储基础上构建的NewSQL存储系统。Fusion-NewSQ兼容了MySQL协议，支持二级索引功能，提供超大规模数据持久化存储和高性能读写。

▍我们的问题

滴滴的业务快速持续发展，数据量和请求量急剧增长，对存储系统等压力与日俱增。虽然分库分表在一定程度上可以解决数据量和请求增加的需求，但是由于滴滴多条业务线（快车，专车，两轮车等）的业务快速变化，数据库加字段加索引的需求非常频繁，分库分表方案对于频繁的Schema变更操作并不友好，会导致DBA任务繁重，变更周期长，并且对巨大的表操作还会对线上有一定影响。同时，分库分表方案对二级索引支持不友好或者根本不支持。鉴于上述情况，NewSQL数据库方案就成为我们解决业务问题的一个方向。

▍开源产品调研

最开始，我们调研了开源的分布式NewSQL方案：TIDB。虽然TIDB是非常优秀的NewSQL产品，但是对于我们的业务场景来说，TIDB并不是非常适合，原因如下：

我们需要一款高吞吐，低延迟的数据库解决方案，但是TIDB由于要满足事务，2pc方案天然无法满足低延迟（100ms以内的99rt，甚至50ms内的99rt）我们的多数业务，并不真正需要分布式事务，或者说可以通过其他补偿机制，绕过分布式事务。这是由于业务场景决定的。TIDB三副本的存储空间成本相对比较高。我们内部一些离线数据导入在线系统的场景，不能直接和TIDB打通。

基于以上原因，我们开启了自研符合自己业务需求的NewSQL之路。

▍我们的基础

我们并没有打算从0开发一个完备的NewSQL系统，而是在自研的分布式KV存储Fusion的基础上构建一个能满足我们业务场景的NewSQL。Fusion是采用了Codis架构，兼容Redis协议和数据结构，使用Rocksdb作为存储引擎的NoSQL数据库。Fusion在滴滴内部已经有几百个业务在使用，是滴滴主要的在线存储之一。

Fusion的架构图如下：

我们采用hash分片的方式来做数据sharding。从上往下看，用户通过Redis协议的客户端就可以访问Fusion，用户的访问请求发到proxy，再由proxy 转发数据到后端 Fusion 的数据节点。proxy 到后端数据节点的转发，是根据请求的key计算hash值，然后对slot分片数取余，得到一个固定的slotid，每个slotid会固定的映射到一个存储节点，以此解决数据路由问题。

有了一个高并发，低延迟，大容量的存储层后，我们要做的就是在之上构建MySQL协议以及二级索引。那么如何将MySQL的数据格式转成Redis的数据结构存储就是我们必须面临的问题，后面会详细说。

2.需求