简介TiDB是PingCAP自主设计开发的开源分布式关系数据库。它是一种融合同时支持在线事务处理和在线分析处理（HybridTransactionalandAnalyticalProcessing，HTAP）的分布式数据库产品，具有水平扩展或缩减、金融级高可用、实时HTAP、云-原生分布式数据库，兼容MySQL5.7协议和MySQL生态。目标是为用户提供一站式OLTP（在线事务处理）、OLAP（在线分析处理）、HTAP解决方案。TiDB适用于高可用、强一致性要求高、数据规模大等多种应用场景。一键水平扩缩容：得益于TiDB的存储计算分离架构设计，可按需分别对计算和存储进行在线扩容或缩容，扩缩容过程对应用运维透明人员。金融级高可用：数据多副本存储，数据副本通过Multi-Raft协议与交易日志同步。只有大多数写入成功的事务才能被提交，保证数据强一致性和数据可用性不会在少数副本失败时受到影响。可按需配置地理位置、副本数等策略，满足不同容灾级别的需求。实时HTAP：提供两种存储引擎，行存储引擎TiKV和列存储引擎TiFlash。TiFlash通过Multi-RaftLearner协议实时从TiKV复制数据，保证行存储引擎TiKV和列存储引擎TiFlash之间的数据强一致性。TiKV和TiFlash可以根据需要部署在不同的机器上，解决HTAP资源隔离的问题。云原生分布式数据库：专为云端设计的分布式数据库。通过TiDBOperator，可以在公有云、私有云和混合云中实现部署工具和自动化。兼容MySQL5.7协议和MySQL生态：兼容MySQL5.7协议、MySQL常用功能和MySQL生态，无需或只需少量代码修改即可将应用从MySQL迁移到TiDB。提供丰富的数据迁移工具，帮助应用轻松完成数据迁移。与传统的单机数据库相比，TiDB具有以下优势：纯分布式架构、良好的扩展性、支持弹性伸缩。支持SQL，暴露MySQL网络协议，兼容绝大部分MySQL语法，在绝大部分场景下可以直接替代MySQL。默认情况下支持高可用性。在少数副本出现故障的情况下，数据库本身可以自动进行数据修复和故障转移，对业务是透明的。支持ACID事务，对一些一致性要求强的场景友好，比如银行转账。拥有丰富的工具链生态，覆盖数据迁移、同步、备份等多个场景。场景金融行业对数据的高一致性和高可靠性、系统高可用性、可扩展性和容灾需求的场景是众所周知的。金融行业要求数据一致性、高可靠性、高系统可用性、可扩展性和容灾性。更高的要求。传统方案是同城2个机房提供服务，异地1个机房提供数据容灾能力但不提供服务。该方案存在以下缺点：资源利用率低，维护成本高，RTO（RecoveryTimeObjective）和RPO（RecoveryPointObjective）无法真正实现企业预期的价值。TiDB使用多副本+Multi-Raft协议将数据分派到不同的机房、机架、机器。当部分机器出现故障时，系统能够自动切换，保证系统的RTO<=30s，RPO=0海量数据对存储容量、扩展性、并发性要求高，高并发OLTP场景随着业务的快速发展，数据呈爆发式增长，传统的单机数据库由于数据的爆发式增长已经不能满足数据库的容量需求，可行的方案是使用分库分表中间件产品或者NewSQL数据库代替，以及使用高端存储设备等。其中NewSQL数据库性价比最高，比如TiDB。TiDB采用了计算和存储分离的架构，可以分别对计算和存储进行扩容和缩容。计算最大支持512个节点，每个节点最大支持1000并发，集群容量最大支持PB级别。实时HTAP场景随着5G、物联网、人工智能的快速发展，企业将产生越来越多的数据，规模可能达到数百TB甚至PB级别。传统方案是使用OLTP数据库处理在线交易业务中，通过ETL工具将数据同步到OLAP数据库进行数据分析。该处理方案存在存储成本高、实时性差等诸多问题。TiDB在4.0版本引入列存储引擎TiFlash，并结合行存储引擎TiKV构建真正的HTAP数据库。在存储成本小幅增加的情况下，可以在同一个系统中进行在线交易处理和实时数据分析，大大节省了企业的成本。.数据汇聚二次处理场景目前，大部分企业的业务数据分散在不同的系统中，没有统一的汇总。随着业务的发展，企业的决策层需要了解整个公司的业务状况，以便及时做出决策，需要将分散在各个系统中的数据汇集到同一个系统中，并执行二次加工生成T+0或T+1报告。传统常见的解决方案是使用ETL+Hadoop来完成，但是Hadoop系统过于复杂，运维和存储成本过高，无法满足用户的需求。与Hadoop相比，TiDB要简单得多。业务通过ETL工具或TiDB的同步工具将数据同步到TiDB，通过SQL直接在TiDB中生成报表。架构在核心设计上，TiDB分布式数据库将整体架构拆分为多个模块，各个模块相互通信，形成一个完整的TiDB系统。对应的架构图如下：TiDBServer：SQL层，对外暴露MySQL协议的连接端点，负责接受客户端连接，进行SQL解析和优化，最终生成分布式执行计划。TiDB层本身是无状态的。在实践中，可以启动多个TiDB实例，通过负载均衡组件（如LVS、HAProxy、F5）对外提供统一的访问地址。客户端连接可以均匀分布在多个TiDB实例中。从而达到负载均衡的效果。TiDBServer本身不存储数据，只是解析SQL并将实际的数据读取请求转发给底层存储节点TiKV（或TiFlash）。PD（PlacementDriver）Server：整个TiDB集群的元信息管理模块，负责存储各个TiKV节点的实时数据分布和集群的整体拓扑结构，提供TiDBDashboard管控接口，以及为分布式事务分配事务ID。PD不仅存储元信息，还会根据TiKV节点上报的实时数据分布情况，向特定的TiKV节点发送数据调度命令，可以说是整个集群的“大脑”。另外，PD本身也是由至少3个节点组成，具备高可用能力。建议部署奇数个PD节点。TiKVServer：负责存储数据。从外部看，TiKV是一个提供事务的分布式Key-Value存储引擎。存储数据的基本单元是Region，每个Region负责存储一个KeyRange（从StartKey到EndKey的左闭右开区间）的数据，每个TiKV节点负责多个Region。TiKV的API在KV键值对层面原生支持分布式事务，默认提供SI（SnapshotIsolation）的隔离级别，这也是TiDB在SQL层面支持分布式事务的核心。TiDB的SQL层完成SQL解析后，会将SQL执行计划转化为对TiKVAPI的实际调用。因此，数据存储在TiKV中。另外，TiKV中的数据会自动维护多份（默认是三份），天然支持高可用和自动故障转移。TiFlash：TiFlash是一种特殊类型的存储节点。不同于普通的TiKV节点，在TiFlash内部，数据以列的形式存储，主要作用是加速分析场景。StorageTiKV并没有选择直接将数据写入磁盘，而是将数据保存在RocksDB中，由RocksDB负责具体的数据落地。之所以这样选择，是因为开发单机存储引擎需要做大量的工作，尤其是高性能的单机引擎，需要进行各种细致的优化。RocksDB是Facebook开源的一款优秀的单机KV存储引擎。可以满足TiKV对单机引擎的各种需求。这里可以简单的认为RocksDB是一个独立的持久化Key-ValueMap。TiKV使用Raft进行数据复制。每一次数据变化都会被记录为Raft日志。通过Raft的日志复制功能，将数据安全可靠地同步到复制组中的各个节点。但在实际写入时，根据Raft协议，只需要同步复制到大部分节点即可安全认为数据写入成功。综上所述，TiKV可以通过单机RocksDB将数据快速存储到磁盘；通过Raft，可以将数据复制到多台机器上，防止单机故障。数据通过Raft层接口写入，而不是直接写入RocksDB。通过实现Raft，TiKV成为一个分布式的Key-Value存储。即使几台机器宕机，也可以通过原生的Raft协议自动完成复制，可以做到业务无感知。事务TiDB支持分布式事务，提供乐观事务和悲观事务两种事务模式。对于TiDB3.0.8及之后的版本，TiDB默认采用悲观事务模式。TiDB可以显式（通过[BEGIN|STARTTRANSACTION]/COMMIT语句定义事务的开始和结束）或隐式（SETautocommit=1）使用事务。TiDB支持语句执行失败后的原子回滚。如果语句报错，则修改不会生效。事务将保持打开状态并且可以进行其他修改，直到发出COMMIT或ROLLBACK语句。由于底层存储引擎的限制，TiDB要求单行不超过6MB。您可以通过将一行的所有列根据类型转换为字节并将它们加在一起来估算单行的大小。TiDB同时支持乐观事务和悲观事务，其中乐观事务是悲观事务的基础。由于乐观事务首先在私有内存中缓存修改，因此TiDB限制了单个事务的容量。在TiDB中，默认单个事务的总大小不超过100MB。这个默认值可以通过配置文件中的配置项txn-total-size-limit修改，最大支持10GB。单个事务的实际大小限制还取决于服务器上剩余可用内存的大小。在执行一个事务时，TiDB进程的内存消耗相对于事务大小会有一定的放大，可能会达到提交事务大小的6倍以上。在4.0之前的版本中，TiDB限制了单笔交易的键值对总数不超过30万，从4.0版本开始，TiDB取消了这个限制。兼容性TiDB高度兼容MySQL5.7协议，以及MySQL5.7的常用函数和语法。MySQL5.7生态中的系统工具（PHPMyAdmin、Navicat、MySQLWorkbench、mysqldump、Mydumper/Myloader）、客户端等都适用于TiDB。但TiDB目前还不支持部分MySQL功能。可能的原因如下：有更好的解决方案，比如用JSON代替XML函数。这些功能目前需求量不大，例如存储过程和函数。有些功能在分布式系统上更难实现。另外，TiDB不支持MySQL的复制协议，但是提供了专门的工具来与MySQL进行数据复制。CopyfromMySQL：TiDBDataMigration(DM)是一个将MySQL/MariaDB数据迁移到TiDB的工具，可用于增量数据拷贝。复制到MySQL：TiCDC是一个通过拉取TiKV变更日志实现的TiDB增量数据同步工具，可以通过MySQLsink将TiDB增量数据复制到MySQL。
