1 TiDB

1.1 产品简介

TiDB是Ping CAP公司的自主设计、研发开源的分布式开源数据库，是一款支持在线处理与在线分析处理的融合性分布式数据库产品，具备水平扩容，金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。

1.2 与Mysql的对比

  1. mysql是由瑞典mysql AB公司开发，TiDB是由北京PingCAP开发
  2. 事务更新机制的不同
  1. tidb数据库：采用乐观锁机制保证事务的一致性和持久性；
  2. mysql：采用redo log保证事务的一致性和持久性；

        更新数据上，mysql会首先获取到某条记录的行级锁（排它锁），获取成功后，进行事务操作，获取失败则阻塞等待（变相将并行事务从逻辑上进行串行化）；

        TiDB遵循Percolater的事务模型，可以理解为乐观锁实现事物的开启，事务上都不会进行加锁，而是在提交时才会加锁。下文会有TSO（时间戳的概念），保证并行事务有先后顺序。

Percolater的事务模型：Google发表在OSDI 2010上的论文Large-scale Incremental Processing Using Distributed Transactions and Notifications中介绍的事务模型；

Percolater事务模型有以下特点：

  1. 为增量处理定制
  2. 处理结果强一致性
  3. 针对大数据量
  4. 提供了跨行跨表的基于快照隔离级别的ACID的事务（默认级别，事务只能看到在它开始事务之前的数据）
  5. 去中心化锁管理，基于单行的事物上，实现了跨行事务；

2 TiDB分布式数据整体架构

tidb和MySQL的性能 tidb对比_tidb和MySQL的性能

        TiDB遵循Mysql的协议，则项目可以无缝的将Mysql数据库切换到TiDB，正常情况下我们执行Sql语句，都是通过tidb sever进行解析优化，生成TiKV可以执行的语句，TIDB server 相当于sql层面的转换工具，本身不存储数据。而pd cluster则相当于TiDB的大脑，存放一些系统相关的信息，当进行数据存储的时候，tidb server 会向pd申请data location确定数据存放在具体的哪一个TI KV上，而data localtion就是这条数据的基本信息，而tso是保证数据强一致性（时间快照），每次进行操作的时候，pd cluster会维护一个一直在更新的时间戳，不管事务如何的并发，pd cluster都会对事务进行一个先后的的排序，并且开启一次事务就会去pd cluster申请一个tso，数据存放在tikv的region（tikv的一个内存分区）里面，，region是TiKV map中一个小单元，默认为96M，为什么会存在region这个内存分区呢，如果事务的更新的粒度为 一条的数据时候，数据从leader到follwer的更新，这样会造成大量的网络IO次数，所以TiDB的最小更新单元就是region，减少网络IO的次数，这里有必要提到raft一致性协议，TiDB里面的server cluster、pd cluster 以及storage cluster（数据分区regino都是采用 raft协议保证数据一致性）

raft协议

raft一致性协议；

  • raft系统中所有的节点的数据最终一致
  • raft系统中大部分节点的日志状态实时一致

raft协议规定两种存储：

Log：raft采用先写日志，日志的写入是顺序的，效率较高，当raft的leader收到一个操作请求，首先将数据append到日志里面，然后再将其广播到集群

Replicated state machine（复制状态机）：保存的实际的数据，数据的读取都是从状态机中读取。

raft规定一个节点三个角色：

leader：服务客户端唯一的server，leader要不断的向fllower发送心跳包确保自己的leader的地位

candidata：临时角色，是由fllower临时转换而来，即当一个Follower节点在一定时间(Election timeout)没有收到Leader的心跳包，这个Follower就会转换为Candidate,发起投票选举自己为Leader, 如果它能获取到多数投票，它就会成为下一个任期（term）的Leader. 若不能，则有两种情况: 继续投票或转换角色为Follower。

Follwer：Follwer接收leader的日志复制，负责高可用，当leader挂掉的情况下，其中最先election timeout（选举超时）会推荐自己成为leader，TIKV选举超时的时间为10s，这样确保不会有两个candidata同时在选举

3 TiDB server 执行逻辑

tidb和MySQL的性能 tidb对比_mysql_02

TIDB server执行的过程：

        本身TIDB遵循mysql的语法以及Mysql协议，所以对外暴露的为mysql的语法，客户端只要执行mysql语法就能进行解析，server要负责客户端的连接，客户端发送sql语句，首先经过session context，判断有没有进行连接，然后将sql送到解析层，解析层要跟pd进行交互，取到dataLocation，然后生成一个抽象逻辑树（取到要查的基本信息），然后交给逻辑优化器，对sql语句进行优化以及改写，然后生成逻辑执行计划，然后交给物理优化器，此时会获取一些辅助信息，比如要去访问的表的数据条数以及数据的大小等，然后对其进行优化，生成一个更好的物理执行计划，然后交给本地执行器或者分布式执行器去执行查询，生成分布式sql，查询结果，然后将结果汇总。

4 TiDB事务的执行

        遵循Percolator事务模型执行过程，分为两个阶段，prewriter以及commit；