9月16日，Distributed Cloud|2021寰球分布式云大会·上海站隆重召开。在寰球分布式云大会不懈布道下，云计算行业对分布式云的关注度愈发低落，以寰球分布式云联盟成员为代表，涌现出了大量分布式云技术和实际成绩，为分布式云计算倒退夯实了根底。
2021寰球分布式云大会为分布式云计算倒退再添弱小推力，本次大会共设有分布式云主题报告会、边缘云论坛、云原生专题论坛、分布式数据库论坛四大论坛，围绕分布式云、边缘算力、云原生、分布式架构等技术与实际开展。寰球分布式云联盟联结阿里云、腾讯云、Google Cloud、中兴通讯、京东云、安迈云、网心科技等国内外分布式云顶尖技术服务商，共话分布式云翻新新趋势，共谋云计算改革新将来，共享分布式云计算新红利！
在9月16日下午召开的云原生专题论坛上，腾讯云数据库专家工程师张远发表了题为《腾讯云TDSQL-C云原生数据库技术》的精彩演讲。
TDSQL-C简介
张远介绍说，TDSQL-C是腾讯云自研的新一代企业级云原生分布式数据库，通过五年的打磨，具备以下几个要害的个性：
可靠性。TDSQL-C基于共享存储的云原生架构，存储是多正本的，可能保证数据可靠性。同时可能做到即时回滚，任意工夫数据都牢靠。
极致性能。腾讯云对主备机读写性能做了全面优化，同时也依据不同规格做针对性优化。
可用性。TDSQL-C能够做到秒级的RTO，故障简直无感知，同时主备提早能够做到毫秒级。此外，基于共享内存，数据可能疾速复原、疾速预热。
弹性扩大。数据可能疾速通明拓展，而且容量最大能够达到1PB，满足大的需要。
在总体架构上，TDSQL-C是基于共享存储的存储和计算拆散的架构。与传统的MySQL主备架构比照，能够看到传统的MySQL主备通过binlog进行逻辑复制，而TDSQL-C是通过redo日志进行的物理复制；传统的MySQL须要向存储写多份数据包含data，binlog，redo log等， 而TDSQL-C只需向存储写一份redo日志即可；传统的MySQL主备各存储一份数据，而TDSQL-C基于共享存储只有一份数据。
TDSQL-C内核关键技术
张远演讲的第二局部会围绕要害个性开展，具体介绍了TDSQL-C个性背地的技术原理和细节。
TDSQL-C之高性能。
TDSQL-C 高性能-plan cache
TDSQL-C 高性能的一个重要优化是实现了查问打算缓存，称之为plan cache。
图中展现了一条SQL在数据库中的执行过程，会通过以下几个阶段：
首先MySQL server承受到用户的SQL申请，在parse阶段解析为逻辑的执行打算树；接下来在查问优化阶段生成物理的查问打算；而后执行器从存储引擎获取数据进行计算。
通过plan cache优化后，一条SQL执行过程省略了后面的解析和查问优化阶段，SQL的执行工夫大大缩短了。
优化成果以sysbench场景为例，不同色彩代表不同阶段的耗时，能够看到通过plan cache优化后，parse和查问优化工夫缩小了，性能晋升了70%左右。
TDSQL-C高性能-异步组提交
TDSQL-C是计算和存储拆散的架构，因而计算节点和存储节点之间的网络IO存在肯定时延。而写事务提交时须要保障redo先刷盘能力实现提交，因而Redo日志刷盘存在网络IO。TDSQL-C在线程池的根底上进行了异步组提交优化，事务提交交给后盾线程异步实现，将线程池资源提前开释从而可能去解决更多的申请。优化后整体的读写事务QPS有70%的晋升。
TDSQL-C 高性能-Log Compaction
TDSQL-C是基于日志的数据库，计算机节点和存储节点之间有日志的传输，同时Master节点和TXStore存储之间也有redo日志传输，TDSQL-C将redo日志进行了压缩。
下图是redo日志的构造，一条一般的redo日志包含日志头和日志内容，日志头次要包含日志类型以及Space ID和pageno等信息。通常状况下日志头占了日志的较大一部分。TDSQL-C对redo日志进行压缩存储，对于同一页面进行批改的多条redo日志能够共享一个日志头。优化后redo日志量减少了30%。
TDSQL-C之高可用
TDSQL-C 高可用-物理复制
传统的MySQL的是通过binlog进行复制的。Binlog复制是在MySQL server层进行的，binlog记录的是逻辑的批改记录，binlog在备库apply须要通过server层的parser,optimizer后再通过engine的btree查找能力批改到对应的记录。这个门路比拟长，复制速度慢。
而腾讯云TDSQL-C采纳的是redo物理复制。Redo日志记录的是页面物理批改记录，redo复制是在engine层进行的，备库apply redo日志不须要查找就能够间接定位到页面，在内存中实现页面的批改。因而复制速度快。
更重要的一点是，TDSQL-C是基于共享存储的，主备数据物理上是统一的，而binlog复制只能保障逻辑统一。
TDSQL-C 高可用-备库提早优化
TDSQL-C高可用另一个优化是备库提早优化，TDSQL-C最多反对16个备库提供读服务，备库提早能够达到毫秒级别。其中一个优化就是备库读写IO抵触优化。TDSQL-C备库是提供读服务的，同时备库也会apply主库传来的redo日志。
张远以场景举例说，首先用户读取pageA，pageA不在buffer pool中，那么会从TXStore中申请pageA，TXStore中申请pageA就存在网络和IO的开销。同时redo日志回放线程上有log1/log2/log3正在期待回放到pageA上。也就是说，用户发动的读操作可能阻塞redo日志回放线程，从而导致主备提早。
优化计划是将pageA上的redo日志缓存到page上的链表中，pageA IO实现当前再将链表中的redo日志回放到pageA上。这样pageA的IO过程就不阻塞redo的回放了。
TDSQL-C 高可用-独立buffer pool
TDSQL-C 高可用的另一个优化是独立buffer pool。Buffer pool是InnoDB数据页的缓存。
计算节点HA重启后，buffer pool须要从新加载进行预热，持续时间比拟长，期间业务会受到较大影响。
TDSQL-C 将buffer pool从计算节点独立进去放到共享内存中，计算节点crash后buffer pool能够独立存在。这样一来，Buffer pool 不须要预热，重启工夫也缩短了。
TDSQL-C 高可用-秒级RTO
TDSQL-C在基于redo日志的架构下，计算节点crash recovery不须要apply redo，redo的apply由存储节点来实现。从而crash recovery工夫相比传统MySQL要快很多。在此基础上，TDSQL-C做了更多的优化，能够做到秒级RTO。例如通过测试，大规格实例重启速度比较慢，例如buffer pool为500G的大实例重启，初始化buffer pool耗时23秒，这对于用户来说是不可承受的。优化计划是并行初始化加pag上的mutex提早初始化。并行初始化是指按InnoDB buffer pool instance来并行初始化。而page mutex提早初始化，是指当page首次应用时才初始化，而不是在启动时全副都初始化。优化后buffer pool初始化速度晋升近20倍，而且腾讯云将这个计划也奉献给了MySQL官网。另外回滚段并行初始化也奉献给了MySQL官网。
TDSQL-C 之弹性扩大
TDSQL-C 备库能够提供读服务。为了提供更好的读服务，腾讯云做了许多读优化。Btree一致性读优化就是其中一个。
Btree在数据的更新过程中会产生SMO操作，即btree的决裂或合并。
如图所示，Btree发现决裂，page B决裂为pageB和pageC。Btree决裂时，用户查问pageB可能导致数据不统一甚至crash。但主库在Btree产生决裂时会通过index锁和page lock的形式保障正在产生决裂的page不被其余用户拜访。但对于备库来说，备库通过redo日志不能感知Btree的SMO操作，SMO操作所产生的日志只有页面批改的信息，redo日志中没有index lock上锁信息。因而备库在SMO过程是没有被爱护的，备库的查问可能异样。
这里有一个可选计划就是将SMO操作index lock记录到日志中，备库解析index lock日志对整个btree加index lock。但index lock会锁整个btree导致并发查问性能比拟差。
TDSQL-C对此进行了优化，MySQL的SMO操作是原子的，所有产生的redo日志都在一个mini-transaction中。引入新的日志类型来标记redo日志中SMO操作的边界。这样用户在查问btree过程遇到page在SMO操作从新扫描btree即可。例如用户拜访page A时会判断一下page是否在SMO，如果A在在mtr start和end之间则重试。
这样优化后，备库读不会被主库更新产生的SMO操作所阻塞。
TDSQL-C 其它个性
TDSQL-C 秒改列（instant modify column）
在官网MySQL8.0反对instant add column后，批改列类型操作便趁势成为MySQL中最不敌对的DDL类型，批改列类型既不是inplace的同时也须要rebuild table。而在咱们用户实际中，批改列类型也是用户执行比拟频繁的DDL之一，而此操作会长工夫阻塞用户的读写申请，对业务的影响十分大。
TDSQL-C翻新的反对了instant modify column性能，达到了秒级批改列的成果。
具体的实现形式是：
元数据多版本化, 表元数据保留列的多个版本信息，用户只能看到的总是最新的表元数据。
行记录减少版本信息对应到不同版本的表元数据上。
批改列只批改元数据，批改列的过程中不批改理论的行记录。
行记录读取时，老版本记录会主动转换为最新版本的记录。
行记录更新时，老版本记录会自动更新为最新版本的记录。
值得注意的是，这是业界独创的计划。
TDSQL-C purge预读
Undo 空间收缩问题是MySQL历史老大难问题，TDSQL-C翻新的通过purge预读解决了此问题。
Purge会读取undo page并清理delete mark的记录，清理实现后会开释undo page，从而最终开释undo表空间。
IO bound场景， purge时读取undo page更容易呈现remote IO。而remote IO时占用工夫比拟长，导致purge不及时undo日志空间收缩。
解决办法是实现purge预读机制：依据事务提交程序在内存中保留undo page的purge程序用于预读。Purge coordinator异步预读这些page。
TDSQL-C瞻望
瞻望TDSQL-C的将来倒退，张远示意，将来TDSQL-C会进一步增强查问优化的能力，比方减少新的join类型如SMJ， 以及在parallel query上做一些拓展。同时TDSQL在反对多写方面会进一步摸索，将来TDSQL-C也会向HTAP方向演进，TDSQL-C会同时具备OLTP和OLAP的能力。