TiKV

作者：夏锐航 本文由逊馁队的成员夏锐航同学主笔，介绍 Unified Thread Pool 项目的设计与实现过程。该项目实现了在 TiKV 中使用一个统一的自适应线程池处理读请求，能够显著提升性能，并可预测性地限制大查询对小请求的干扰，最终在 TiDB Hackathon 2019 中斩获一等奖。 距离 TiDB Hackathon 落幕已经过去了半个多月，回忆这次比赛、获奖的经历，依然让我感到非常兴奋。我目前是华南理工大学大三的学生，我和正在 PingCAP 实习的学长奕霖一起组队参加了这次 TiDB Hackathon，比赛的主题为 “Improve”，即提升 TiDB 及相关项目的性能、易用性等。我们项目设计的切入点是： TiKV 现有的线程池在大小查询混合场景下的表现不太优秀。 需要针对不同的环境、场景配置线程池数量，使用和学习成本较高。 于是我和奕霖尝试为 TiKV 重新实现一个线程池来解决这个问题，以达到 Improve 整体表现的效果。除了优化读请求的线程池外，我们计划将这个线程池来代替 TiKV 中其他线程池，最后就产生了我们本次的参赛作品 Unified Thread Pool。 项目设计 在 TiKV 现行的线程池方案中有 Coprocessor、Storage 和 Scheduler 三套线程池。这些线程池原本是设计来分隔不同的任务，减少它们之间的相互影响

作者：Breezewish 本文为 TiKV 源码解析系列的第三篇，继续为大家介绍 TiKV 依赖的周边库 rust-prometheus ，本篇主要介绍基础知识以及最基本的几个指标的内部工作机制，下篇会介绍一些高级功能的实现原理。 rust-prometheus 是监控系统 Prometheus 的 Rust 客户端库，由 TiKV 团队实现。TiKV 使用 rust-prometheus 收集各种指标（metric）到 Prometheus 中，从而后续能再利用 Grafana 等可视化工具将其展示出来作为仪表盘监控面板。这些监控指标对于了解 TiKV 当前或历史的状态具有非常关键的作用。TiKV 提供了丰富的监控指标数据，并且代码中也到处穿插了监控指标的收集片段，因此了解 rust-prometheus 很有必要。 感兴趣的小伙伴还可以观看我司同学在 FOSDEM 2019 会议上关于 rust-prometheus 的 技术分享 。 基础知识 指标类别 Prometheus 支持四种指标：Counter、Gauge、Histogram、Summary。 rust-prometheus 库目前还只实现了前三种。TiKV 大部分指标都是 Counter 和 Histogram，少部分是 Gauge。 Counter Counter 是最简单、常用的指标，适用于各种计数

