前言在《US3元数据革新（上）》中，咱们介绍了US3的新版本元数据服务UKV-Meta，UKV-Meta是基于咱们自研的分布式计算存储拆散的KV零碎UKV研发的对象存储元数据服务，上面咱们将介绍一下UKV及其相干组件。URocksDBI.简介URocksDB是UKV存储引擎, 是US3研发小组针对开源RocksDB定制化开发的Key-Value存储引擎。II.RocksDBLevelDB是由Google开源的，基于LSM Tree的单机KV数据库，其特点是高效，代码简洁而柔美。RocksDB则是Facebook基于LevelDB革新的，它在Level的根底上加了很多实用的性能，例如Column Family等，具体的差异大家能够Google，也能够理论体验一下，这里就不再赘述了。RocksDB目前曾经使用在许多海内外出名的我的项目中，例如TiKV，MyRocksDB，CrockRoachDB等。RocksDB应用上的毛病

RocksDB是通过WAL来保证数据持久性的，RocksDB先将数据写入磁盘上的WAL，再将数据写入内存中的Memtable中，当Memtable达到大小阈值（或者WAL的大小阈值），Memtable中的内容会被Flush成有序的SST文件长久化，WAL也会切换成新的WAL（代表旧的数据已被长久化，防止WAL过大）。当RocksDB呈现问题当机/重启后，能够通过重做WAL来使RocksDB内存中未长久化的数据恢复到之前的状态。然而这里存在两个问题:1、RocksDB读取WAL是线性读取的, 当为了读性能把Memtable设置的足够大时，WAL也可能变得很大（Flush频率降落），此时如果产生当机重启，RocksDB须要足够长的工夫来复原。2、如果机器硬盘呈现损坏，WAL文件自身被毁坏，那么就会呈现数据损坏。即便做了Raid，也须要很长时间来复原数据。因而RocksDB的可用性是个大问题。另外因为LSM架构，RocksDB的读性能也会存在问题。怎么解决？Share Nothing为了满足数据一致性这一根本要求，大部分的解决方案都是将一致性协定置于RocksDB之上，每份数据通过一致性协定提交到多个处于不同机器的RocksDB实例中，以保证数据的可靠性和服务的可用性。典型如TiKV:

TiKV应用3个RocksDB组成一个Group，存储同一份数据，实例与实例之间不共享任何资源（CPU、内存、存储），即典型的Share Nothing模式。一旦有一实例数据有损失，可通过另外的实例迁徙/同步日志，来做复原。这种模式解决了可用性问题，也有不错的扩展性。但也存在毛病：•目前CPU的老本偏高，是咱们在理论业务中重点关注的老本优化点之一。而RocksDB（LSM Tree架构）的一大问题就是写放大。每个RocksDB为了进步读性能、升高存储大小，都会进行不定期Compaction(将数据读出来从新Decode/Encode，再写入磁盘)，编解码自身会耗费大量的CPU资源。而这样的多份（个别3份）写入RocksDB，等于CPU耗费确定会放大3倍。并且写放大因为进步了写的次数，即进步SSD的擦写次数，会显著缩小SSD的寿命，进步零碎的老本。•这种架构计算与存储是耦合在一起的，无论是计算先达到瓶颈，还是存储先达到瓶颈，两种情况尽管不同，工夫点也不统一。但通常不论哪种状况都是加机器，因而就会存在不少节约。•不易扩大：计算和存储耦合模式下，存储扩大通常须要迁徙大量数据。存算拆散将数据存储于分布式文件系统中，由其保证数据的一致性和存储的扩容，而计算节点仅仅解决数据的写入和读取。

URocksDB应用自研的分布式存储服务Manul作为底层的存储，Manul具备数据高牢靠，服务高可用的个性, 领有主动容灾、扩容等性能。这样当主节点写入一份数据时，Manul会主动做三正本同步数据，而从节点也能很快同步到主节点做好的数据，无需再多做几次反复的Flush或者Compaction。当存储节点容量不够时，可独自退出新的存储节点，Manul可能主动均衡数据。当计算节点达到瓶颈时，URocksDB领有独特的热点决裂性能，在无需做数据迁徙的状况下即可疾速减少计算节点，升高热点压力。此时就可能更精细化的经营计算资源和存储资源，升高业务老本。URocksDB热备RocksDB是反对Read Only模式的，然而只是相似于读一个快照，并不能读取到主节点DB的最新数据。咱们实现了RocksDB Secondary Instance（以下简称RSI）模式，可能通过底层分布式存储系统实时的读到另一个RocksDB最新写入的数据，使得从节点不仅能与主节点共享一份长久化文件数据，还能放弃从节点内存数据紧紧追随主节点，提供读取能力，和疾速容灾能力。

