关于TDSQL(MySQL)的简单知识分享

0. 前言

近来在系统改造过程中，接触到了国产分布式数据库TDSQL，记载一下关于TDSQL的部门知识点。
1. TDSQL简介

TDSQL是腾讯推出的一款兼容MySQL的自主可控、高划一性分布式数据库产品。
1.1 TDSQL长处：

• 数据强划一性
  
• 高性能低成本
  
• 线性水平扩展
  
• 金融级高可用
  
• 企业级安全性
  
• 便捷的运维
  

1.2 TDSQL系统总览

• 资源池：TDSQL部署的服务器资源。
  
• 存储节点：存储节点要强调的是TDSQL的两种存储形态，一种是Noshard数据库，一种是分布式数据库（也叫Shard版TDSQL）。简单来说，Noshard就是一个单机版的TDSQL，在MySQL的基础上做了一系列的改造和改良，让它支持TDSQL的一系列特性，包罗高可用，数据强划一、7×24小时自动故障切换等。第二种是分布式数据库，具备水平伸缩能力。以是TDSQL对外着实出现了两种形态，出现一种非分布式形态，一种是分布式的形态。
  
• 计算节点：计算节点就是TDSQL的计算引擎，做到了计算层和存储层相分离。计算层紧张是做一些SQL方面的处置惩罚，好比词法解析、语法解析、SQL改写等。假如是分布式数据库形态，还要做分布式事务相关的协调。
  
• 赤兔运营管理平台 ：通过这个平台，DBA可以使用TDSQL后台黑盒，以是相当于是一套WEB管理系统。让所有DBA的操纵都可以在用户界面上完成，而不必要登陆到后台，管理节点的操纵可以通过界面化完成。
  
• “扁鹊”智能DBA平台：扁鹊智能DBA平台还有一个智能诊断系统，可以定期由DBA发起对实例进行的诊断。
  

1.3 TDSQL架构模块及其特性

首先用户的请求通过负载均衡发往SQL引擎。然后，SQL引擎作为计算接入层，根据这个SQL的要求从后端的存储节点去取数据。固然，无论是SQL引擎还是后端的数据库实例都存在一个元数据来管理调治。举个例子，计算引擎必要拿到一个路由，路由告诉SQL引擎，这个SQL该发往哪一个后端的数据节点，到底是该发往主节点还是发往备节点。TDSQL引入了ZK（Zookeeper）来储存类似于路由这类元数据信息。固然ZK只是静态的存储元数据，维护和管理这些元数据信息，还必要有一套调治以及接口组件，这里是OSS、Manager/Schedule。这张图可以看到是TDSQL整体来说就分为三部门：管理节点、计算节点和存储节点。固然这里还有一个辅助模块，资助完成一些个性化需求的，好比备份、消息队列，数据迁移工具等。别的，这里的负载均衡着实不是必需的，用户可以选用自身的硬件负载，也可以用LVS软负载，这个负载均衡根据现实的用户场景可自定义。
2. 模块划分

2.1 管理模块

作为一个集群只搭建一套的管理模块，一般可以复用一组呆板。
首先，DBA用户在赤兔管理台——这一套WEB前台发起一个操纵——点了一个按纽，这个按纽大概是对实例进行扩容，这个按纽会把这个https的请求转移到OSS模块，这个OSS模块有点像web服务器，它能接收web请求，但是它可以把这个转发到ZK。以是，OSS模块就是一个前端到后台的桥梁，有了OSS模块，整个后台的工作模块都可以跟前台、跟web界面绑定在一起。
捕捉到这个请求之后，在ZK上创建一个使命节点，这个使命节点被调治模块捕捉，捕捉之后就处置惩罚使命。处置惩罚完使命，再把它的处置惩罚效果返回到ZK上。ZK上的使命被OSS捕捉，最后也是https的请求，去查询这个使命，最后得到一个效果，返回给前端。
这是一个纯异步的过程。
2.2 DB模块

