皮皮网

1.【CUDA编程】OneFlow Softmax 算子源码解读之WarpSoftmax
2.TiKV 源码解析系列文章（十七）raftstore 概览
3.TiDB 源码阅读系列文章（五）TiDB SQL Parser 的源码文章实现
4.openGauss数据库源码解析系列文章——事务机制源码解析（一）
5.Mobx源码阅读笔记——3. proxy 还是defineProperty，劫持对象行为的源码文章两个方案
6.TiKV 源码解析系列文章（十四）Coprocessor 概览

【CUDA编程】OneFlow Softmax 算子源码解读之WarpSoftmax

       深度学习框架中的Softmax操作在模型中扮演关键角色，尤其在多分类任务中，源码文章其用于将logits映射成概率分布，源码文章或在Transformer结构中衡量query与key的源码文章相似度。Softmax的源码文章springboot系统源码CUDA实现直接关系到模型训练效率。本文以OneFlow框架中的源码文章一种优化Softmax实现为例，即Warp级别的源码文章Softmax，特别适用于矩阵宽度不超过的源码文章场景。

       Softmax操作的源码文章计算公式如下：

       [公式]

       为解决数值溢出问题，通常先减去向量的源码文章最大值。优化后的源码文章公式为：

       [公式]

       Softmax计算涉及五个关键步骤：reduceMax、broadcastSub、源码文章exp、源码文章reduceSum、源码文章broadcastDiv。本篇文章将深入探讨OneFlow源码中的实现技巧。

       OneFlow采用分段函数优化SoftmaxKernel，针对不同数量的列选择不同实现策略，以适应各种场景。为实现优化，OneFlow提供三种Softmax实现方式，以期在所有情况下达到较高的有效带宽。

       对于WarpSoftmax分支，源码中函数调用关系清晰，实现细节分为四部分：数据Pack、调用链、DispatchSoftmaxWarpImpl、DispatchSoftmaxWarpImplCols、DispatchSoftmaxWarpImplPadding、LaunchSoftmaxWarpImpl。各部分分别专注于提升访问带宽、确定函数参数、实现核心计算逻辑。

       在WarpSoftmax的核函数SoftmaxWarpImpl中，重点实现以下步骤：核函数启动参数确定、线程网格形状定义、数据加载到寄存器、计算最大值、计算指数和、规约操作、通信优化等。实现过程中，OneFlow通过优化数据访问模式、利用寄存器存储中间结果、并行规约操作，以及束内通信，提升了计算效率。

       总结WarpSoftmax源码中的关键点，本文详细解读了其优化策略与实现细节，旨在提高模型训练速度。通过深入分析OneFlow框架中的Softmax实现，读者可以更全面地理解深度学习框架在CUDA环境下进行优化的策略。

TiKV 源码解析系列文章（十七）raftstore 概览

       TiKV，作为分布式 KV 数据库，利用 Raft 算法提供强一致性，但单一 Raft 组无法满足扩展性和均衡需求，物业管理源码因此引入了 MultiRaft 架构。在 TiKV 中，数据通过分片形成多个 Region，每个 Region 由一个 Raft 组管理，形成一对一关系。通过多 Raft 组并行管理，实现高效扩展和均衡。

       MultiRaft 与 Region 结构紧密相连，数据在多个副本间分布，一个机器可能承载多个不同 Region 的副本。这种设计允许 Raft 组并行工作，从而提升性能和容错能力。

       Batch System 是 raftstore 的核心机制，用于并发驱动状态机。状态机通过 PollHandler 驱动，分为 normal 和 control 两种类型。control 状态机负责全局任务管理，normal 状态机处理特定任务。消息和消息队列绑定在状态机上，PollHandler 负责消费消息，产生落盘或网络交互的副作用。

       raftstore 中包含 RaftBatchSystem 和 ApplyBatchSystem 两个 Batch System。RaftBatchSystem 处理 Raft 状态机，包括日志分发、落盘、状态迁移等。ApplyBatchSystem 解析日志并应用到底层 KV 数据库，执行回调函数。写操作遵循此流程，客户端请求序列化为日志后，通过 Raft 提交到 raft。Ready 机制收集副作用，最终由 Batch System 处理。

       Region 的分裂和合并是 TiKV 稳定运行的关键。Split 将大范围数据分割，创建新 Raft 组管理；Merge 则合并相邻 Raft 组，优化资源利用。这些操作遵循 Raft 提交/确认流程，并维护版本概念，确保写命令正确分发。

       LocalReader 为读操作提供优化，Raft 组 leader 维护 lease 机制，确保在有效期内的读操作即时执行，超出则触发续期。Lease 定义了读操作的时间窗口，允许精度误差，优化性能。

       Coprocessor 用于自定义 KV 处理逻辑，如事务一致性、关键数据管理等。TiKV 中包括 SQL 下推、Observer 等 Coprocessor，监听事件并执行自定义逻辑，保证系统正确运行。

       综上所述，TiKV 通过 MultiRaft、陌陌的源码Batch System、LocalReader 和 Coprocessor 等机制，实现了高效、可靠的分布式 KV 存储。深入理解这些组件的原理与实现细节，有助于优化 TiKV 应用场景与性能。