RSI如何做到数据的同步？利用底层存储分布式的特点，无论在哪个节点，从节点都能看到与主节点统一的数据，因此能够由从节点定期Tail Read并回放主节点的WAL文件和Manifest文件至其内存中，以跟上主节点的内存中最近的数据。RSI容灾如果间接重启主节点，那么因为LSM架构的缺点，主节点必须回放所有WAL日志至内存中后，能力对外提供服务。然而只读的从节点在同步数据后，其Memtable中的数据应与主统一。因为从节点一直的Tail Read主节点写下的WAL日志，因而从节点只须要先Tail Read 主节点写入最新的WAL日志即可同步好数据。而后新建一个主节点对象，再将内存中的Memtable和VersionSet切过去即可。原生RocksDB在重启时，会先加载所有的WAL日志至内存中，再将内存中的Memtable全副Flush至Level 0文件。这样RocksDB就能取得一个“洁净”的Memtable，而后对外提供服务。然而如果Memtable很大很多，那么Flush将会占用很多的工夫。钻研了RocksDB的SwitchWAL的过程后，通过代码革新，把这一部分挪动到后盾线程去做了（即把加载的Memtable转为只读的Immemtable）。

当主节点挂掉时，从节点内存中即有最新的写入数据，所以从节点抢到ZK的主后，即可将本人从只读节点转为可写节点，同时因为从同步Manifest文件，从已有所有的数据文件信息（与之前的主是同一份），无需进行数据迁徙，因而可立即对外提供服务。

采纳此种优化后，咱们线上的节点容灾工夫大幅度降低，主从切换P99达到100ms内。UKV

UKV是UCloud优刻得自研的计算存储拆散的分布式KV存储系统。其存储底座为分布式对立存储Manul，Manul是具备主动数据均衡、异构介质存储、EC存储等性能的高性能、高可用、分布式存储服务。UKV提供了集群治理服务，疾速备份等惯例性能，还针对US3元数据服务设计了数据结构，使其在UCloud优刻得日常的业务场景下提供更优良的性能。UKV应用UCloud优刻得自研的、由开源RocksDB定制化的URocksDB作为计算节点，同时依靠Manul，实现了主从热备，热点节点疾速决裂等特色性能。热点决裂因为UKV采纳Range Sharding（因为对象存储有许多的列表服务，会有大量的范畴读申请，因为咱们采纳Range Sharding来满足此项需要），所以比拟容易呈现热点问题，同时咱们也须要集群的横向扩大能力，以保障集群服务能力，所以UCloud优刻得为UKV实现了热点决裂的性能。设计准则:1、服务可用性- 用户服务不可长时间进行2、数据完整性- 元数据完整性不容有误3、失败回滚解决- 有任何预期外状态能兜得住4、自动化- 自动检测热点节点做决裂，主动筛选闲暇机器节点做指标决裂流程首先Range信息是长久化在ConfigServer集群的。UKV启动时，如果它是Active节点，ConfigServer会给其下发Range。UKV会与ConfigServer放弃心跳，一直上传节点信息，包含容量、QPS、机器状态。ConfigServer依据其状态判断节点是否触发热点决裂，如果触发，则会抉择一个闲暇节点作为指标端。决裂次要分为四个阶段：1.SPLITTING_BEGINConfigServer发动SplitRequest2.HARDLINK_BEGINUKVRequest定期更新其硬链状态（向ConfigServer发送申请，如胜利顺便带上计算的Range）3.TARGET_OPENConfigServer向Target发动OpenRequest申请（Target Open但不启动Compaction）4.OPEN_COMPACTION_FILTERConfigServer应用心跳来让Source和Target开启Compaction Filter

咱们次要利用计算存储拆散的能力，利用硬链性能和RocksDB的Compaction个性，来保证数据不挪动，且能过滤非Range数据。决裂工夫

咱们单节点大小下限设置为256G，理论线上300ms以内就可实现决裂，配合上下层的重试，决裂过程中用户是齐全无感知的。数据迁徙

因为新老列表数据存储构造不统一（新的是字典序），老的是先目录再文件，所以还做了列表服务Proxy的兼容开发, 防止下层业务改变

以现有扩容形式，无缝退出UKV-Meta，放大影响范畴。

咱们研发了专用的Migration服务来为咱们的UKV-Meta进行迁徙，将存在于老架构的元数据迁徙至UKV-Meta，以便将老架构占用的机器下机，升高业务老本。Migration服务能够在不影响用户业务的状况下，平安的进行数据热迁徙，保证数据的一致性，同时还具备迁徙数据实时校验性能，避免迁徙过程中呈现问题。总结因为以后芯片、机柜等硬件资源价格昂扬，使得云计算公司对CPU资源、存储资源的应用提出了更高、更精细化的需要。计算存储耦合的形式在扩容集群、裁减CPU、存储资源时，不仅会引发数据的Reshuffle，还会耗费比拟大的网络带宽、以及CPU资源。通过拆散存储资源、计算资源，独立布局存储、计算的资源规格和容量，使得计算资源的扩容、缩容、开释，均能够比拟快的实现，并且不会带来额定的数据搬迁代价。存储、计算也能够更好的联合各自的特色，抉择更适宜本人的资源规格和设计。