【IT168 技术】本文根据丁俊老师于第十届中国系统架构师大会(SACC 2018)的现场演讲《JD K-V存储产品演化之路》内容整理而成。
讲师介绍：
丁俊，京东商城在线存储部负责人，主要负责分布式存储系统、分布式消息系统、分布式服务框架等产品的开发和维护。
正文：
大家好，我今天讲的题目是京东KV存储产品的演进之路。我不会具体讲每一个产品是怎么做的，而是重点去讲我们在开发中碰到的一些问题，以及我们是怎么解决的。当然这些问题的解决方法不一定最优，也不一定完全适合大家。大家可以共同探讨，作为一种解决思路。
我今天主要讲三个部分，一个部分是内存存储(jimdb)，另一块是持久化存储(sharkstore)，还有一块就是我们目前想要做的混合存储。
内存针对的是一个高吞吐、低延迟的场景;持续化存储更强调的是可靠性和容量上面。我们后面想做一些混合存储，主要是因为在业务发展过程中有很多数据慢慢从内存里面沉淀下来，可能不常使用，而因为业务、成本等各方面的考虑，没有将其从内存中挪出来，我们就想能不能通过平台统一把这些事情处理一下。
下面我大概介绍一下我们各个产品的时间节点。2014年我们内存存储产品的第一个版本上线，当时是公司内部有各种各样的一些开源产品的使用，每个小组也有自己的维护系统，包括开发一些管理界面，维护工具等等，公司决定把它统一起来，由一个独立的团队去提供这样一个产品。
2014年上线以后，业务量增长比较大，在2015年的时候，我们就面临了一些新的挑战。随着业务数据的增长，比如在内存里面，有一些业务数据可能今年的增长量是前面所有年份的总和，甚至还要多。2015年数据的扩容，包括我们服务的产品越来越多，搭建的集群越来越多，它的故障恢复能力都给我们带来了一些挑战。第二个版本重点解决这些问题。
2017年，我们有了异地的机房，就需要支持中间件的异地多活。现在的这个产品，我们也做了异地多活的解决方案。2018年内存方面的大部分事情，主要的矛盾解决差不多了，我们就做了持久化的存储，去解决一些成本上的问题，包括和一些厂商去探索新的存储，比如这个介质是不是可以节省一些内存，从降低成本上去进行一个考量。2018年当我们的存储系统上线以后，就在这个基础上，为一些业务提供了分布式锁，包括配置分发的功能。再后面就是我们正在研发中的一个事情，希望能够把混合存储提上去。
内存存储的实践与挑战
现在讲第一部分，内存存储。这里先讲运营数据，当然不是为了说明这个系统有多复杂，其实系统不是特别复杂，主要是我觉得一个系统碰到的主要问题和解决问题的思路，可能是随着系统的数据量访问压力来的，所以说大家在挑选方案的时候，还是要结合自己的业务特点，从成本、实现的难度，维护人员的数量、紧急度等等一些方面去考量。平常我们整个平台大概每秒钟可能有上亿次的访问，内存的进程数大概在10万级以上。
下图是我们内存存储的架构图。
该架构的主要特点包括：高吞吐、低延迟，能够自动故障恢复，可以在线伸缩，能够进行广域复制等等。
下面我主要讲一下故障检测。说到故障检测，大家在部署的系统当中其实都会面临这个问题，都需要容灾，对硬件、网络的故障等进行检测，让你的业务避免受到这些故障的影响，提升可用率。我们在做故障检测的时候，如果说我本来就没几个实例，可能就是部署一个哨兵，或者有一些别的方案去探测。检测一个服务是否存活，可能常用这几种方法：一种是主动探测，另一块就是由本身提供服务的人，去上报它的状态是不是好的。
如果故障检测没有做好，会有什么问题?其实如果说你是一个没有状态的服务，探测错了也不会引起太多的问题，最多可能就是导致性能的偶尔波动。作为一个有状态的服务，如果检测错了，很可能导致的后果就是，可能你的数据会写丢。比如说你检测到一个master，它是一个写入点，你认为它是故障的，有一部分节点还在往这个节点上写入，另一部分节点认为它故障以后，可能会选出一个新的写入点。如果你的业务同时往两个写入点进行写入，势必就会导致数据丢失。
导致这种检测误判的主要原因有哪些呢?目前我们主要面临的一些问题，一个就是网络的分割——当然如果部署的节点比较少，本身可能就这一个网络、一个机架里面或者一台交换机下面，这种故障的可能性会小一些。但是当你的服务部署在整个机房的各个角落，包括甚至可能在同城的多个机房里面，这种网络的故障出现的概率就会大很多。另外其实我们还碰到一个问题，就是一个长任务的执行导致系统阻塞，探测的时候，可能会探测到它不是存活的，因为它没有在一定的时间内给你一个响应。比如说你认为多少秒以后它就“死亡”了，如果说任务执行的时间超过这个时间，你也可能会认为它是死亡的。
大家可以认为一个长期阻塞的任务是“死的”，当然也可以认为它是“活的”——因为本身进程还在，这个要看你的业务特点。但是我们认为，这种场景尽量不要把它“判死”，为什么?我们发现往往你把它“判死”、“杀掉”、在别的地方恢复起来以后，业务往往还会执行相同的事情。相当于不停地“杀掉”-起来、“杀掉”-起来，进入这样一个恶性循环中。
对于这些问题，我们主要有这几种解决办法。第一个，我们把探测点部署在机房的各个角落里，分布在不同的机架和交换机下面，他们组成一组探测服务，共同去投票决定这个服务是“死亡”的、还是存活状态。这是一点，解决网络的问题。第二就是，对于任务阻塞的情况，我们是在服务器上面部署一个agent，因为本身服务器上有agent去做一些指标采集等，也会做一个判断进程是否存在的服务，结合这两点去防止误判。
下面说一下故障的自动恢复。恢复其实很简单，就是你探测到它不存活以后，可能通过一系列的手段，比如说slave“死了”，副本“死掉”以后，再加一个副本就可以了。如果说你的写入节点master“死掉”了，从现有的副本里面、slave上面去提升一个，提升为master就可以了。我觉得在做业务系统的时候，为了提升使用率不一定要完全去依赖这种探测的服务，你还应该有一些别的手段，在客户端可以做一些容错的策略，比如说如果你是读写分离的，那能不能够在slave“死掉”以后自动去读一下master，恢复以后再去读slave。比如说，如果我在同城有别的机房，有两个对等的集群，那我能不能在这一个集群访问不了的时候，业务客户端去访问另一个集群。在这种规模比较小的时候，可能大家实际开发成本都是相对比较低的。
还有一个问题就是，是不是所有的故障都一定要去恢复。这个场景其实不太经常碰到，但是如果碰到了，确实需要注意一下。因为我这么多年做这种服务，偶尔也有碰到过那么一两次。就是说我发现一个大面积的故障，比如探测到某一个机房断电了，那要不要去做故障恢复?也许这种场景下去做故障恢复带来的后果可能更大，可能你还没有完全把数据都自动恢复好的时候，机房可能已经帮你把电也已经通上了。而在自动恢复时，会占用大量内部网络的流量，对现有业务产生影响。所以在这里我主要想提一句，有一些场景可能需要你去做一个系统的决策，做一个智能的判断，但有时也不一定要做的这么复杂，如果系统简单，那做一个开关就好了。
下面说一下迁移的过程。当系统的数据量越来越大时，原来分配的空间可能不够了，需要扩容，系统需要升级，这时你也需要做数据迁移，因为数据在内存里面，没有办法进行原地升级。我们知道在数据迁移中，通常第一步可能就做一个快照，做完快照以后再补增量。在这里要提一句，就是说我们在补增量当中，实现完第一版以后，发现系统有时会卡顿一段时间。因为首先每个业务写入的流量大小不一样，有的业务可能刚好碰到写入量比较大的那段时间，你会发现增量的数据比较多，这个时候就可能阻塞住。
在线迁移流程图
为了保证前后、新旧服务的数据一致性，你可能需要把老的写入给停了。后面发现一个业务特点就是，读比较多一些。我们可以把读给放开，让它在迁移的过程当中，只阻止写——也就是变化的地方。
下面说一下内存存储的广域复制的问题。我可能在华东、华北有两个机房，我的服务部署在华北，有一个master，也有一个slave。现在我可能需要在华东也提供一个服务，常用的就是把一个数据复制过去就可以了。这里有一个前提，因为它是在内存里面，所有的数据都在内存里面，我能不能够直接在华东挂一个副本到我的master去。
个人认为在业务量比较小、数据比较少的时候，这种方案是可以的。但是大家都知道，广域网络上面可能网络延迟比较高，网络的质量比较差一些。这就带来一个问题，可能会有中断。那我要缓存的、要同步的数据，可能在内存里面会积攒比较长的一段。这样，当我数据量比较少的时候，能不能把缓冲区直接调大，就可以缓存更多的增量数据，避免这种存量。不过平台、服务的集群很多的时候，如果把每一个实例内存都调大，可能浪费的资源就比较大了。
我们采用的方案如下图，在华北新建一个同步的模块去模拟slave，把master的数据同步下来，保存在本地的机房，再把数据发送给华东的集群。这里我们会有两个master，意味着就可以接受两个地方写入，目前我们线上也有这样的一些服务在跑。比如，大部分是华北作为一个主要的集群进行写入，华东是不接受写的，只有读，但也有一些业务可能需要在两地同时多写，我们也提供在华东接受写入。
这里可能会面临一个问题，就是华北写入的key复制到了华东，如果华东也要往回复制的话，同一个key是不是就在这里“转圈”?其实我们在key里面打了一个标，它从哪个地方写入就打哪里的标，当sync服务在复制这些数据的时候，会跳过这些key，这样就实现了两个集群之间的相互复制。当然这里也有一个问题是没有解决的，需要业务去解决，比如说华东和华北同时写同一个key，这可能就面临一些问题。第一，复制是延迟的，第二就是一致性等问题。我们这里其实没有去解决，还是靠上层的业务去规避。就是说在华东写入的key不会在华北写入，华北写入的key不会在华东写入。或者业务上能够接受这种混写，就是说以谁为准都可以。
持久化存储的实践与挑战
下面讲一下持久化存储。其实持久化的KV存储其实有很多开源的实现，大家的一些实现思路也都大同小异。我们也一样，选用了一些常用的开源组件，在这基础之上进行开发。自己开发这个系统的原因，一方面是为了更好地和内存存储的API等等兼容，还有一些自己的业务特性在里面。
持久化存储的特点包括：1、分布式强一致;2、支持在线分裂、自动故障恢复;3、支持schema，海量数据;4、支持范围查询，单表操作。
下图是持久化存储的逻辑视图，其实KV的存储里面，大家的key和value不一定是列的，那我们选用这样一种方案，一方面为了方便，比如说后面我们要兼容MySQL的协议，还有就是从我们自己的业务特点来看，目前这种跟MySQL一样的这种结构可能对我们来说已经能够满足需求。相对来讲，我觉得这种方案可能还有一定的灵活性，也有一定的约束，比较折中一点。然后key是可以由多列去组成的。
下图是持久化存储的结构图，其实这种持久化存储，包括对象存储等等，大家的结构可能都差不多，有一个接入层，有一个master去管理元数据，有保存数据的地方。
这里可能需要介绍一下，我们的data servers是基于rocksdb去实现的。其实大家上网去查这种持久化存储，可能首屈一指的就是rocksdb，它各方面性能，写、读都非常优秀，所以我们也选择了这么一种方案。但后面我们在一个场景上测试的时候就碰到了一个问题，主要是rocksdb compact带来的影响。这里我简单介绍一下compact产生的原因，对于rocksdb来讲，它就是一个基于日志结构的合并树。假设我的左手边是一棵无序写入的、按写入顺序进行保存的树，而我的右手边是一颗有序的树，然后不停地把无序写入的数据往右手这边的有序树上去合并。一个是为了保证读的性能，另外一块就是说它有一个特点，比如我的删除，其实在无序的树里面去写入一个Key，做一个标记它是删除的，并没有真正在我的右手边有序的树里面去删除，只是打了个标，然后通过后台的GC把这些数据给清理掉。基于这两点，它需要不停地把无序的树和有序的树进行一个文件的合并，合并的动作就是从无序的树里面挑一个文件，看Key的分布，在有序的树里面也挑选相同或者一定跨度范围内的Key的一个文件进行合并。
另一块就是说因为每一层数据不能够保证Key写得太大，它会一层一层往下写，下面的虽然说每一层不是有序的，为了查找的效率，包括GC掉一些删除的Key等等，它会往下进行合并，每一层也会合并。这里面其实大家就看到一个问题，比如说我有一个Key，从写入以后就再也没有改变过，也没有删除，在这个过程当中，可能我就会被来回搬运很多次，被写入很多次，这就导致了一个写的放大。大概就是这么一个流程。
我们会发现在一段时间内，当我一个rocksdb的进程、数据量在100多近200G左右的时候，它其实性能还维持的比较好(这里提一下，我们使用的是基于NVMe的SSD)。当它超过一定的量以后，你会发现写入的性能就有一些“尖刺”了，有的可能就直接掉到0。作为一个在线服务来讲，这种问题是我们无法接受的。举个例子，大家作为消费者，可能都不希望在大促销、“秒杀”的那一刻，服务如果出现延迟，那么可能促销的时间点已经过去了。当然如果是一个离线服务，我觉得是可以接受这种短暂波动的。
下面是系统长时间跑的一个图，大家可以看到，越到后面波动就越大。
针对这个问题，我们目前采用了一个Key-value分离的方案。我们是基于rocksdb里面blobdb功能的完善和改造。这里简单介绍一下Key-value分离是怎么实现的，就是说我有一个Key写进来以后，还是和原来一样保存到rocksdb这一套结构里面，同时我把我的value写在一个顺序追加的文件当中，然后把这个顺序追加的文件的位置，比如文件编号、基于这个文件的偏移量等等，把它写在一个索引里面，把索引信息和Key保存在一起，索引信息作为一个原来Key对应的value保存起来，相当于中间加了一层。这样做的一个好处就是说我在做一个有序整理的时候，就是排序合并的时候，不用先去搬弄我的value。
其实这里面也隐藏了一个问题，就是说它并没有解决所有的场景，可能只对Key-value比例比较大的场景比较合适。比如说key可能就几十个字节，而value可能上千或更大，这种场景其实是非常合适的。如果value本身就比较小，可能几十个字节，和key差不多，还多出个索引来，其实这种场景也是解决不了的。
然后，如果说你的比例能达到一比几十的话，你一块盘几个T的容量，内存里面保留几百G的key的数据，也许就能够很好的去解决这个问题。包括你这对一台物理机进行多个实例的部署，也可以缓解这些问题。当然业界也有一些别的探讨，比如说结合SSD磁盘的一些特性，SSD磁盘本身也会在后台做一个GC，也许就可以和rocksdb的GC合并起来。
下面就是我们改动以后业务测试的一个性能表现，相对来讲就比原来平滑很多。
讲完存储那一块碰到的问题以后，下面就说一下raft成员变更。因为我们的数据，包括云数据、业务数据和元数据都是基于raft复制的，它可以在线扩容，也可以进行一些故障恢复，势必就会涉及raft成员的变更。当你在做数据迁移负载均衡的时候，成员就需要变更。比如说一个磁盘快满了，我需要把一个副本从A机器搬到B机器去，我们的做法就是在B机器上面加一个节点，加上以后再把A机器上的副本删掉。
这里面就碰到一个问题，如果这个时候刚好A机器有故障，你就会发现raft就没办法正常工作了，因为它现在的成员是四个，新加入的成员和有故障A镜像的副本同时不能工作，这个时候其实你是有两个节点是坏的，两个节点是好的，它没有办法保证大多数的成功。
大家可能就问，那我能不能先把A机器上的节点删了，让我的成员从三个变成两个，然后再把一个别的节点加进来，是不是就能解决这个问题?其实在一定程度上是能缓解这个问题，但这里面可能也会碰到新的问题，就是说当你刚好把A镜像的副本给删掉以后，三个节点删了一个还有两个，如果再有个节点出现故障的话，你整个数据可能都没有办法自己去恢复了，你就需要强行去干预它，这可能就涉及数据的一个安全。
那么我们现有的方案是怎么解决这个问题的?其实我们大概思路就是，首先让新增的raft成员只复制数据，不参与到投票里面，同时也不会发起Leader选举，让它作为一个“学习节点”。当这一个新增的节点复制完数据以后，我的Leader会知道它复制到哪了，就认为它已经跟上进度了，再把它提交到成员里面去，同时把另一个节点删掉，这样就能够保证这个工作比较顺利地进行。如果这个时候即使有一个新的节点有故障的话，也能保证有两个节点在。
这里提到其实它有个特点，就是新增一个成员的时候，是会重新发起Leader选举的。还有一个就是，如果我这个节点(follower)数据落后了很多，断开网络以后重新加进来，也会发起一次Leader的选举。那Leader的这种选举、切换，其实是需要时间的，对性能会有干扰。
当然raft的作者也有提到怎么解决这些问题。就是新增的节点加进raft组以后，先询问一下，跟现实中的选举一样，你在正式选举之前，可能需要去各个社区拜个票，后面真的选举了，让人家选你。它也一样，就是说加进来以后，先不发起Leader选举，而是先去拜个票，跟每一个成员沟通一下，能不能给我一个机会当Leader。如果大多数的人反馈你可以，那就进行选举。如果说现有的Leader挺好的，我不能让你当，或者是说你的数据落后于我，你不会成为Leader，那就没必要再发起leader选举了。作者提出了Pre-Candidate算法，在发起之前就先进行一次预选举。如果预选举时能得到大多数的投票，再增加term，进行正常的选举。这样就是大大的降低了因为一些网络，包括数据的迁移平衡等因素导致的性能波动。
前面有提到，我们在持久化化存储的基础之上实现了分布式锁和配置服务。企业当中或多或少都有这种需求，最初如果说Redis/Memcached没有升级之前，可能更多基于数据库去做;或者说我的场景比较简单，就基于数据库去做。我在做一个任务的时候，先把这个任务打个标，在数据库里面标识这个任务是分配状态或执行状态。你做完任务后，你可能就去把它解锁，把任务标识为执行完成，打上标的数据不会被别的服务抢到。
这里其实可能就带来一个问题，假设打上标以后你的服务就挂了，谁来解?可能你会引入比如超时时间，一个定时的服务，去检测这些长时间在执行中的任务，将其解锁，让它重新可以交给别人去执行。另一种方案就是基于Redis/Memcached这种服务，如果你只部署了一个节点，我们知道进入Redis/Memcached都是异步的复制，如果你的锁服务加上以后刚好碰到了你的master“死”掉了，这把锁是不是意味着就丢失了?redis作者提出了redlock算法，通过去多个redis里面同时写个锁，类似于这种分布式的协商一样。这里面其实有一个问题是什么?如果说写入以后，你的服务“死”了，可能你就需要根据你的业务给它设一个超时时间。对大部分的业务来讲，其实我觉得是能满足的。当然一些比较严格的服务里面，可能会面临一个问题，就是我们这个时间设多长合适?如果你设的时间不是很合适，可能到这个时间以后，服务还没有执行完就过期了。
分布式锁流程
另外一种就是基于Etcd/zk的方案，它有心跳机制。这里面有一个场景，就是网络中断以后，临时节点不存在了，但是服务本身还在跑，那么它要不要中断?因为你没有终止的话，还是有可能发生重复执行的现象。这里我们提供了一些业务可选的方案，根据场景去配置。比如，我们可以是合理的超时时间+心跳机制，让这个时间可以续期，如果服务没有“死”，还在执行，就可以加时间;还有一个就是分布安全超时时间+报警检测，设比较长的时间，我发现一段时间以后没有执行完，就给那个业务去报警;还有一种就是心跳过期+回调，是保证你的任务是能够取消掉的。
然后是配置服务，基于刚才讲的，我们KV存储是多range的，一台服务器、一个进程有多个range服务，意味着它是多点的写入。在range分裂的时候，树型结构的深度是有限制的，防止分离时group分组被割裂。
混合存储的实践与挑战
下面给讲一下混合存储。我们希望能做到冷、温、热的三层存储，冷数据保存在持久化急群众。其中冷和温数据在同一个进程里面去解决，这可能就涉及到一个Key的淘汰问题，将不常访问的数据淘汰到磁盘。淘汰有很多种算法，比如LRU、HIT DENSITY等等，这时又面临一个问题，Key要不要从内存里删除?其实内存本身就是需要低延迟的场景，这里面又关联到第二个问题，如果Key删掉以后，在访问Key的时候需要去磁盘访问，这样会不会阻塞掉内存访问的其他客户端的请求，拖慢整体性能?还有一个问题就是，内存里面可能有一些大的数据结构，要不要把它淘汰到磁盘上去?淘汰以后可能就意味着一些功能的阉割，作为一个平台，可能有些功能没有办法阉割的，需要进行一个取舍。
我们目前的做法是，作为一个冷数据，是采用异步去访问的(如下图)。比如说我有A、B、C三个客户端，A客户端访问到的是一个冷数据，key保存在内存里打个标，然后它需要访问磁盘，我们暂时把这个请求再丢给一个队列，把这一个CPU线程给释放出来，去处理别的客户端的请求。如果在我们以前其实没有按这种方式，就会导致就是说我访问磁盘，比如说要50毫秒，可能整个后面的任务都被阻塞50毫秒。
下图这是一个冷热分离的访问流程，没有太复杂的事情。
还有一个就是混合存储，如下，这一块我们还在实践当中。
今天我大概就讲了这三部分的内容，内存存储、持久化存储和混合存储，希望能够给大家带来一些共鸣，谢谢。