TiDB 源码阅读系列文章（五）TiDB SQL Parser 的实现

       本文是 TiDB 源码阅读系列文章的第五篇，主要内容围绕 SQL Parser 功能实现进行讲解。内容源自社区伙伴马震（GitHub ID：mz）的投稿。系列文章的目的是与数据库研究者及爱好者深入交流，收到了社区的积极反馈。后续，期待更多伙伴加入 TiDB 的探讨与分享。

       TiDB 的源码阅读系列文章，帮助读者系统性地学习 TiDB 内部实现。最近的《SQL 的一生》一文，全面阐述了 SQL 语句处理流程，从接收网络数据、MySQL 协议解析、SQL 语法解析、查询计划制定与优化、执行直至返回结果。

       其中，SQL Parser 的功能是将 SQL 语句按照 SQL 语法规则进行解析，将文本转换为抽象语法树（AST）。此功能需要一定背景知识，下文将尝试介绍相关知识，以帮助理解这部分代码。

       TiDB 使用 goyacc 根据预定义的 SQL 语法规则文件 parser.y 生成 SQL 语法解析器。这一过程可在 TiDB 的 Makefile 文件中看到，通过构建 goyacc 工具，使用 goyacc 依据 parser.y 生成解析器 parser.go。

       goyacc 是 yacc 的 Golang 版本，因此理解语法规则定义文件 parser.y 及解析器工作原理之前，需要对 Lex & Yacc 有所了解。Lex & Yacc 是用于生成词法分析器和语法分析器的工具，它们简化了编译器的编写。

       下文将详细介绍 Lex & Yacc 的工作流程，以及生成解析器的过程。我们将从 Lex 根据用户定义的 patterns 生成词法分析器，词法分析器读取源代码并转换为 tokens 输出，以及 Yacc 根据用户定义的语法规则生成语法分析器等角度进行阐述。

       生成词法分析器和语法分析器的过程，用户需为 Lex 提供 patterns 的定义，为 Yacc 提供语法规则文件。这两种配置都是文本文件，结构相同，分为三个部分。我们将关注中间规则定义部分，并通过一个简单的例子来解释。

       Lex 的输入文件中，规则定义部分使用正则表达式定义了变量、整数和操作符等 token 类型。例如整数 token 的定义，当输入字符串匹配正则表达式时，大括号内的卡盟源码下载动作会被执行，将整数值存储在变量yylval 中，并返回 token 类型 INTEGER 给 Yacc。

       而 Yacc 的语法规则定义文件中，第一部分定义了 token 类型和运算符的结合性。四种运算符都是左结合，同一行的运算符优先级相同，不同行的运算符，后定义的行具有更高的优先级。语法规则使用 BNF 表达，大部分现代编程语言都可以使用 BNF 表示。

       表达式解析是生成表达式的逆向操作，需要将语法树归约到一个非终结符。Yacc 生成的语法分析器使用自底向上的归约方式进行语法解析，同时使用堆栈保存中间状态。通过一个表达式 x + y * z 的解析过程，我们可以理解这一过程。

       在这一过程中，读取的 token 压入堆栈，当发现堆栈中的内容匹配了某个产生式的右侧，则将匹配的项从堆栈中弹出，将该产生式左侧的非终结符压入堆栈。这个过程持续进行，直到读取完所有的 tokens，并且只有启始非终结符保留在堆栈中。

       产生式右侧的大括号中定义了该规则关联的动作，例如将三项从堆栈中弹出，两个表达式相加，结果再压回堆栈顶。这里可以使用 $position 的形式访问堆栈中的项，$1 引用第一项，$2 引用第二项，以此类推。$$ 代表归约操作执行后的堆栈顶。本例的动作是将三项从堆栈中弹出，两个表达式相加，结果再压回堆栈顶。

       在上述例子中，动作不仅完成了语法解析，还完成了表达式求值。一般希望语法解析的结果是一颗抽象语法树（AST），可以定义语法规则关联的动作。这样，解析完成时，我们就能得到由 nodeType 构成的抽象语法树，对这个语法树进行遍历访问，可以生成机器代码或解释执行。

       至此，我们对 Lex & Yacc 的原理有了大致了解，虽然还有许多细节，如如何消除语法的歧义，但这些概念对于理解 TiDB 的代码已经足够。

       下一部分，我们介绍 TiDB SQL Parser 的实现。有了前面的背景知识，对 TiDB 的 SQL Parser 模块的理解会更易上手。TiDB 使用手写的条形码源码词法解析器（出于性能考虑），语法解析采用 goyacc。我们先来看 SQL 语法规则文件 parser.y，这是生成 SQL 语法解析器的基础。

       parser.y 文件包含 多行代码，初看可能令人感到复杂，但该文件仍然遵循我们之前介绍的结构。我们只需要关注第一部分 definitions 和第二部分 rules。

       第一部分定义了 token 类型、优先级、结合性等。注意 union 结构体，它定义了在语法解析过程中被压入堆栈的项的属性和类型。压入堆栈的项可能是终结符，也就是 token，它的类型可以是 item 或 ident；也可能是非终结符，即产生式的左侧，它的类型可以是 expr、statement、item 或 ident。

       goyacc 根据这个 union 在解析器中生成对应的 struct。在语法解析过程中，非终结符会被构造成抽象语法树（AST）的节点 ast.ExprNode 或 ast.StmtNode。抽象语法树相关的数据结构定义在 ast 包中，它们大都实现了 ast.Node 接口。

       ast.Node 接口有一个 Accept 方法，接受 Visitor 参数，后续对 AST 的处理主要依赖这个 Accept 方法，以 Visitor 模式遍历所有的节点以及对 AST 做结构转换。例如 plan.preprocess 是对 AST 做预处理，包括合法性检查以及名字绑定。

       union 后面是对 token 和非终结符按照类型分别定义。第一部分的最后是对优先级和结合性的定义。文件的第二部分是 SQL 语法的产生式和每个规则对应的 aciton。SQL 语法非常复杂，大部分内容都是产生式的定义。例如 SELECT 语法的定义，我们可以在 parser.y 中找到 SELECT 语句的产生式。

       完成语法规则文件 parser.y 的定义后，使用 goyacc 生成语法解析器。TiDB 对 lexer 和 parser.go 进行封装，对外提供 parser.yy_parser 进行 SQL 语句的解析。

       最后，我们通过一个简单的例子，使用 TiDB 的 SQL Parser 进行 SQL 语法解析，构建出抽象语法树，并通过 visitor 遍历 AST。我实现的 visitor 只输出节点的类型，运行结果依次输出遍历过程中遇到的节点类型。

       了解 TiDB SQL Parser 的实现后，我们有可能实现当前不支持的语法，如添加内置函数。这为我们学习查询计划以及优化打下了基础。希望这篇文章对读者有所帮助。

       作者介绍：马震，金蝶天燕架构师，负责中间件、大数据平台的研发，今年转向 NewSQL 领域，关注 OLTP/AP 融合，目前在推动金蝶下一代 ERP 引入 TiDB 作为数据库存储服务。

