1.TIDB和MySQL对比
|------------|-----------------------------------------------------------------|------------------------------------------------|
| 对比内容 | MySQL | TiDB |
| 架构设计 | 一个传统的单机数据库系统，采用主从复制和分区表等方式来实现水平扩展 | 一个分布式的 NewSQL 数据库，采用分布式存储和分布式事务等技术，支持水平扩展和高可用性 |
| 事务支持 | InnoDB 存储引擎来支持事务处理，支持 ACID 特性 | 支持 ACID 特性，并在分布式环境下提供了分布式事务的支持 |
| 水平扩展 | 水平扩展能力较弱，通常通过主从复制和分区表等方式进行扩展 | 通过简单地增加节点来实现水平扩展，支持自动数据分片和负载均衡，适合大规模数据存储和处理 |
| 一致性 | 一致性依赖于配置和复制机制，可能存在数据同步延迟或数据不一致的情况 | 基于 Raft 算法实现了多副本之间的强一致性，确保数据的一致性和可靠性 |
| SQL兼容性 | 关系型数据库的代表，支持标准的 SQL 语法 | 兼容 MySQL 协议和 SQL 语法，使得迁移和使用更加方便 |
| 自动化运维 | TiDB Ansible 工具和 TiDB Lightning 等工具，支持快速部署、备份恢复和在线迁移等功能，简化了运维管理 | 借助第三方工具或脚本来实现自动化运维 |
| 存储引擎 | 支持多种数据存储引擎，如InnoDB、MyISAM等 | 使用TiKV作为默认的数据存储引擎，TiKV是一种基于RocksDB的分布式键值存储引擎 |
小结：TiDB 是一种分布式的 NewSQL 数据库，具有水平扩展、高可用性和分布式事务支持等特点，适合处理大规模数据和高并发的场景。而 MySQL 则是一种传统的关系型数据库系统，适用于中小型应用和对事务一致性要求不是特别高的场景。选择使用哪种数据库取决于具体的业务需求和技术架构
2.什么是TiKV
TiKV 是一个分布式事务型的键值数据库，提供了满足 ACID 约束的分布式事务接口，并且通过 Raft 协议 保证了多副本数据一致性以及高可用。TiKV 作为 TiDB 的存储层，为用户写入 TiDB 的数据提供了持久化以及读写服务，同时还存储了 TiDB 的统计信息数据。
2.1 TiKV整体架构
与传统的整节点备份方式不同，TiKV 参考 Spanner 设计了 multi-raft-group 的副本机制。将数据按照 key 的范围划分成大致相等的切片（下文统称为 Region），每一个切片会有多个副本（通常是 3 个），其中一个副本是 Leader，提供读写服务。TiKV 通过 PD 对这些 Region 以及副本进行调度，以保证数据和读写负载都均匀地分散在各个 TiKV 上，这样的设计保证了整个集群资源的充分利用并且可以随着机器数量的增加水平扩展。
2.2 Region 与 RocksDB
虽然 TiKV 将数据按照范围切割成了多个 Region，但是同一个节点的所有 Region 数据仍然是不加区分地存储于同一个 RocksDB 实例上，而用于 Raft 协议复制所需要的日志则存储于另一个 RocksDB 实例。这样设计的原因是因为随机 I/O 的性能远低于顺序 I/O，所以 TiKV 使用同一个 RocksDB 实例来存储这些数据，以便不同 Region 的写入可以合并在一次 I/O 中。
2.3Region 与 Raft 协议
Region 与副本之间通过 Raft 协议来维持数据一致性，任何写请求都只能在 Leader 上写入，并且需要写入多数副本后（默认配置为 3 副本，即所有请求必须至少写入两个副本成功）才会返回客户端写入成功。
当某个 Region 的大小超过一定限制（默认是 144MB）后，TiKV 会将它分裂为两个或者更多个 Region，以保证各个 Region 的大小是大致接近的，这样更有利于 PD 进行调度决策。同样，当某个 Region 因为大量的删除请求导致 Region 的大小变得更小时，TiKV 会将比较小的两个相邻 Region 合并为一个。
当 PD 需要把某个 Region 的一个副本从一个 TiKV 节点调度到另一个上面时，PD 会先为这个 Raft Group 在目标节点上增加一个 Learner 副本（虽然会复制 Leader 的数据，但是不会计入写请求的多数副本中）。当这个 Learner 副本的进度大致追上 Leader 副本时，Leader 会将它变更为 Follower，之后再移除操作节点的 Follower 副本，这样就完成了 Region 副本的一次调度。
Leader 副本的调度原理也类似，不过需要在目标节点的 Learner 副本变为 Follower 副本后，再执行一次 Leader Transfer，让该 Follower 主动发起一次选举成为新 Leader，之后新 Leader 负责删除旧 Leader 这个副本。
2.4 分布式事务
TiKV 支持分布式事务，用户（或者 TiDB）可以一次性写入多个 key-value 而不必关心这些 key-value 是否处于同一个数据切片 (Region) 上，TiKV 通过两阶段提交保证了这些读写请求的 ACID 约束，详见 TiDB 乐观事务模型。
2.5 计算加速
TiKV 通过协处理器 (Coprocessor) 可以为 TiDB 分担一部分计算：TiDB 会将可以由存储层分担的计算下推。能否下推取决于 TiKV 是否可以支持相关下推。计算单元仍然是以 Region 为单位，即 TiKV 的一个 Coprocessor 计算请求中不会计算超过一个 Region 的数据。
3.什么是RocksDB
RocksDB是一个高性能、可扩展、嵌入式、持久化、可靠、易用和可定制的键值存储库。它采用LSM树数据结构，支持高吞吐量的写入和快速的范围查询，可被嵌入到应用程序中，实现持久化存储，支持水平扩展，可以在多台服务器上部署，实现集群化存储，具有高度的可靠性和稳定性，易于使用并可以根据需求进行定制和优化。它广泛应用于互联网公司和数据密集型应用中。RocksDB使用了许多技术来实现其高性能和可靠性。
3.1 RocksDB主要的技术点
3.1.2 LSM树
LSM树（Log-Structured Merge Tree）是一种基于日志结构的数据结构，能够高效地存储和更新键值数据。它将数据分为多个层，每一层都是一个有序的键值存储文件，其中较旧的数据位于较低的层，较新的数据位于较高的层。当数据被写入时，它首先被写入到一个内存中的结构，称为内存表（MemTable），然后在后台异步地将内存表与磁盘上的某个层合并，最终生成新的文件。这种设计使得RocksDB能够高效地处理大量写入操作，并支持快速的范围查询。
3.1.2 压缩
RocksDB使用了多种压缩算法来压缩数据文件，减小了磁盘空间的占用，提高了存储效率。压缩算法包括LZ4、Snappy、Zlib等。
3.1.3 并发控制
RocksDB使用多种技术来实现并发控制，以支持高并发读写操作。例如，它使用锁、读写锁、CAS等机制来保证多线程并发的正确性和一致性。
3.1.4 内存管理
RocksDB使用了多种技术来管理内存，以保证高效的内存使用和低延迟的响应。例如，它使用了对象池、内存池等技术来减少内存分配和释放的开销，使用了缓存技术来缓存热点数据，使用了内存映射技术来快速加载数据文件等。
3.1.5 日志系统
RocksDB使用了可插拔的日志系统，可以将日志输出到不同的目标，例如文件、控制台、网络等，以支持不同的日志需求。
3.1.6 文件格式
RocksDB使用了一种自定义的文件格式，可以高效地存储键值数据，并支持快速的数据访问和查询。这种格式将数据划分为多个块，每个块包含多个键值对，每个块都有一个索引来支持快速的查找和范围查询。
