共计 4200 个字符，预计需要花费 11 分钟才能阅读完成。
前言在《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 资源。通过拆散存储资源、计算资源，独立布局存储、计算的资源规格和容量，使得计算资源的扩容、缩容、开释，均能够比拟快的实现，并且不会带来额定的数据搬迁代价。存储、计算也能够更好的联合各自的特色，抉择更适宜本人的资源规格和设计。