openGauss数据库源码解析系列文章——事务机制源码解析（一）

       事务是数据库操作的核心单位，必须满足原子性、一致性、隔离性、持久性（ACID）四大属性，确保数据操作的可靠性与一致性。以下是openGauss数据库中事务机制的详细解析：

       ### 事务整体架构与代码概览

       在openGauss中，事务的实现与存储引擎紧密关联，主要集中在源代码的`gausskernel/storage/access/transam`与`gausskernel/storage/lmgr`目录下。事务系统包含关键组件：

       1. **事务管理器**：事务系统的中枢，基于有限循环状态机，接收外部命令并根据当前事务状态决定下一步执行。

       2. **日志管理器**：记录事务执行状态及数据变化过程，包括事务提交日志（CLOG）、事务提交序列日志（CSNLOG）与事务日志（XLOG）。

       3. **线程管理机制**：通过内存区域记录所有线程的事务信息，支持跨线程事务状态查询。

       4. **MVCC机制**：采用多版本并发控制（MVCC）实现读写隔离，结合事务提交的CSN序列号，确保数据读取的正确性。

       5. **锁管理器**：实现写并发控制，通过锁机制保证事务执行的隔离性。

       ### 事务并发控制

       事务并发控制机制保障并发执行下的数据库ACID属性，主要由以下部分构成：

       - **事务状态机**：分上层与底层两个层次，上层状态机通过分层设计，支持灵活处理客户端事务执行语句（BEGIN/START TRANSACTION/COMMIT/ROLLBACK/END），底层状态机记录事务具体状态，包括事务的开启、执行、结束等状态变化。

       #### 事务状态机分解

       - **事务块状态**：支持多条查询语句的事务块，包含默认、已开始、事务开始、运行中、结束状态。

       - **底层事务状态**：状态包括TRANS_DEFAULT、TRANS_START、TRANS_INPROGRESS、TRANS_COMMIT、TRANS_ABORT、TRANS_DEFAULT，分别对应事务的初始、开启、运行、提交、回滚及结束状态。

       #### 事务状态转换与实例

       通过状态机实例展示事务执行流程，包括BEGIN、SELECT、END语句的执行过程，以及相应的状态转换。

       - **BEGIN**：开始一个事务，状态从默认转为已开始，之后根据语句执行逻辑状态转换。

       - **SELECT**：查询语句执行，状态保持为已开始或运行中，事务状态不发生变化。

       - **END**：结束事务，状态从运行中或已开始转换为默认状态。

       #### 事务ID分配与日志

       事务ID（xid）以uint单调递增序列分配，用于标识每个事务，CLOG与CSNLOG分别记录事务的提交状态与序列号，采用SLRU机制管理日志，确保资源高效利用。

       ### 总结

       事务机制在openGauss数据库中起着核心作用，通过详细的架构设计与状态管理，确保了数据操作的ACID属性，支持高并发环境下的高效、一致的数据处理。MVCC与事务ID的合理使用，进一步提升了数据库的性能与数据一致性。未来，将深入探讨事务并发控制的MVCC可见性判断机制与进程内的多线程管理机制，敬请期待。