作者：屈鹏 本文为 TiKV 源码解析系列的第二篇，按照计划首先将为大家介绍 TiKV 依赖的周边库 raft-rs 。raft-rs 是 Raft 算法的 Rust 语言实现。Raft 是分布式领域中应用非常广泛的一种共识算法，相比于此类算法的鼻祖 Paxos，具有更简单、更容易理解和实现的特点。 分布式系统的共识算法会将数据的写入复制到多个副本，从而在网络隔离或节点失败的时候仍然提供可用性。具体到 Raft 算法中，发起一个读写请求称为一次 proposal。本文将以 raft-rs 的公共 API 作为切入点，介绍一般 proposal 过程的实现原理，让用户可以深刻理解并掌握 raft-rs API 的使用， 以便用户开发自己的分布式应用，或者优化、定制 TiKV。 文中引用的代码片段的完整实现可以参见 raft-rs 仓库中的 source-code 分支。 Public API 简述 仓库中的 examples/five_mem_node/main.rs 文件是一个包含了主要 API 用法的简单示例。它创建了一个 5 节点的 Raft 系统，并进行了 100 个 proposal 的请求和提交。经过进一步精简之后，主要的类型封装和运行逻辑如下： struct Node { // 持有一个 RawNode 实例 raft_group: Option<RawNode

概述 本文档主要面向 TiKV 社区开发者，主要介绍 TiKV 的系统架构，源码结构，流程解析。目的是使得开发者阅读文档之后，能对 TiKV 项目有一个初步了解，更好的参与进入 TiKV 的开发中。 需要注意，TiKV 使用 Rust 语言编写，用户需要对 Rust 语言有一个大概的了解。另外，本文档并不会涉及到 TiKV 中心控制服务 Placement Driver(PD) 的详细介绍，但是会说明一些重要流程 TiKV 是如何与 PD 交互的。 TiKV 是一个分布式的 KV 系统，它采用 Raft 协议保证数据的强一致性，同时使用 MVCC + 2PC 的方式实现了分布式事务的支持。 架构 TiKV 的整体架构比较简单，如下： Placement Driver : Placement Driver (PD) 负责整个集群的管理调度。 Node : Node 可以认为是一个实际的物理机器，每个 Node 负责一个或者多个 Store。 Store : Store 使用 RocksDB 进行实际的数据存储，通常一个 Store 对应一块硬盘。 Region : Region 是数据移动的最小单元，对应的是 Store 里面一块实际的数据区间。每个 Region 会有多个副本（replica），每个副本位于不同的 Store ，而这些副本组成了一个 Raft group。 Raft

众所周知，在对可用性要求极高的行业领域（比如金融、通信），分布式数据库需要跨地域的在多个数据中心之间建立容灾以及多活的系统架构，同时需要保持数据完整可用。但这种方式同时也带来了一些问题： 跨地域的网络延迟非常高，通常在几十毫秒左右，洲际间更能达到几百毫秒。 跨地域的网络专线带宽昂贵、有限，且难于扩展。 在今年 TiDB Hackathon 的比赛过程中，我们针对以上问题做了一些有趣的事情，并获得如下优化成果： 跨地域 SQL 查询，延迟下降 50%（图 1）。 跨节点消息数减半，即网络流量减半（图 2）。 <center>图 1 延迟对比</center> <center>图 2 网络流量对比</center> “Google Spanner 高性能事务和强一致特性（跨区域甚至跨洲），是每一个做多数据中心架构设计的工程师心中所向往的目标。虽然当前 TiDB 在多数据中心部署时的表现同 Google Spanner 还有明显的差距，但我们很高兴的看到“多数据中心读写优化”项目让 TiDB 向 Spanner 级别多数据中心能力迈出了坚实的一步。相信在社区小伙伴们的共同努力下，假以时日 TiDB 一定能够为大家带来 Google Spanner 级别的体验。” —— 孙晓光（知乎｜技术平台负责人） “在官方推荐的具备同城多活能力的同城三中心五副本，以及两地三中心五副本的部署方案中

作者： Breezewish 本文为 TiKV 源码解析系列的第四篇，接上篇继续为大家介绍 rust-prometheus 。 上篇 主要介绍了基础知识以及最基本的几个指标的内部工作机制，本篇会进一步介绍更多高级功能的实现原理。 与上篇一样，以下内部实现都基于本文发布时最新的 rust-prometheus 0.5 版本代码，目前我们正在开发 1.0 版本，API 设计上会进行一些简化，实现上出于效率考虑也会和这里讲解的略微有一些出入，因此请读者注意甄别。 指标向量（Metric Vector） Metric Vector 用于支持带 Label 的指标。由于各种指标都可以带上 Label，因此 Metric Vector 本身实现为了一种泛型结构体， Counter 、 Gauge 和 Histogram 在这之上实现了 CounterVec 、 GaugeVec 和 HistogramVec 。Metric Vector 主要实现位于 src/vec.rs 。 以 HistogramVec 为例，调用 HistogramVec::with_label_values 可获得一个 Histogram 实例，而 HistogramVec 定义为： pub type HistogramVec = MetricVec<HistogramVecBuilder>; pub struct

作者：黄梦龙 背景知识 TiKV 使用 Raft 算法来提供高可用且具有强一致性的存储服务。在 Raft 中，Snapshot 指的是整个 State Machine 数据的一份快照，大体上有以下这几种情况需要用到 Snapshot： 正常情况下 leader 与 follower/learner 之间是通过 append log 的方式进行同步的，出于空间和效率的考虑，leader 会定期清理过老的 log。假如 follower/learner 出现宕机或者网络隔离，恢复以后可能所缺的 log 已经在 leader 节点被清理掉了，此时只能通过 Snapshot 的方式进行同步。 Raft 加入新的节点的，由于新节点没同步过任何日志，只能通过接收 Snapshot 的方式来同步。实际上这也可以认为是 1 的一种特殊情形。 出于备份/恢复等需求，应用层需要 dump 一份 State Machine 的完整数据。 TiKV 涉及到的是 1 和 2 这两种情况。在我们的实现中，Snapshot 总是由 Region leader 所在的 TiKV 生成，通过网络发送给 Region follower/learner 所在的 TiKV。 理论上讲，我们完全可以把 Snapshot 当作普通的 RaftMessage 来发送，但这样做实践上会产生一些问题，主要是因为 Snapshot

作者：吴叶磊 一直以来我对优雅地停止 Pod 这件事理解得很单纯：不就利用是 PreStop hook 做优雅退出吗？但最近发现很多场景下 PreStop Hook 并不能很好地完成需求，这篇文章就简单分析一下“优雅地停止 Pod”这回事儿。 何谓优雅停止？ 优雅停止（Graceful shutdown）这个说法来自于操作系统，我们执行关机之后都得 OS 先完成一些清理操作，而与之相对的就是硬中止（Hard shutdown），比如拔电源。 到了分布式系统中，优雅停止就不仅仅是单机上进程自己的事了，往往还要与系统中的其它组件打交道。比如说我们起一个微服务，网关把一部分流量分给我们，这时： 假如我们一声不吭直接把进程杀了，那这部分流量就无法得到正确处理，部分用户受到影响。不过还好，通常来说网关或者服务注册中心会和我们的服务保持一个心跳，过了心跳超时之后系统会自动摘除我们的服务，问题也就解决了；这是硬中止，虽然我们整个系统写得不错能够自愈，但还是会产生一些抖动甚至错误。 假如我们先告诉网关或服务注册中心我们要下线，等对方完成服务摘除操作再中止进程，那不会有任何流量受到影响；这是优雅停止，将单个组件的启停对整个系统影响最小化。 按照惯例，SIGKILL 是硬终止的信号，而 SIGTERM 是通知进程优雅退出的信号，因此很多微服务框架会监听 SIGTERM 信号

爱奇艺，中国高品质视频娱乐服务提供者，2010 年 4 月 22 日正式上线，推崇品质、青春、时尚的品牌内涵如今已深入人心，网罗了全球广大的年轻用户群体，积极推动产品、技术、内容、营销等全方位创新。企业愿景为做一家以科技创新为驱动的伟大娱乐公司。我们在前沿技术领域也保持一定的关注度。 随着公司业务的快速发展，原来普遍使用的 MySQL 集群遇到了很多瓶颈，比如单机 MySQL 实例支撑的数据量有限，只能通过不停删除较旧的数据来维持数据库的运转。同时单表的数据行数不断增大导致查询速度变慢。急需一种可扩展、高可用同时又兼容 MySQL 访问方式的数据库来支撑业务的高速发展。 我司从 2017 年年中开始调研 TiDB，并且在数据库云部门内部系统中使用了 TiDB 集群。从今年 TiDB 推出 2.0 之后，TiDB 愈发成熟，稳定性与查询效率都有很大提升。今年陆续接入了边控中心、视频转码、用户登录信息等几个业务，这几个业务背景和接入方式如下详述。 项目介绍 1. 边控中心 边控中心存储的是机器的安全统计信息，包括根据 DC、IP、PORT 等不同维度统计的流量信息。上层业务会不定期做统计查询，其业务页面如下： <center>图 1 边控中心上层业务页面（一）</center> <center>图 2 边控中心上层业务页面（二）</center> 在选型过程中，也考虑过时序型数据库

1. 背景和现状 近几年，基于MySQL构建的传统关系型数据库服务，已经很难支撑美团业务的爆发式增长，这就促使我们去探索更合理的数据存储方案和实践新的运维方式。而随着分布式数据库大放异彩，美团DBA团队联合基础架构存储团队，于 2018 年初启动了分布式数据库项目。 图 1 美团点评产品展示图 在立项之初，我们进行了大量解决方案的对比，深入了解了业界的 scale-out（横向扩展）、scale-up（纵向扩展）等解决方案。但考虑到技术架构的前瞻性、发展潜力、社区活跃度以及服务本身与 MySQL 的兼容性，我们最终敲定了基于 TiDB 数据库进行二次开发的整体方案，并与 PingCAP 官方和开源社区进行深入合作的开发模式。 美团业务线众多，我们根据业务特点及重要程度逐步推进上线，到截稿为止，已经上线了 10 个集群，近 200 个物理节点，大部分是 OLTP 类型的应用，除了上线初期遇到了一些小问题，目前均已稳定运行。初期上线的集群，已经分别服务于配送、出行、闪付、酒旅等业务。虽然 TiDB 的架构分层相对比较清晰，服务也是比较平稳和流畅，但在美团当前的数据量规模和已有稳定的存储体系的基础上，推广新的存储服务体系，需要对周边工具和系统进行一系列改造和适配，从初期探索到整合落地，仍然还需要走很远的路。下面将从以下几个方面分别进行介绍： 从 0 到 1 的突破，重点考虑做哪些事情。