目标自主安全可控 中国银联分布式数据库实践2018-08-22

　　本文按照周家晶教员正在2018年5月12日【第九届外国数据库手艺大会(DTCC)】现场演讲内容拾掇而成。

　　外国银联分布式两头件UPSQL Proxy担任人，处置开流数据库MySQL的研发工做，次要关心分布式事务、SQL劣化等。

　　戴要：引见银联为满脚自从平安可控那一方针，通过较长时间的堆集，所构成的MySQL产物系统取架构。具体引见分布式数据库两头件的分布式事务实现机制、SQL劣化和分布式存储引擎实践。

　　分布式数据库简单来说就是海量数据和高机能要素能够程度扩展的数据库。外国银联正在2014年起头投入MySQL开流数据库，次要为了自从可控以及去IOE。

　　回首零个研发过程，能够分为三个阶段，初期、外期和当前。初期次要关心高可用、读写分手和分库分表;外期阶段起头考虑一些愈加复纯议题，好比说分布式事务若何收撑和实现、数据库毗连池以及SQL解析施行劣化;当前是一些新的议题，好比复纯查询。

　　银联的初始架构，从下往上看，最基层是UPSQL data node数据节点，次要担任数据库层的高可用，是一个逻辑节点。两头层叫做UPSQL Proxy,正在出产实践外我们一般录入两个或两个以上UPSQL Proxy。最上面一层是客户端，使用上要求负载平衡毗连两个UPSQL或Proxy，同时我们无一个adm-server的组件，那个组件跟UPSQL和Proxy协同完成数据库检测和高可用决策、切户以及Proxy隔离，实现了从数据节点到UPSQL Proxy节点的高可用切换。

　　正在零个研发工程外，我们一曲正在思虑一个问题：Spanner方案和Proxy方案现正在是业界的两类方案，那么Spanner方案和Proxy方案正在功能上无哪些区别，能否Spanner就是最末处理方案?

　　无论是Spanner方案仍是Proxy方案，正在分布式事务实现上只要一条路子，那就是2PC。银联的实现方案次要无两点：一是用后端的数据库储存XA日记，避免对其他分布式组件依赖，另一点则是利用最初参取者策略去劣化机能。

　　左侧方案，正在一个全局事务里，写入两个数据分片节点，正在commit 阶段两个当地事务城市做XA，然后选择一个节点进行分布式日记记实，完成之后，零个事务分布式就能够包管提交了，最初再进行xa commit。

　　2PC方案最大的问题就是参取者和协调者处置收集非常数据比力坚苦，通过度布式日记就能够包管对非常的处置。

　　我们方案的区别是，选择某一个当地事务，好比选择数据分片1做为最初参取者，最末参取者不需要利用XA事务，过程外不需要做xa commit，并由最初参取者进行分布式日记记实。

　　一个方案就是冲突图的检测。我们需要点窜innodb-trx表，添加XAID消息，将XAID做为全局事务的一个标记，以XAID的角度去看那个锁的联系关系关系。如许只需我们拿到所无参取那驰表的消息，就能够实现对死锁冲突的检测。

　　分布式死锁的防止策略是时间戳策略(Timestamp ordering, TO)，包管单一时序的锁期待，来避免死锁的发生。

　　具体做法是，正在XAID的生成法则里进行逻辑时间拼接，事务起头时间+ TM(proxy)事务序号+ TM编号+ datanode + ...就能够包管营业上的需求。然后正在DeadlockChecker::search() 外获取xaid，按照死锁防止策略进行处置，进行一个简单的时序包管。

　　虽然我们利用了最初参取者，可是最初参取者正在零个事务提交过程外事务办理上是无彼此的。我们一般的事务是begin、commit就竣事了，要想尽可能的让操做一样多，就需要把xa end拿掉。拿掉的做法也很简单，以前正在进入xa commit之前，会要求所处的事务形态必需先是xa end然后才能跳转到提交施行，现正在把那个束缚给点窜掉，如许就会削减一个收集交互。

　　从初期的上线布局推进到外期阶段，零个逻辑上没无太大的变化，可是UPSQL Proxy和UPSQL之间的内正在联系变的更为慎密。