Mobx源码阅读笔记——3. proxy 还是defineProperty，劫持对象行为的两个方案

       这篇文章将深入分析 MobX 的 observableObject 数据类型的源码，同时探讨使用 Proxy 和 Object.defineProperty 这两种实现方案来劫持对象行为的策略。通过分析，我们能够理解 MobX 在创建 observableObject 时是如何同时采用这两种方案，并在创建时决定使用哪一种。

       首先，回顾 observableArray 的实现方式，通过 Proxy 代理数组的行为，转发给 ObservableArrayAdministration 来实现响应式修改的逻辑。同样，我们已经讨论过 observableValue 的实现，通过一个特殊的类 ObservableValue 直接使用其方法，无需代理。

       对于 observableObject 的实现机制，其特点在于同时采用了上述两种方案，并且在创建时决定使用哪一种。让我们回到文章中提到的工厂方法，其中根据 options.proxy 的值来决定使用哪一种方案。

       在 options.proxy 为 false 的情况下，使用第一条路径来实现 observableObject。这通过直接返回 extendObservable 的结果，其中 extendObservable 是一个工具函数，用于向已存在的目标对象添加 observable 属性。属性映射中的所有键值对都会导致目标上生成新的 observable 属性，并且属性映射中的任意 getters 会被转化为计算属性。

       这里首先根据 options 参数选择特定的 decorator，这个过程与之前在第一篇文章中通过 options 参数选择特定的 enhancer 类似。实际上，这里的 decorator 起到了类似的作用，甚至在创建 decorator 这个过程本身也需要通过 enhancer 参数。

       至于 decorator 和 enhancer 之间的耦合机制，文章中详细解释了 createDecoratorForEnhancer 和 createPropDecorator 函数，通过这些函数我们能够了解到它们是如何将 decorator 和 enhancer 联系起来的。

       接下来，文章深入分析了 decorator 的作用机制，包括它如何决定是否立即执行，以及在不立即执行时如何将创建 prop 的相关信息保存下来。通过 initializeInstance 函数，我们了解了如何解决 # 问题，这涉及到如何正确处理那些在创建时未被立即执行的 prop。

       最终，通过为 target 对象创建 ObservableObjectAdministration 管理对象，并通过 $mobx 和 target 属性将它们关联起来，我们完成了 observableObject 的创建。如果传入的 properties 不为空，则使用 extendObservableObjectWithProperties 来初始化。这里的代码逻辑相对简单，主要遍历 properties 中的所有键并调用对应的 decorator。

       文章还指出，虽然在第一条路径中，使用 Object.defineProperty 重写了 prop 的 getter 和 setter，但在 MobX 4 及以下版本中，使用 Proxy 来实现 observableObject 的逻辑更为常见。Proxy 特性在 ES6 引入后，提供了更强大的能力来劫持对象的行为，不仅限于 getter 和 setter，还包括对象的其他行为。

       最后，文章总结了使用 Proxy 方案的优点，包括能够更全面地劫持对象的行为，而不仅仅是属性的 getter 和 setter。Proxy 方案在实现双向绑定时，能够提供更灵活和强大的功能。同时，文章也提到了两种方案的局限性，尤其是在处理对象属性的可观察性方面，Proxy 方案在某些情况下可能更具优势。

