MySQL的5种特殊设计架构

￡神魔★判官ぃ 2021-11-29 05:20 214阅读 0赞

# 1. MySQL+分布式Proxy扩展 #

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

## 1.1 PXC集群 ##

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

## 1.2 Replication集群 ##

说完了数据强一致性的PXC集群，我们再说一下弱一致性的Replication集群。用Replication搭建集群之后也可以使用数据分片。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 1]

## 1.3 PXC集群+Replication集群 ##

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 2]

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

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

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

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

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 5]  
比如以发红包的案例，用户A发红包，把红包数据存入缓存，用户B,C,D抢完红包之后，再把红包数据写入到数据库中。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 6]

# 4. MySQL+小文件系统 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 7]

# 5. MySQL+Inforbright统计分析架构 #

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70]: /images/20211129/27b11353c90b46b78463974e68329108.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 1]: /images/20211129/8707c9307f8d409291e47027daa52867.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 2]: /images/20211129/2fe0c1c382cc43a0ac25ce0866de62af.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 3]: /images/20211129/441f2619bd8c4267a52ac3a5d0ddd2a2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 4]: /images/20211129/c1fd7fc391784cfc91322c54784b081e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 5]: /images/20211129/86bd97de574f4ba39ff871cc1ab67ed2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 6]: /images/20211129/7e57dd970e4b4a65bc7fcffe0196867a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 7]: /images/20211129/a9b727efc74648cbb1de9c8b2c4e3614.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3Bqc2RzZw_size_16_color_FFFFFF_t_70 8]: /images/20211129/35de0620c4e24e72a42f24c94c42b25d.png