MySQL的5种特殊设计架构

1. MySQL+分布式Proxy扩展

MySQL+分布式Proxy扩展分好多种情况，我们从之前博客讲解的pxc集群开始讲解。

1.1 PXC集群

pxc集群牺牲读写速度的代价保证数据的强一致性，在保证数据强一致性的业务中才推荐使用pxc集群，比如与钱相关的业务必须使用pxc集群，数据不一致导致的后果很难承担。由于pxc集群是牺牲写入速度保证数据的强一致性，增强pxc集群性能可以使用数据分片，比如使用mycat分片，通过mycat分发之后每个分片写入的压力就减少了很多，性能就能提升不少。另外在业务设计上也要避免瞬时写入的压力

1.2 Replication集群

说完了数据强一致性的PXC集群，我们再说一下弱一致性的Replication集群。用Replication搭建集群之后也可以使用数据分片。

1.3 PXC集群+Replication集群

面对复杂的业务，系统会同时面对强一致性和弱一致性。我们可以将两种集群整合在一起，我们根据水平拆分的原则，把需要强一致性的数据表建立在PXC集群，不需要强一致性的数据表建立在Replication集群里。关键性的数据写在PXC，非关键性的数据写在RP里。这就兼顾了强一致性，弱一致性，读写速度的矛盾。在CRUD语句里边最复杂的是查询语句，单标查询还好，表连接要是查询不同集群中的数据表这就会很复杂。应对这种查询方式有两种，第一种是由于Replication集群写入速度比PXC集群速度更快，我们可以使用同步中间件将PXC集群中的数据同步到Replication集群。然后在Replication集群里边查询表连接操作。这样就能查到你想要的数据结果。另一种方案是ETL中间件，先把数据从不同的集群中抽取出来，然后再做表连接去查询，比如知名的ETL中间件kettle。

1.4 PXC集群+Replication集群+缓存集群

说完了PXC集群和Replication集群的混合方案，如果系统对读写速度要求更高，我们还可以引入mongodb，redis等NoSQL缓存数据库。
这里就要关注一下数据库集群的事务，有些人会想到XA事务，但是PXC集群不支持XA事务，所以这个方案并不可行。阿里巴巴有一个GTS的中间件，他可以把各种数据库纳入到一个事务之下，但是GTS只能运行在阿里云上。还有一种方案是利用消息中间件，去模拟分布式的事务，把PXC集群、Replication集群、缓存集群纳入到事务之内。

2. 数据归档，冷热数据分离

随着是数据的增加，无论是单节点的mysql还是mysql的集群，都要做冷热数据分离，冷数据可以存放到归档表，可以使用MongoDB，也可以使用TokuDB来保存归档数据。mongodb大家都熟悉，这里主要讲解一下TokuDB。TokuDB是mysql的一种存储引擎，可以高速的写入数据，写入速度是innodb引擎的9倍，压缩比是innodb的14倍，跟mongdb相比丝毫不逊色，TokuDB的写入性能是MongoDB的4倍，而且还是带事务的写入

3. MySQL+缓存(Redis)高并发架构

比如以发红包的案例，用户A发红包，把红包数据存入缓存，用户B,C,D抢完红包之后，再把红包数据写入到数据库中。

4. MySQL+小文件系统

5. MySQL+Inforbright统计分析架构

这一种mysql设计方案跟数据分析有关，对于数据库而言，通常是第二天之后才会有结果汇总统计分析的需求， 这类OLAP执行频率较低，但是每次统计的信息太多，消耗的资源很大，如果在OLTP系统上运行会造成两大业务的相互影响，所以我们应该把OLAP给独立出去，通过数据流转把OLTP的数据传输个OLAP系统，有很多成熟的OLAP系统比如Inforbright系统，在几百万到几十亿数据的规模下查询速度是mysql的5-60倍。相对而言Inforbright是轻量级的，而分布式的mpp数据仓库可以支撑更大海量数据的统计分析，所以有数据分析的系统不防试一试这种架构。