PXC架构理论解析（三）——集群节点同步

PXC架构理论解析（三）——集群节点同步

我们前面通过搭建实验和参数解释大概解释了一下PXC的工作原理，我们这里在细化的说一下PXC集群同步。

此图出自运维内参

一. Galera的事务处理

我们在之前的《PXC架构理论解析（一）——Galera接口》当中有过一些介绍，Galera不参与数据库的复制同步，它只是在中间协调配合事务，将各个节点构成联系。在Galera当中所处理的最重要的一个就是验证，在每个节点之间传送是以写集为单位，验证每个节点的写集会不会冲突，这个功能就是由wsrep_pre_commit进行操作的。而写集的组成是由galera_append_key和galera_append_data接口执行的，galera_append_key将当前事务影响的行的KEY（主键+数据）+数据库名+影响行所在的表名组成一个写集KEY，每个受影响的行都会生成一个写集key。当一个事务结束后，另外一个接口galera_append_data，将当前事务产生的所有binlog都添加到当前事务的DATA集合中（DATA其实就是binlog），然后将KEY和binlog一一对应，现在的KEYS+DATA就是一个写集（write_Set）。

此图出自运维内参

在得到写集之后galera_pre_commit就进行他的两项工作：1.向其他节点replicate 写集（KEYS+DATA）2.进行验证

现在写集被传送到了各个节点，各个节点会去做复制和验证，复制我们后面说，先说验证：

验证工作其实就 是本地验证，每个节点验证当前节点传来的写集或者是本节产生的写集（我们叫做WN,这个是我自己起的）和等待提交的写集（我们叫做WW，这个也是我自己起的）之间的事务验证，WN去和在缓存中的所有WW进行验证对比，如果同时满足下面三点，验证失败：

两个事务的来源不是一个节点提供。

两个事务包含相同的key（同一个行的主键+数据）。

之前的事务没有提交。

此图出自运维内参

如果验证失败，有两条路可以选择：

1.再次尝试

2.GTID大的事务调用接口wsrep_abort_pre_commit，停止事务commit，如果这个这个事务已经验证，那么将这个事务回滚。因为之前已经将写集进行发送，所以通过接口galera_replay_trx，模拟一个从节点，将这些信息APPLY。

二.Galera的消息传送（replicate）

我们在上面提到PXC在节点之间传递同步事务的时候是以写集为单位，我们知道galera_pre_commit所做的是两个操作，其中一项就是replicate数据向所有节点。运维内参当中介绍到PXC有五层，这五层的关系保证了数据之间的同步互传同步，我们先看下这个架构图。

Mysql层：MYSQL服务层 ，这一层也就是PXC的表面层，这里保证数据库之间是muliti-master多主的架构。

Galera层：galera通过一些回调函数将数据库集群的数据进行传输同步，并且将数据保证一致。

GCS层：group communacation system ，目的是操作逻辑处理部分，发送线程包括数据分片，数据分发，下层传送。接受线程包括接收，组装，通知worker线程或者丢弃。

Backend层：后端抽象层，为GCS层提供统一的接收发送接口。

GCOMM：真正接受和发送数据的地方。

Galera在处理事务写集的时候，GCS层判断事务包大小，以64k为节点，超过会切片分发，在backend层将GCOMM层接口封装，GCOMM将会给自己节点和其他节点进行分发，我们之前也说过这个。其会等待自己给自己发来的这个信息，本机在收到这个消息之后产生序列号，其实就是一个GTID。等待这个GTID收到之后就会认为其他节点也收到对应信息了。

针对于其他的节点来说，在backend层的接口backend_recv接受GCOMM传来的事务节点发来的数据，将所有的分片在这里组装，将组装玩的数据包传递给mysql层（pxc层），进行Galera_recv和process_trx，先做验证，之后通过获取binlog和这个数据包，通过wsrep_apply_cb，将写集复制到其他节点。

THAT'S ALL

BY CUI PEACE!!!!!