1.TiDB简介
TiDB 是 PingCAP 公司⾃主设计、研发的开源分布式关系型数据库，是⼀款同时⽀持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing,HTAP) 的融合型分布式数据库产品，具备⽔平扩容或者缩容、⾦融级⾼可⽤、实时HTAP、云原⽣的分布式数据库、兼容 MySQL 5.7 协议和 MySQL ⽣态等重要特性。⽬标是为⽤户提供⼀站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决⽅案。TiDB 适合⾼可⽤、强⼀致要求较⾼、数据规模较⼤等各种应⽤场景。
2.TiDB五⼤核⼼特性
- ⼀键⽔平扩容或者缩容
得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进⾏在线扩容或者缩容，扩容或者缩容过程中对应⽤运维⼈员透明。 - ⾦融级⾼可⽤
数据采⽤多副本存储，数据副本通过 Multi-Raft 协议同步事务⽇志，多数派写⼊成功事务才能提交，确保数据强⼀致性且少数副本发⽣故障时不影响数据的可⽤性。可按需配置副本地理位置、副本数量等策略满⾜不同容灾级别的要求 - 实时 HTAP
提供⾏存储引擎 TiKV、列存储引擎 TiFlash两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保⾏存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强⼀致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。 - 云原⽣的分布式数据库
专为云⽽设计的分布式数据库，通过 TiDB Operator可在公有云、私有云、混合云中实现部署⼯具化、⾃动化。 - 兼容 MySQL 5.7 协议和 MySQL ⽣态
兼容 MySQL 5.7 协议、MySQL 常⽤的功能、MySQL ⽣态，应⽤⽆需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移⼯具帮助应⽤便捷完成数据迁移。
3.TiDB的应⽤场景解决⽅案
3.1 TiDB规模化OLTP通⽤解决⽅案
近年来全球数据呈爆发增⻓，到2025年预计将达到175ZB，数据⽇益成为重要战略资源和新⽣产要素，数据库软件作为基础软件之⼀，时代发展对其能⼒提出了更⾼的要求。
关系型数据库在企业数字化转型的过程中⾯临诸多挑战：
- 海量数据下如何实现应⽤⽆感的在线⽔平扩展，具备弹性的架构能⼒；
- 多源数据接⼊，数据价值如何快速变现；
- 如何满⾜⾼并发、低延时、数据⼀致性、⾼可⽤等需求。
TiDB⽀持海量数据的⾼性能写⼊和实时分析
- TiDB提供可扩展、⽆上限的实时写⼊和实时查询能⼒；
- TiDB具备强⼤的分布式查询引擎，可⽤于各种实时分析场景。
TiDB分布式架构提供整体的弹性扩缩容能⼒
- TiDB⽔平弹性扩展、分布式数据库强⼀致性等特性适合批量计算场景；
- 解决传统数据库并发⽀持低、分析能⼒差、⽆法线性扩展等痛点；
- 结合应⽤系统的场景能⼒，打造整体分布式弹性扩缩容的业务架构。
该⽅案的优势：
- ⾼并发、可扩展、⽆上限的实时写⼊和查询能⼒。
- 采⽤存储计算分离的架构设计，可按需对计算、存储分别进⾏在线扩容或者缩容，且过程对应⽤运维⼈员透明。
- 数据均匀分散到所有存储节点，对应⽤完全透明。
3.2 TiDB实时数据服务解决⽅案
数字化转型过程中数据价值变现的关键点：
- 多源应⽤的数据实时汇聚能⼒
- 多场景的灵活数据计算能⼒
- 基于持续变化数据的管理模式
- 动态的数据加⼯与更新
- 持续、及时、⾼效获取“新鲜数据”
- T+0实时数据服务化能⼒
适⽤于实时监控、实时⼤屏、实时营销、⼤数据⻛控、实时搜索、实时资产等业务场景的混合负载：
- ⽀持多种数据采集⽅式，包括CDC（数据变化捕获）、消息中间件+流式计算框架的实时⽅式，及时、⾼效地获得“新鲜数据”；
- 基于⾏、列混存的HTAP架构，提供实时数据服务，具备数字化转型中数据价值的实时变现能⼒。
TiDB+Flink企业版（Ververica Platform）实时HTAP商业⽅案：
- 数据处理速度有保障，TiBD和Flink都可以通过⽔平扩展节点来增加算⼒。
- ⽤户可以单独使⽤TiDB构建实时分析业务，也可以与Flink⽣态⼀起构建实时的数仓体系。
该⽅案的优势：
- 灵活多样的准实时接⼊模式，简化中间集合，缩短传递链路，提⾼处理时效。
- 简化技术栈，实时HTAP，流批⼀体化。
- HTAP架构兼顾实时分析领域的⾼并发访问和交互式分析诉求。
3.3 企业级客户信息整合系统解决⽅案
ECIF是企业级客户信息整合系统(Enterprise Customer Information Facility)。ECIF提供客户维度的开⽴、变更、查询、校验客户信息等基本服务，以及合约关系管理、可会等级等增值服务。ECIF数据管理经历了“单体模式——垂直拆分模式——垂直+⽔平拆分模式”的变迁，当前ECIF的核⼼诉求和痛点包括：
- 数据规模⽔平扩展：随着数据整合以及业务的快速发展，ECIF所承载的数据规模呈指数级增⻓，传统单体数据库或分库分表模式⽆法满⾜需求。
- 简化数据管理模式：分库分表架构增加了系统的复杂度和维护成本，应⽤团队需要在业务功能迭代创新、系统稳定易⽤等⽅⾯不断平衡。
- 持续业务创新能⼒：数据拆分直接导致汇总查询、多维分析等跨分⽚场景⽆所适从，还需引⼊额外的汇总库，进⼀步加⼤了架构的复杂度和管理成本。
- 弹性架构能⼒：分库分表模式在⽔平扩展能⼒不⾜，需要停机进⾏数据迁移，⽆法做到在线⽔平扩展及真正意义的7*24服务，也会对系统⾼并发服务能⼒造成制约。
基于TiDB的ECIF弹性架构：
- 基于TiDB的OLTP Scale 能⼒承载ECIF系统的对私或对公客户信息、系统公共信息；
- 应⽤层通过数据访问组件基于负载均衡软、硬件访问TiDB中的各类数据进⾏联机和批量操作；
- ⽆需考虑分⽚键和反向索引设计，可基于标准索引进⾏多维度⾼效数据操作及汇聚查询；
- 批量操作可基于调度框架按业务维度分批次进⾏处理；
- 同时⽀持传统ETL离线⼊仓和TiCDC实时增量同步到下游；
- 可基于TiDB搭建跨数据中⼼级的⾼可⽤架构。
该⽅案的优势：
- 在线⽔平扩展和弹性架构能⼒
TiDB⽀持分布式事务和强⼀致性的⽔平弹性扩展，⽆论多⼤的数据量，只需轻松增加节点即可解决。 - ⾮分库分表，简化数据管理复杂度
应⽤⽆需再引⼊分库分表、应⽤级分布式事务等复杂技术栈，⽆需再引⼊额外的汇聚库处理汇总查询、多维查询等场景。 - 便捷式应⽤适配和业务能⼒提升
应⽤如何使⽤单体数据库⼀样使⽤TiDB，⽆需考虑底层数据管理细节。应⽤系统将更多的精⼒回归到业务功能的迭代，以提供更加敏捷、创新、扩展的服务。
3.5实时⻛控解决⽅案
在⾦融需求和⽣活场景不断融合的趋势下，实时⻛控的复杂度和对数据时效性的要求越来越⾼，通常需要秒级完成业务流程，并整合决策引擎、征信服务、额度系统、反欺诈系统、公安系统、联⽹检查、反欺诈等系统能⼒，提供统⼀的⻛控能⼒⼊⼝。
现有⽅案在实时⻛控领域⾯临的主要痛点有：
- 复杂的数据获取与加⼯，⻛控实时价值丧失，统⼀视图构建困难重重；
- 复杂数据处理技术栈，多处多地加⼯、数据割裂，丧失灵活性和扩展性。
TiDB实时⻛控（含监察）数据处理技术架构，在⼤数据场景下⻛控数据的存储及加⼯，实现⻛控数据价值的实时变现：
- 利⽤TiDB数据库CDC处理技术，结合Kafka和Flink等技术栈，实现将各业务系统最新产⽣的业务数据、外部监察类数据、本⾏及三⽅⻛控数据实时汇聚到统⼀的TiDB分布式数据库集群存储管理，提升数据实时获取能⼒；
- 基于TiDB⾼可⽤和弹性处理能⼒，可进⼀步对实时汇聚的⻛控相关数据进⾏聚合、汇总、分类，变量加⼯等处理，根据业务的诉求，提供实时⻛控或实时⼤屏展现的能⼒。
基于TiDB HTAP能⼒打造实时⻛控弹性架构
- 利⽤TiDB数据库海量数据存储能⼒，可以实现将⻛控系统智能信审模块、基础数据服务模块沉淀的⻛控业务、征信、反欺诈、联⽹核查等⻛控数据进⾏统⼀存储；
- 基于TiDB HTAP架构⾏存及列存混合处理引擎能⼒，可进⼀步对业务沉淀和实时汇聚的⻛控相关数据加⼯分析处理，形成可⽤于⻛控场景消费的价值数据；
- 基于TiDB的⾼并发能⼒，服务层将业务逻辑封装成标准的统⼀⻛控服务API，并提供统⼀的访问⼊⼝，打造实时⻛控（含监察类）弹性架构。
该⽅案的优势：
- 满⾜⼤数据场景下⻛控数据存储；
- 提供统⼀数据实时服务
通过流式数据接⼊可以实时汇总征信、三⽅、客户交易、监管⿊名单、联⽹核
查、反欺诈等数据，对数据进⾏聚合分析，形成⻛险数据集市。 - 降低技术架构实现的复杂性。
3.7 综合数据服务平台解决⽅案
⾦融⾏业传统数据服务按⾯向的群体划分为客户服务、运营管理两个维度。对客户服务部分通过OLTP类关系型数据库承载⾼并发、低延时特性的实时交易场景；对于运营管理类需求，通常基于⽂件交换或ETL技术，将对客部分的OLTP数据离线同步到下游的OLAP类分析型数据库，并通过⾯向主题的数据仓库模式，采⽤批处理对⼤数据进⾏复杂计算，将结果应⽤于⾯向经营分析的场景。
传统模式的特征是数据产⽣到处理时效性差、数据附加值低，难以应对移动互联
⽹、场景⾦融时代对于数据实时应⽤能⼒的诉求。数字化转型对数据服务模式带来的挑战包括：
- 多源、多分⽚的数据实时汇聚能⼒
- 多场景、多维度的灵活数据计算能⼒
- 基于持续变化数据的管理模式
- 动态的数据加⼯与更新
- 持续、及时、⾼效获取“新鲜数据”
- T+0实时数据服务化能⼒
基于TiDB的综合数据服务平台架构：
- 平台由数据采集、数据预处理、实时/离线数据存储、数据服务等功能组件，以及资产管理等运营组件构成；
- ⽀持多种采集⽅式，包括CDC、消息中间件+流式计算架构的实时⽅式，以及与离线数仓/⼤数据平台交互的ETL⽅式；
- 基于TiDB的弹性扩展、HTAP能⼒实现实时数据的集中存储和混合式处理，并与离线数仓形成有益的互补；
- 数据服务可基于TiDB实现基于标准SQL、⽆需考虑分⽚键的扩展性设计能⼒；
- 简化传统实时分析领域的技术栈，降低运维复杂性。
该⽅案的优势：
- 在线⽔平扩展和弹性伸缩能⼒
- 微服务、单元化架构下的数据实时汇聚和消费能⼒
- HTAP架构兼顾实时分析领域的⾼并发访问和交互式分析诉求
4、与传统单机数据库的⽐较
与传统的单机数据库相⽐，TiDB 具有以下优势：
- 两者都支持ACID、事务强一致性
- 纯分布式架构，拥有良好的扩展性，⽀持弹性的扩缩容
- ⽀持 SQL，对外暴露 MySQL 的⽹络协议，并兼容⼤多数 MySQL 的语法，在⼤多数场景下可以直接替换 MySQL
- 默认⽀持⾼可⽤，在少数副本失效的情况下，数据库本身能够⾃动进⾏数据修复和故障转移，对业务透明
- ⽀持 ACID 事务，对于⼀些有强⼀致需求的场景友好，例如：银⾏转账
- 具有丰富的⼯具链⽣态，覆盖数据迁移、同步、备份等多种场景
- 采用水平扩展，在大数据量、高吞吐的业务场景中具有先天优势
- 强项不在于轻量的简单SQL，而在于大量高并发SQL的吞吐
- 传统的分布式，扩展，就是经常说的分库分表。最大的弊端就是肯定需要在app层定制分片策略，例如操作的时候一定要指定分片键
- 而对于TiDB则对于app层不需要做 分片策略，它的数据分分布在不同的Region中（类似传统的sharding ），TiDB能告诉应用数据在哪。
5、TiDB的内核模块(了解，后续详解)
5.1、整体架构
- TiDB 整体架构：TiDB Server、TiKV、TiFlash、PD
在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下
- TiFlash 是 TiKV 的列存版本，并参与复制，保持数据一致
- PD（Placement Driver） 节点记录数据在哪些 TiKV 或 TiFlash 节点上，以及全局时间戳（TSO），还会配合 TiDB Server 生成事务的唯一ID
- 数据分区（Region）存储（96~144mb），默认三副本，一个 leader 负责读写，另两个读96mb 后 Region 里就不会新插入数据了，但可能会修改已有的数据，所以 region 大小是 96~144mb 一个区间
- 兼容 MySQL 5.7 协议
- TiKV = Transaction + MVCC + Raft + rocksdb raft + rocksdb kv
- 分布式事务是两阶段提交。两阶段提交的锁信息被持久化到 TiKV 中。
- PD 会收集集群信息进行调度，达到平衡数据的效果
- TiKV 承载 OLTP 业务，TiFlash 承载 OLAP 业务，达到业务隔离。TiDB Server 根据 SQL 进行预测，智能选择使用 TiKV 还是 TiFlash 进行查询，也可以人工指定
- TiDB Server 是无状态的，不存储数据。支持扩展，缓解连接压力
- TiDB Server 会解析，编译，优化 SQL 语句，生成执行计划；同时会负责将关系型数据转化为 KV 存储进行持久化，以及将 KV 存储转化为关系型数据返回给客户端
- 对于历史版本数据的垃圾回收，是由 TiDB Server 在 TiKV 上完成的
- 数据在TiKV中是以键值对（KEY-VALUE）形式存储的
5.2、行记录映射到KV
key的形式：
tablePrefix{TableID}_recordPrefixSep{RowID}
表数据与KV的映射:
- 1,“TiDB”,“SQL Layer”,10:t10_r1 --> [“TiDB”,“SQL Layer”,10]
- 2,“TiKV”,“KV Engine”,20:t10_r2 --> [“TiKV”,“KV Engine”,20]
- 3,“PD”,“Manager”,30:t10_r3 --> [“PD”,“Manager”,30]
这个 (1,“TiDB”,“SQL Layer”,10) 是关系型数据库当中存放的的一条记录。
在TiDB当中，它会变成t10_r1 --> [“TiDB”,“SQL Layer”,10] ，具体的行作为value
它的key(t10_r1)，实际上是由 t:是固定的。10：是当前插入某个表的全局唯一id，就是Table ID，这个TableID会从PD(大脑)中来取。 r: 记录前缀，1：这个行的id rowid,1就表示第一行。
通过key-value的方式存储到TiKV当中。
5.3、存储节点
- TiKV Server：负责存储数据，从外部看 TiKV 是⼀个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region，每个 Region 负责存储⼀个 Key Range（从 StartKey 到 EndKey的左闭右开区间）的数据，每个 TiKV 节点会负责多个 Region。TiKV 的 API 在 KV 键值对层⾯提供对分布式事务的原⽣⽀持，默认提供了 SI (Snapshot Isolation) 的隔离级别，这也是 TiDB 在SQL 层⾯⽀持分布式事务的核⼼。TiDB 的 SQL 层做完 SQL 解析后，会将 SQL 的执⾏计划转换为对TiKV API 的实际调⽤。所以，数据都存储在 TiKV 中。另外，TiKV 中的数据都会⾃动维护多副本（默认为三副本），天然⽀持⾼可⽤和⾃动故障转移。
TiKV实际上是一个集群，在集群当中有很多TiKV很多服务器，对于分布式系统而言，需要多台服务器 让数据可以实现高性能和高可用的访问。
数据是如何保存的，副本是如何同步的。
首先数据会转变成kv 键值对的形式进行存储。存储在TiKV Map中（这个单元非常大）。 在这个map里面保存了所有kv键值对。
raft group：raft共识算法， 集群的目的是为了数据访问的性能和高可用，采用raft算法，它会选择某一台服务器作为leader，leader会将数据同步到flower 服务器中。这条记录在其他flower 服务器上同步成功后，才意味着这条数据写入成功。 好处：一条数据在三个节点上有副本，在查询它的时候，可以在不同的服务器并行的读。 另外一个flower出现故障，并不会影响这条数据的访问。 当然如果leader挂掉了，会有影响，需要在剩下的flower中选举出一个新的leader，通过它完成数据的写入，同步。 数据的副本（以region为单位） 它会在一个 Raft group当中进行同步，如果它里面有一个leader 两个flower
副本的同步，细粒度应该设置多少合适，一条KV就同步一次（在kv层），则会非常频繁，显然是不合适的。 但如果将整个TiKV Map作为副本的同步，则存在太大的问题，因为所有数据都在里面。 这个时候就有一个Region的概念，region 它默认大小是96M
节点间同步的单位就是一个Region。 region 会根据key的字节序列进行排序，然后放到region。 region不会像一个kv键值对粒度那么小，也不会像Map那么大。
RocksDB: 它作为存储引擎，将对应的数据落盘到TiKV server中。
- TiFlash：TiFlash 是⼀类特殊的存储节点。和普通 TiKV 节点不⼀样的是，在TiFlash 内部，数据是以列式的形式进⾏存储，主要的功能是为分析型的场景加速。
这些数据会存放在多个 TiKV的region中。此时 region 1 、 region 2 、 region 3 < 这1 2 3说的是对应 region的leader>当中都有category_id=1的数据 。 当然这些是region 在其他TiKV有对应的flower。
这涉及到一个并行的操作
TiDB Server 得知道这些数据是在哪些TiKV Region当中（通过询问PD）.
然后将这些数据在这些不同的TiKV上执行， 这些动作是在TiKV server上。（图片右边）。 然后在对应TiKV上得到对应结果。 例如 region1 上得到2条， region2 上得到3 条， region3 得到5条。
然后将这些数据 交给TiDB Server上，TiDB Server上进行汇总。
其实具体的操作，脏活累活 是交给TiKV Server处理，TiDB是将结果进行汇总。第二步 进行过滤
5.4 PD (Placement Driver) Server
整个 TiDB 集群的元信息管理模块，负责存储每个 TiKV 节点实时的数据分布情况和集群的整体拓扑结构，提供 TiDB Dashboard 管控界⾯，并为分布式事务分配事务ID。PD 不仅存储元信息，同时还会根据 TiKV 节点实时上报的数据分布状态，下发数据调度命令给具体的 TiKV 节点，可以说是整个集群的“⼤脑”。此外，PD 本身也是由⾄少 3 个节点构成，拥有⾼可⽤的能⼒。建议部署奇数个 PD 节点。（也是采用Raff 协议 leader flower）
