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数据仓库可以支撑更大海量数据的统计分析,所以有数据分析的系统不防试一试这种架构。