开发者学堂课程【如何将PolarDB-X与大数据等系统互通：如何将 PolarDB-X 与大数据等系统互通】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/984/detail/14937
如何将 PolarDB-X 与大数据等系统互通
通过这样的一个机制，就可以实现我的一个分布式事物，那这个分布事物最终在PolarDB-X 的里面是什么样一种结果呢？就是如果你的应用做的一个事物，它的变更的数据涉及到了多个 DN ，也就及到了多个 MySQL ，那么能够保证就是它在多个 DN 中有一个事物的约束，这就是第一步，也就是说PolarDB-X用两阶段提交和实现了分布式事物，那么实现了这样一个事物其实用 XA 的方式也有一些问题，这个问题是什么呢？这个问题是当比如说这些事物真的发生冲突的时候，比如说两个事物涉及到了同一个 DN 上面的同一条数据的时候，在这里面就会有一个冲突，在这些场景下面，这个事物的方案实现的效率就会非常低，所以为了进一步提高效率需要继续往下做优化，通常业界所做的优化就是引入 micc 这样的一种多版本控制，那引入多版本之后会引入一些新的问题，因为在读版本机制里面有一个基本的概念叫做全局的快照，那在分布式的场景下面，也就是说需要在新这一层能够获取若干个 DN 里面数据的一个一致性的快照，那么这件事情是比较麻烦的，为什么这么说呢？
因为在分布式的场景下面，大家最基本的一个点所有的 DN 的机制时间是不一样的。第二个 CN 到所有的 DN 之间通信网络的延迟是不一样的，所以没有办法用一个某一个机制上的时间来做为一个衡量的标准，来说这个小于这个时间之前的数据，就认为就可以拿来做一个快照了。这边做一个简单的比喻，比如说这张图的右边的最上面这一部分，这边有第一个 CN ，它现在在处理一个事物，那么它现在想获取这边有两个 DN 里面数据的一个全局的，进而进行一个拍照，那它如果先用自己机器的时间，拿这样的一个时间去往下游的两个 DN 里面去查询，如果我查询的时候是这么个时间点，就把早于这个时间的那些数据快照给我就好了。
那这样就有问题，比如说下游的某个 DN 的机器时间,我就是比你走的快，或者我就是走的比你慢，这个时候就可能会有问题，所以就是最终需要提供一个全局性的大家达成一致的一个授时服务，也就是前面所说的那个组件，它所提供的一个服务叫做 TSO ，简单来说它是系统的一个单点，它能够为系统里面所有的组件来提供一个能够达成一致这样一个时间服务。那引入这一堆概念之后，你会发现这些东西会跟Binlog有什么关系呢？
因为在 MySQL 里面所有的变更，最终它会记录在 Binlog 里面。因为分不知事物用了my SQL 的 xa 这样一个协议的实现。那 xa 这样的一个协议，Binlog的格式又跟前面所说的那个稍微有点不一样，就是在单机 MySQL的事物下面，它记录的Binlog就是一个事物一个事物一个事物，按照它们事务处理的顺序记住在一个单一的队列里面，但是一旦用了 XA 之后，一个XA 这样的一个事物，它记录的格式是分成了两阶段，那这样会导致什么问题呢？
如果没有多个事物记录在这个Binlog的时候，你会发现他们的每个事物的 p 和 c 可能会交叉，也就是我的Binlog里面可能会出现这样的一种场景， p1p2Cc2甚至有可能会出现P1p2C1C2这样的一个状态，这样就会增加生成Binlog 的一个复杂度，这是第一点；第二点是什么？第二点就是因为在分布式的场景下面一个事物会涉及到多个 DN ，也就是说一个事物的变更被记录在了多个的物理的Binlog 的流里面，但是最终要对下游提供一个单一的对全局的这样的一个Binlog的一个流，那也就意味着需要将同一个分布式事物分布在不同的DN 上面，那些变更再次把它们收集起来放到一个事物的时间里面，那需要有一个依据来知道这个 DN 物理Binlog里面的这一段变更，它和另一个DN的另一段Binlog里面的物理变更，他们其实是属于同一个分布事物的。
所以这个系统去处理的另外一个复杂的一个事情；第三个事情是什么呢？就是现在这个图里面的最右下角的这张图，这张图是个什么东西呢？它就是现代的分布式系统，分布式数据库通常也会支持一个 online 这样的一个能力，就是可以做一个 dl 的表，比如说结果的一个变更，那目前一个组织的方案就是Google 的 fone 的方案，也就是所谓的online change ，这个方案简单来说它有这样的一个特点，它允许你的系统当中同一时间存在两个版本的信息，比如说你现在有一张表，就这张图里面它有 ab 这两列，那过一段时间你想要加个 E ，那它说的事情就是说我允许在我的系统当中，比如说我如果有一个应用的连接到了其中的一个 CN ，它看到了一张表有两列，那另外一个应用然后通过连接到另外一个 cn ，它看到了结果里面有三列，那这样的那事情是允许的，所以那个方案里面讲的就是这种事情，并且不引起任何一致性的一个问题。那么这样就会引入一个新的问题，也就是他如果允许这样的一种方式，那么 DDL 在实现的时候，它会给讲一堆的逻辑，那确实是按照那种方式实现的，但是最终会导致什么样的一种结果呢？
这个结果就是比如说最下面只有两个物理 Binlog的流，最左边的时候大家那个表结构是一致的，那过一段时间肯定要做 DDL ，因为不同的 DN 的时间不一样， DN 跟 CN 之间的网络交互延迟也不一样，所以收到那个表结构变更这条指令肯定时间是不一样的，也就是开始做这个ddl的时间是不一样的，这样就会存在一个同样一张表的关于同一行他在一个Binlog里面他说他有两列，在另外一个是不同的行，但是同一张表的数据里面，他说他是有两列，在另外一个他有三列，那我全局 Binlog 最终是要合到一起的，那在这个阶段应该用两列还是三列？所以这就是个问题，这会导致实现还是非常复杂的。那怎么解这些问题呢？
这些问题最终都是可解的，所以今天简单来说一下，把这个问题给简化一下，来看一下站在Binlog的角度来看一下整个系统的数据的流。这张图是从左往右看，最主要是 CN ，它接受应用的一些SQL，然后它先将这些 SQL 经过计算之后，下发到了下游的一个 DN ，那这些 DN 处理完之后就会产生他们的一个物理的 Binlog 。
假设系统当中现在有四个 CN 四个 DN ，那么四个 DN 就会产生四条 Binlog，也就是这张图里面的这个目前的一个状态，又因为前面所说的两阶段提交了那些乱序等等这些问题，所以这四个物理的Binlog 流里面可能是现在图里面那种状态。首先每一格代表的是一个 XA 事物里面那个变更，那里面的数字代表的是事物的一个ID，那标成橙色的部分代表了它们的顺序已经乱掉了，对于四条物理的Binlog 的流，那要怎么去处理它们呢？
那首先第一点是要把它们单个的这四条物理的Binlog 流里面的顺序给理顺。
比如最上面那条，它是1233548，那首先我要把“4”的位置给它放对，所以要做的第一件事情就是要把每一个物理Binlog 流的顺序理顺。这就是到了第二阶段，那每一个流理顺之后，还要做件事情因为刚才说了在单机的 MySQL 里面每一个变更,它是同一个事物的变更，它们是在一起的。在差异里面，它是p和c这两个阶段，那所以这个时候还要将 xa 里面的事物合并了，之后but合成把它转换成一个单机的形态，比如把 PC 变成原来的MySQL 这个单机的那种形态，这是我做的第二点事情。
然后第三个就是刚才说的 DDO ，因为可能会有所变化，这里面会做一些其他的一些处理，然后最后一个还需要做一些过滤，因为PolarDB-X会有一些系统的表，那这个是没必要对下游进行暴露的，另外一个它会有一些内部实现的一些类似于广播表或者是全局索引等等这样的一种功能，这些东西在 DN 里面也都会体现，比如广播表实际上站在我记得视角来看，它就是一张表，但是在实现上它其实分布在了所有的 DN 里面，这样也就会导致广播表里面的一条数据，那会出现在四个点里面，那也就是会出现在这四个的流里面，那其实它是一条数据，那在处理的时候就需要识别出来这样的一种场景，然后把这四条里面的三条给去掉留一条，留着四条其实是一样的。会把内部的一些逻辑给屏蔽掉，那经过这个处理之后，你会发现我得到了四条干净的有序的物理Binlog 流。
那接下来就是经典的一个规定这样的一个过程，也就是第三阶段，会把这四个物理Binlog 流按照顺序做一个规定，规定完之后，你会发现他们都会同一个事物就会放到一起，比如说现在这个处理好的流就变成了前三个就是111，接下来就是222，然后五个三等等这样的一个顺序，三个111其实就是同一个分布式事物分布在了三个物理Binlog 流，如果它们被归到了一起，那么这个时候其实就是可以进一步的将这三个事物的变更整合成一个，所以接下来会将这个单一的流再做进一步处理。
第一个会把分布式事物进行合并，第二个会按照MySQL的不是，进行一个录盘那到此终于到了第四阶段就是我终于生成了跟SQL编了个格式一样的一个文件，就是在前面的弹幕当中大家看到的那个log 50一个文件，他其实跟买这款的文件完全一模一样的，还需要进一步的将这个冰冻文件，也就是单一的时间流分发给下游，也就是在这次的两个弹幕里面，一个是server一个是bicycle那么，在给下游提供这种增量文件订阅的时候呢，就是cn层同样的实现了mexico协议同时在很多的一些行为上会跟进行一个兼容，比如说它会去查一下，回去看这个有没有设置好，还有一些其他的一些等等一些跟相关的一些参数甚至不相关的一些参数，然后很多工具都会为它们一个标准的过程，在这些边过订阅的行为当中把这个接着这样就实现了一个给下游提供一个完全兼容的这样的一个过程。
