PXC的数据库集群架构有用多节点强一致性同步的特性，并且每个节点都可以作为主节点，都可以同时读写，然后更改会立即同步到集群中所有节点，但是由于强一致性，导致其写入速度不如传统的Replication架构，PXC的写性能取决于集群中最慢的一台节点，所以集群节点并不是越多越好，一般三台。而Repilication读写分离架构就无此限制。但是Replication架构虽然写速度更快，但是却无法实现多主节点灾备，而且由于延迟会导致不一致性，所以对于一致性要求高的表数据又无法选用Replication架构。
所以把两者的优点结合起来使用是最好的，由于PXC数据库也可以当成mysql一样使用，而且PXC集群实现是通过galera，而Replication是通过binlog异步同步，两者互不牵连，所以可以同时实现两种模式。而且PXC数据库可以和PXC数据库组Replication这种主从读写分离集群，也可以和MySQL官方版组成集群，因为其通过binlog进行复制所以跨版本也是可以接受的。
关于PXC和Replication集群的部署方法，可以看我前两篇博客
《基于Docker的MYSQL PXC集群搭建》《MySQL5.7.18基于事务的主从复制和读写分离》《MYCAT轻松实现mysql读写分离》
下图是一种部署方法
上面使用了两台Percona数据库做成了双主集群，左边那台用来写，右边那台用来读，而且是对一致性要求较高的那些表的读。当Master1节点宕机之后，会被mycat发现，然后把读操作迁移到Master2上。
最左边是MySQL官方版数据库，作为Master1的slave，只能读不能写，并且基于GTID的事务进行同步。用来做那些一致性要求不高的表的读负载，比如用户评论，用户收藏夹等。同样最右边那台也是MySQL的slave，不过它的master是Master2那台机器。正常运行的时候，mycat向Master1写，从Master2和两台slave读，当Master1宕机之后，mycat将会用Master2写，用Master2和最右边的slave读。直到Master1恢复后再还原。
注：如果在Master2上插入数据，不仅Master1会同步，Master1的Slave们也会同步，因为虽然sql语句没有直接发到Master1，但是Master1在同步Master2的过程中，会把相关的操作写入到binlog中，然后Slave就可以通过3306上的IO线程进行同步了。
最上面那台服务器是Master1的slave，只做同步，不去读取。用于同城或者异地备份。由于距离较远，所以采用Replication这种异步方式进行同步，如果也加入PXC集群会大大拖慢写入速度。这样做的原因是如果本地机房发生断水断网等灾害，那么可以迅速的将异地的MySQL直接切换成Master支撑全部数据库业务。保证在机房故障的时候不中断业务。
在上面的集群中，每一台Slave只有一个Master，这样可以防止自增键出现重复计数的问题，同时实现了数据库一般查询和一致性查询分流，大大提高了并发性能。并且实现了本地双活高可用。异地实时同步提高了抗风险能力。上图中任意一台服务器宕机都不会影响服务的正常运行。
