Lenshood

这一节的主要内容，是讲解 TiKV 如何执行下推计算的。

本文中涉及到的图片来源，都来自 PingCAP 官方网站。

通过先前的课程我们了解到，tidb 在生成执行计划时，先生成逻辑计划，之后将逻辑计划翻译成物理计划。而物理计划最终都是以 task 的形式来执行的，task 分 root task 和 coptask，coptask 通常就会下推至 tikv 来执行。

本节课程主要学习的是 TiDB 的 事务原理。由于 TiDB 的分布式部署的特性，其事务的实现主要借鉴了 Percolator 中分布式事务的实现方式，将 TiDB 与 TiKV 结合起来，共同完成分布式事务的任务。

本文中涉及到的图片来源，都来自 PingCAP 官方网站。

本节课程主要学习的是 TiDB 的 planer 模块，planer 模块的主要功能是将 AST 转化为实际的执行计划，在这当中，包含了两个阶段的优化过程：逻辑优化、物理优化。优化过后的执行计划可以直接构造对应的 Executor 来执行（回忆 Executor 章节的火山模型）。

本文中涉及到的图片来源，都来自 PingCAP 官方网站。

这一节，我们涉及的知识是 TiDB 如何实现 DDL。

本次课程主要涉及 TiDB 中的 Executor 组件。

本节课程作业，我们会采用多种 profile 工具来对 TiDB 的性能进行分析，寻找其性能瓶颈，并根据分析结果来给出优化建议。

主要内容如下：

1. TiUP 部署最小集群
2. TiDB CPU Profile
3. 性能瓶颈分析与优化建议

这一节，我们需要对一个完整的 TiDB 集群进行性能测试，为了实现这一目标，本文会通过以下几个步骤来介绍如何从零开始实现 TiDB 的性能测试：

1. 借助 kind 在单机模拟集群
2. 通过 TiDB Operator 部署 TiDB 集群到 K8S
3. 根据机器硬件调整 TiDB 配置
4. 性能测试
   1. sysbench 测试
   2. go-ycsb 测试
   3. go-tpc 测试
5. 性能瓶颈分析

今年了解到 TiDB 这样一个 HTAP 数据库，在 Github 上面热度超高，再加上国人开发与维护，因此产生了很大的兴趣。

正好社区搞了一个《高性能 TiDB 课程学习计划》通过 12 节课来使学员能达到 Committer 的水平，因此就报名参加啦。

第一节课的课程作业是尝试在本地启动一个最小集群，并在开启事务时打印 “hello transaction” 并将这一过程写成一片文章，因此本文将会主要描述这一过程。

近期所在的项目，在进行近 4 个月的紧张交付后，与客户一起安排并进行了一次发布上线。在上线过程中出现了一个较为严重的事故，好在没有对客户造成太大的损失，本文期望针对完整的事件进行复盘与反思，以加强自己对线上环境的敬畏。

本文是对 Pete Hodgson 的文章 Feature Toggles (aka Feature Flags) 的全文翻译，一切版权归原作者所有。

Feature Toggles（也经常被称为 Feature Flags）是一项强大的技术，它允许团队不改动代码就能改变系统的行为。Feature Toggles 分为了许多种使用类别，当实现和管理他们时，考虑这些类别是十分重要的。Toggle 会引入复杂性。我们可以通过更聪明的实现方法与合适的工具来管理 Toggle 配置，以此来使 Toggle 带来的复杂性可控，但是我们也应该限制系统中 Toggle 的总量。

“Feature Toggling” 是一组模式，它能帮助团队更快且更安全的将新功能交付给用户。在下文中，我们会以一个小故事开头，来展现一些 Feature Toggling 适用的典型场景。之后我们会深入细节，这包括有助于团队成功实施 Feature Toggle 的特定模式与实践。

Feature Toggles 也被称为 Feature Flags， Feature Bits， 或 Feature Flippers。他们都是同一类技术的同义词。 在下文中我会交替使用 feature toggles 和 feature flags。