一文看懂开源许可证

       理解开源许可证的源码核心在于其版权管理，确保软件的源码修改和使用在法律框架内进行。开源软件通过相应的源码许可证，如Apache、源码MIT、源码BSD、源码自定义表单系统源码GPL、源码LGPL和MPL，源码规范用户的源码行为，区分两类主要协议：宽松自由（Permissive free software licence）和著作权保护（Copyleft License）。源码

       宽松的源码许可证允许更自由地使用、修改和传播，源码如Apache、源码MIT和BSD，源码不强制公开源代码，源码衍生作品可以是专有软件。相反，Copyleft License如GPL和LGPL要求公开源代码，并确保修改后的作品也遵循开源原则。SSPL的争议性表明其可能不符合传统的开源定义。

       开源背后的动力源自FSF和OSI这样的组织，前者以copyleft的长生劫 资源码GPL为代表，后者则寻求商业和开源之间的平衡。这些组织推动了如Apache License这样的许可证，鼓励代码共享和原作者权益，但同时有明确的使用规则，如Apache许可下的企业需遵循相关条件，否则可能侵犯原项目权益。

       PingCAP作为以开源为基石的公司，如TiDB、TiKV和Chaos Mesh，坚持Apache 2.0协议，鼓励创新和协作。开源社区是创新的引擎，如TiDB社区的成熟度研究，旨在促进健康可持续的发展。参与开源需遵循规则，共同维护开源的未来。

TiFlash 源码阅读（一） TiFlash 存储层概览

       本系列文章聚焦于 TiFlash，读者需具备基本的 TiDB 知识。TiFlash 是 TiDB HTAP 模式的关键组件，作为 TiKV 的列存扩展，通过 Raft Learner 协议实现异步复制，新版速来捕鱼源码并提供与 TiKV 相同的快照隔离支持。自 5.0 引入 MPP 后，TiDB 的实时分析场景下计算加速能力得到了增强。

       TiFlash 整体逻辑模块划分如下：通过 Raft Learner Proxy 接入多 Raft 体系，计算层 MPP 在 TiFlash 间进行数据交换，提供更强的分析计算能力。Schema 模块与 TiDB 表结构同步，将 TiKV 同步数据转换为列形式，并写入列存引擎。底层为 DeltaTree 引擎。

       TiFlash 基于 ClickHouse fork，沿用了 ClickHouse 的向量化执行引擎，并加入针对 TiDB 的对接、MySQL 兼容、Raft 协议、集群模式、实时更新列存引擎、MPP 架构等特性。DeltaTree 引擎解决了高频率数据写入、实时更新读性能优化、符合 TiDB 事务模型、开发app源码下载支持 MVCC 过滤、数据分片便于分析场景等需求。

       DeltaTree 引擎不同于 MergeTree，具备原生支持高频率写入、列存实时更新下读性能优化、支持 TiDB 事务模型、数据分片便于提供分析特性等优势。MergeTree 引擎存在写入碎片、Scan 时 CPU cache miss 严重、清理过期数据时 compaction 导致性能波动等问题，而 DeltaTree 通过横向分割数据管理、delta-stable 数据组织、PageStorage 存储等设计优化了性能。

       DeltaTree 引擎通过在表内按 handle 列分段管理数据，采用 delta-stable 数据组织，PageStorage 存储小数据块，构建 DeltaIndex 和 Rough Set Index 等组件优化读性能。DeltaIndex 帮助减少 CPU bound 的 merge 操作，Rough Set Index 用于过滤数据块，减少不必要的 IO 操作。

       TiFlash 存储层 DeltaTree 引擎在不同数据量和更新 TPS 下读性能表现优于基于 MergeTree 的c源码编译环境实现，提供更稳定、高效的读、写性能。TiFlash 中的 PageStorage、DeltaIndex、Rough Set Index 等组件协同作用，优化数据管理和查询性能。

       DeltaTree 引擎在 TiFlash 内部实现中，通过 PageStorage 存储数据，DeltaIndex 提高读性能，Rough Set Index 优化查询效率，提供了对 HTAP 场景的优化和支持。TiFlash 存储层 DeltaTree 引擎的设计和实现细节将在后续章节中详细展开。

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 应用场景与性能。

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 的概要介绍，后续将深入分析该模块的源码细节，并欢迎读者提出改进意见。