TiKV 源码解析系列文章（十四）Coprocessor 概览

       本文将简要介绍 TiKV Coprocessor 的基本原理。TiKV Coprocessor 是 TiDB 的一部分，用于在 TiKV 层处理读请求。通过引入 Coprocessor，TiKV 可以在获取数据后进行计算，从而提高性能。

       传统处理方式中，TiDB 向 TiKV 获取数据，然后在 TiDB 内部进行计算。而 Coprocessor 则允许 TiKV 进行计算，将计算结果直接返回给 TiDB，减少数据在系统内部的传输。

       Coprocessor 的概念借鉴自 HBase，其主要功能是对读请求进行分类，处理包括 TableScan、IndexScan、Selection、Limit、TopN、Aggregation 等不同类型请求。其中，DAG 类请求是最复杂且常用的类型，本文将重点介绍。

       DAG 请求是由一系列算子组成的有向无环图，这些算子在代码中称为 Executors。DAG 请求目前支持两种计算模型：火山模型和向量化模型。在当前的 TiKV master 上，这两种模型并存，但火山模型已被弃用，因此本文将重点介绍向量化计算模型。

       向量化计算模型中，所有算子实现了 BatchExecutor 接口，其核心功能是 get_batch。算子类型包括 TableScan、IndexScan、Selection、Limit、TopN 和 Aggregation 等，它们之间可以任意组合。

       以查询语句“select count(1) from t where age>”为例，展示了如何使用不同算子进行处理。本文仅提供 Coprocessor 的概要介绍，后续将深入分析该模块的源码细节，并欢迎读者提出改进意见。