DB模块，即数据节点，数据存取服务属于IO麋集型的服务，因此，数据节点是TDSQL的存储节点，它对IO的要求比力高。
SET就是数据库实例，一个SET包含数据库的主从节点。
模块Agent，它来完成对所有集群对MySQL的操纵，并且上报MySQL的状态。
2.3 SQL引擎模块

SQL引擎处于计算层的位置，本身属于CPU麋集型，以是在选机型上只管要求CPU高一些。其次是内存，作为计算接入层，它要管理链接，假如是大量的短链接或者长链接，非常占内存，以是它对CPU和内存的要求比力高。此外，它本身不存储数据，也没有主备之分。
SQL引擎要处置惩罚分布式事物，还要维护全局自增字段，保证多个数据、多个存储节点共享一个保证全局自增的序列；假如是分布式的话，要限制一些语法，包罗词法和语法的解析；还有在一些复杂计算上，它还要做一些SQL下推，以及最后数据的聚合。
2.4 TDSQL主备数据复制

mysql主备数据复制实现方式：

• 异步复制：主机在不等从机应答直接返回客户端乐成。
  
• 半同步：主机在一定条件下等备机应答，假如等不到备机应答，它还是会返回业务乐成，也就是说它最终还会退化成一个异步的方式。
  
• 全同步机制：当主库提交事务之后，所有的从库节点必须收到，APPLY并且提交这些事务，然后主库线程才气继续做后续操纵。
  

TDSQL引入了基于raft协议的强同步复制，主机接收到业务请求后，等待其中一个备机应答乐成后才返回客户端乐成。
有点类似把半同步的基础上把这个超时时间改成无穷大同时应答的备机设置为1，但是TDSQL强同步复制的性能是在原生半同步的基础上做了大量的优化和改进，使得性能根本靠近于异步。
2.5自动容灾切换

SQL引擎将请求发给主节点，主节点被两个备机所同步，每个节点上都有对应的Agent上报当前节点的状态。这时，主节点发生了故障被Agent觉察，上报到zk被Scheduler捕捉，然后Scheduler首先会把这个主节点进行降级，把它变成Slave。也就是说此时着实整个集群里面全是Slave，没有主节点。这个时候别的两个存活的备机上报本身最新的binlog点，由于有了强同步的保障，别的两个备机其中之逐一定有最新的binlog，那么两个备机分别上报本身最新的点后，Schedule就可以清楚的知道哪个节点的数据是最新的，并将这个最新的节点提升成主节点。
容灾切换必要建立在强同步的基础上。
2.6 数据强划一性

好比说A节点作为主节点，B、C是从，正常去同步A节点的数据，A+1、A+2，接下来该同步A+3。当A+3还没有同步到从节点的时候发生了故障，这个时候根据B、C节点的数据情况，C的数据是最新的，因此C被选成了主节点，进而C继续同步数据到B。过了一阵，A节点拉起了，可以重新加入集群。重新加入集群之后，发现它有一笔请求A+3还没有来得及被B、C节点应答，但已经写入到日记。这个时候着实A节点的数据是有问题的，我们必要把这个没有被备机确认的A+3的回滚掉，防止它将来再同步给其他的节点。
3. 分表

3.1 分表

shardkey——是TDSQL的分片关键字，也就是说TDSQL会根据shardkey字段将这个数据去分散。

3.2 水平拆分

对于分布式来说，大概最初我们所有的数据都在一个节点上。当一个节点出现了性能瓶颈，必要将数据拆分。
3.3 分布式事务

分布式事务也是根据shardkey来判断，具体来说，对于SQL引擎读发起一个事务，好比第一条SQL是改用户ID为A的用户信息表。第二条SQL是插入一个用户ID为A的流水表，这两张表都以用户ID作为shardkey。假如这两条SQL都是发往一个分片，固然是一个开启的事务，但是发现它并没有走分布式事务，它现实还是限制在单个分片里面走了一个单节点的事务。固然假如涉及到转帐：好比从A帐户转到B帐户，正好A帐户在第一个分片，B帐户是第二个分片，这样就涉及到一个分布式事务，必要SQL引擎完成整个分布式事务处置惩罚。
TDSQL分布式事务长处：

3.4 分布式总结

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。