Rockstable是滴滴内部自研的一套高性能分布式KV存储系统，其特点是支持列模式，支持高并发、低延迟、高可用，目前支撑了滴滴内部主要的特征实时存取需求，本次主要介绍其内部的实现原理。主要技术点：分布式kv存储、列式存储、高性能。

大家好，我是滴滴的盛克华，负责滴滴的后台的引擎相关的工作。今天给大家分享的是我们内部使用的KV存储系统，名字叫Rockstable。大概分成四部分，第一个是Rockstable的简介，第二个是用Rockstable系统解决什么样的问题，以及我们为什么要做这样的一套系统，第三个是这个系统目前在公司内部的使用情况，第四个是内部的实现方式，希望能给大家带来一些思路上的提示。演讲大纲如下：
Rockstable是一个分布式的KV存储系统，所以并非一个文件系统。Rockstable支持劣势，这个劣势是非固定的去做劣势的格式的规定，可以随意的加减。
Rockstable系统解决了滴滴后台各种时时特征的需求。这个是最原始的动力也是我们做这个系统的原始出发点。
多更新源;滴滴的业务，主要是做司机和订单的匹配，我们要存储司机每个维度的特征，订单每个维度的特征，以及乘客每个维度的特征，所以都在这里，并且很多特征和数据源都是时时变化更新的。有些数据是司机端上报的，有的是离线挖掘的，有的是业务系统时时写入的，所以数据源使用很多。
　　多使用方;Rockstable是一套非常基础的特征系统，所以依赖这个特征系统使用的业务也很多，最直接的是我们的派单系统。
　　高度稀疏;这个是很多业务场景都遇到同样的问题，批量读写，这个问题很严重，我们是每个时刻对大量的订单大量的司机做匹配的，所以同一时刻要读取大量的K，所以批量是主要的一个使用接口。
　　高并发、低延迟、高可用;这里对性能的要求尤其苛刻，高并发不用讲，低延迟也是非常敏感，如果延迟很直接导致我们分担的慢。
　我们现在的使用情况：访问量在早高峰或者是晚高峰的时候，读取的是大概两千万的KPS，K是一个司机或者是一个订单或者是一个乘客的维度，写入大概是五十万的KPS，所以访问量是非常巨大的。
　　我们希望存储司机很多维的特征，有一些维度在不断的调研，有一些维度特征是有用的，我们需要逐步的加进来，现在是百级别的样子，数据量是三副本，TB级的数据量，为了保证低延迟，存储主要是在内存和SSD里面。
这一张图主要是描绘了我们的总体架构设计。下面的大框是我们内部的实现，上面是我们的应用方，各个APP，这个APP不只是说客户端，是我们的上游的后台服务。蓝色框是接入层，所有的读写从这里接入，橙色框是存数据的地方，是很简单的二层结构，比较特殊的是有一个对立集群。右边有一个存取一些信息的，这个和用的分布式设计是比较类似的。
　　最左边有一个监控系统，右边有一个管理系统。左边虚线是队列集群，做故障处理的，你挂了一台机器，我们写入数据流会导入队列里面，等机器恢复的时候我们要从队列里面恢复数据。
这张图主要是实现概述，讲Rockstable系统有一些什么样的主动特性。
　　最终一致性;支持A副本，这个是根据我们的需求来的，很多系统是要强一致，我看到的大部分的互联网应用里最终一致性是够用了，所以我们采用的是最终一致性。
　　支持表、列结构;我们可以创建表或者是删除表，对不同的业务或者是不同的数据我们建不同的表。这个是列，这个列可以随意的加减，不需要做任何的操作，这样的话我们的业务会更灵活方便，想加一列就会可以加进去的，不用做另外的工作。
　　批量读批量写;也是最基本的。
　　支持TTL;就是我们的生命周期，他也有三个维度，第一个是表级别，这个是我的表设置一天数据只能绑定一天，设置一个小时就绑定一个小时，过期就自动删除，这个表是一天的或者是一个月的，你可以针对K设置一个小时或者是一天，这个K如果是绑定一天，对部分的列设置秒级别或者是分钟级别都可以，所以TTL设置是比较分布的，
　　白名单;出于稳定性的考虑，访问系统的来源有很多，各种各样的业务系统在读取数据，为了保证系统的稳定性做了严格的限制，读写限额，以及白名单的控制。
　　支持MC、THRIFT两种接口;我们以前在系统上线之前我们线上的业务是由MC做的，所以支持他是方便我们上线。THRIFT用的比较广泛的框架，这个用的比较多，所有的劣势操作，批量的读写都在这个接口里实现。
　　批量数据扫描、修复：因为MC的协议是比较简单的，可以支持批量的读，但是没有办法支持批量的写。支持批量数据扫描和数据修复，对数据的维护方而言是相当重要的，我需要知道上T的数据里有哪些错误的数据。
　　数据的持久化;有一些场合数据要求是很高的，有一些数据访问量低，但是他的数据量大，将这些放到磁盘上，这样的话可以利用存储空间支持数据持久化。
　　支持集群间的数据同步;这个也比较重要，但是相对而言用的少一点，我们可以把一个集群的数据时时的或者是手动的，自动导到另外一个集群上去，这样的话我们可以做集群的拷贝或者是做数据的同步。
下面讲集群的一个管理方式，我们集群有接近上千台的机器，这么多的数据，这么的并发在上面，如何管理集群?我们是开发了一些比较丰富的管理工具，最主要的是有一个命令行的管理入口，支持一些管理人的操作，比如说创建，删除，查看表。
数据模型每个表根据ID进行均匀的分片，每个分片存储三个副本，这样的话我们对一个数据有了一个基本的概念，就是一个表，一个复本一个分片，这样的一个TRP组织了一个最小的数据单元，他是一个最小的数据管理的一个模型，他里面包含一定量的KV。
自动平衡是以TRP的力度进行的，如果现在有一百台的机器的集群，我们扩二十台上去，如何扩数据的平衡，我们找到需要迁移的TRP，从原来的机器上每个挑一点TRP往空白的上面迁移，首先把原始的TRP停掉，停了一个以后另外的一个是正常工作的，把这个停了以后就会开始写队列。从原机器往目标机器拷这个数据，拷贝完以后在新的机器上把TRP起动起来，开始消费队列，把数据追平，然后开始访问新的TRP，所有的操作基本上是一个自动的过程。
作为一个时时的线上系统，特别是存储系统，他的稳定性是至关重要的，如果存储系统崩溃了所有的系统就崩溃了，所以我们做了大量的监控建设，基本上一个集群我们有二百多个监控曲线，这里面有非常详细的监控，错误统计，各个环节的耗时，以及集群的示例的统计一些使用情况，各种读写各种MC各种接口等等。
我们做系统最主要的目的是应付高性能的场景，他是需要特别的低延迟，我们最终做的延迟是这样，耗时差不多三个九，在五毫秒以内，性能是非常满意的。
NodeMgr是我们自己内部的一个动态结点管理的工具，这里主要是支持了一些故障的自动摘除与结点的恢复，我们的集群这个层面对外是上百个机器的IP，访问的时候经常会发生IP的故障或者是经常做一些扩容，如果上游不能应付这样的变化的话是非常被动。