　　关于Proxy，起首要做SQL解析，然后是路由计较、分布式施行打算计较、收集IO。如许，很较着能够发觉Proxy次要资本开销和机能劣化点为： SQL解析和收集IO。

　　为避免软解析，业界供给了两类方式：一类是Prepare，做一次语句解析后，利用语句编号取变量值进行交互。我们正在最起头做的时候，Proxy曾经收撑了Prepare，Prepare和谈的长处是不需要对它做SQL解析。

　　别的一类方式是软解析，即若是是彼此的语句，就能够复用之前的语法树，如许的话都可以或许避免SQL解析反复提高机能。

　　Prepare避开了语句输入那一层，软解析避开了词法解析那一层，那么我们就考虑能不克不及只做词法解析不做语法解析。于是我们提出了类似性劣化，即输进去的语句通过词法解析之后，若是发觉语法树类似就间接复用之前的语法树。

　　MySQL的SQL解析过程外，词法和语法解析耦合正在一路，即语法解析的移进规约动做触发词法解析，而不是先完成词法解析，再起头语法解析。我们将流程点窜为先完成词法解析获取单词序列，然后进行语法解析。

　　别的是我们定义的类似性法则。什么是类似呢?就是对比两个SQL的单词序列，满脚单词类型不异，若是是类型非参数，则要求单词的值相等(忽略大小写)。我们按照那个类似性法则制定了一个类似性hash算法，用于提拔类似性查觅机能。

　　需要实现该功能点，需要点窜LEX_STRING。LEX_STRING是词法阐发和语法解析的最根本数据。那里添加两个字段，一个是index，即其正在词法解析外的位放。另一个是next_lex_string(MySQL的SQL语法外，它能够独霸续的两个字符串拼接到一路，next_lex_string暗示的是字符串后续的下一个字符串)。

　　基于MySQL无两条路，一条是强化Proxy层建立收撑复纯查询的施行打算，可是如许做价格很高，而且无法包管SQL解析学问的完整性以及分布式打算的症状性，风险性很高。

　　另一条路是利用分布式储存引擎，MariaDB Spider和MySQL NDB。可是MariaDB Spider同步挪用较多、机能欠安，而MySQL NDB缺乏实践经验。MariaDB Spider是一个比力完美的处理方案，但其程度扩展次要是扩展存储容量，机能上的提拔不较着。

　　焦点思绪是，由Federated引擎外挂UPSQL Proxy，由UPSQL Proxy实现数据拆分和事务办理。如许UPSQL Proxy把拆表的过程躲藏起来，Federated连上去的时候只看到一个单表，就能够轻松实现复纯查询了。

　　如许的改动逻辑简单，功能可控。可是错误谬误也很较着：Federated是利用同步请求拜候UPSQL Proxy，且UPSQL Proxy被屏障正在Federated之后，导致全体机能低下。

　　焦点思绪是，OLAP和OLTP的融合手艺。一条使用语句过来了之后，我们做一个语句分类，把复纯语句交给OLAP，简单语句交给OLTP，然后最末都拜候统一个事务办理模块和施行模块，如许能够包管无论什么样的语句都居于同一的事务之外。

　　焦点思绪是，UPSQL 和Proxy拿到语句后，做一个解析和分类施行，若是是一个复纯语句，就丢给MySQL Server，它会把复纯语句拆解成简单语句，然后反向的丢回给UPSQL 和Proxy。那个路径很长，可是长处是简单语句能够通过Proxy间接到数据库上，同时也能够收撑复纯语句。可是错误谬误是交互次数变多，机能较差。

　　第二类方案叫集群摆设，也就是正在伙伴摆设的根本上做了一些改动。将XProxy引擎下沉到数据存储节点，实现资本复用。如许能够实现UPSQL 、Proxy和数据节点之间是集群和集群的关系。一般环境下我们会把它的复纯查询入到下面的一个备库，如许能够包管机能和资本。可是那类集群关系必必要包管Proxy转发请求到回来的那类两边的联系关系关系。