Recast NavigationSoloMesh源码分析（三）——行走面过滤

       本文是对SoloMesh源码分析系列文章的第三部分，主题为行走面过滤。此阶段的处理是对体素化后Heightfield的修正和标记，旨在优化导航网格的构建过程。

       行走面过滤分为三个主要步骤：过滤悬空的可走障碍物、过滤高度差过大的span以及过滤不可通过高度span。

       首先，过滤悬空的可走障碍物通过函数rcFilterLowHangingWalkableObstacles实现。此过程识别上下两个体素，其中下体素可行走，而上体素不可行走。若上下两体素上表面相差不超过walkClimb，则将上体素标记为可行走。

       接着，过滤高度差过大的span通过rcFilterLedgeSpans函数完成。此过程寻找如图所示的两种情况。首先，确保上span与下span与邻居的上span下span之间存在超过walkHeight的空隙，表明可通过一个agent的高度。然后，根据两种不同的情况，对体素进行判断，以解决转角台阶的识别问题。实际上，该步骤的目的是通过补充斜向体素的考虑，解决体素连接关系仅考虑4方邻居的问题。然而，该方法存在影响同方向体素的副作用，即图示的错误例子。解决这一问题的方法是排除同方向的两个体素比较。

       最后，过滤不可通过高度span通过rcFilterWalkableLowHeightSpans实现。此过程检查上下两个span之间空隙，若小于等于walkHeight，则将下span标记为不可行走。

       总结：代码逻辑相对简单，具体实现细节可直接在github的wcqdong/recastnavigation项目中查看源码注释，以深入理解此阶段的详细处理流程。

TiDB 源码阅读系列文章（十六）INSERT 语句详解

       作者：于帅鹏

       在已有的文章《TiDB 源码阅读系列文章（四）INSERT 语句概览》中，探讨了 INSERT 语句的基本流程。本文将深入解析 TiDB 中 INSERT 语句的多样性，特别是处理Unique Key冲突的各种策略。我们将了解六种不同类型的INSERT，包括基本插入、忽略冲突、更新冲突、警告更新、替换插入和特殊的LOAD DATA导入。

       六种INSERT语句如下：

       基本插入：当遇到唯一键冲突时，返回失败。

       忽略冲突：插入时遇到冲突，忽略并记录警告。

       更新冲突：在冲突后尝试更新并插入，若更新后仍有冲突，报错。

       警告更新：同上，冲突后更新，冲突再冲突则为警告。

       替换插入：冲突时删除并插入，重复此过程直到无冲突。

       LOAD DATA：类似忽略冲突，数据来自csv文件，但处理方式特殊。

       基本插入的执行逻辑在executor/insert.go，其中InsertExec实现了Executor接口。执行流程根据是否使用SELECT语句获取数据，分为insertRows和insertRowsFromSelect。insertOneRow是处理基本插入的核心部分，它在事务提交时检查冲突，利用batchChecker进行高效冲突检测。

       对于INSERT IGNORE，虽然基本插入在提交时检测冲突，但INSERT IGNORE需要立即检测，因此使用batchChecker实现批量检查，以提高效率。而INSERT ON DUPLICATE KEY UPDATE更为复杂，涉及插入和更新操作，通过batchChecker读取和更新数据，处理各种可能的冲突情况。

       REPLACE INSERT语句则具有特殊性，它会删除冲突行直到成功插入，这与其它INSERT语句处理冲突的方式有所不同。

       理解这些INSERT语句的实现，对于使用TiDB的高效执行以及潜在的代码贡献具有重要意义。继续阅读源码，掌握这些细节，将有助于你更准确地运用INSERT语句。