Mysql集群架构（主从模式、双主模式、分库分表）

        本文主要对mysql集群架构的基本概念和作用进行描述，后续会有更详细的原理介绍。

一、MySql集群架构设计

        在集群架构设计时，主要遵从下面三个维度:可用性、扩展性和一致性。

1.1 可用性设计

1.保证高可用的方法是冗余。

        但是数据冗余带来的问题是数据一致性问题。

（1）站点高可用，冗余站点；

（2）服务高可用，冗余服务；

（3）数据高可用，冗余数据；

2.实现高可用方案

（1）主从模式：简单灵活，能满足多种需求。比较主流的用法，但是写操作高可用需要自行处理。

（2）双主模式：互为主从，有双主双写、双主单写两种方式，建议使用双主单写。

1.2 扩展性设计

        扩展性主要围绕着读操作扩展和写操作扩展展开。

1.读操作

（1）加从库

        ​​​​​​​简单易操作，方案成熟。从库过多会引发主库性能损耗。建议不要作为长期的扩充方案，应该设法用良好的设计避免 持续加从库来缓解读性能问题。

（2）分库分表

        可以分为垂直拆分和水平拆分，垂直拆分可以缓解部分压力，水平拆分理论上可以无限扩 展。

2.写操作

（1）分库分表

1.3 一致性设计

二、主从模式

1.1 基本概念

        MySQL主从模式是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默 认采用异步复制方式，这样从节点不用一直访问主服务器来更新自己的数据，从节点可以复制主数据库 中的所有数据库，或者特定的数据库，或者特定的表。

1.2 解决什么问题

1.高可用

        主从复制+故障切换，实现线上业务不宕机运行。

2.读写分离

        这样减少主库的压力，主写从读。还可以单独使用一个从库来做为企业内部人员查询数据使用的服务器，这样更有利于减少线上服务器的访问压力。

3.数据备份

        很多企业用从库来做专业数据库备份服务器。

1.3 存在什么问题

1.增加服务器负载，影响性能

        主从复制过程中，主服务器需要将数据同步给从服务器，这会增加主服务器的负载，影响性能。

2.数据不一致

        主从复制可能导致数据一致性的问题，例如主从服务器之间的数据延迟或不同步。

3.主服务可用性低

        当主服务器出现故障时，需要手动切换主从角色，这需要一定的时间和人工干预。

4.增加系统复杂性和维护成本

        主从复制需要配置和管理多个服务器，增加了系统的复杂性和维护成本。

总结：

        因此，在选择 MySQL 主从复制时，需要根据实际需求和场景进行评估和规划，以确保系统的可用性、性能和数据一致性等方面的要求得到满足。

三、双主模式

1.1 基本概念

        很多企业刚开始都是使用MySQL主从模式，一主多从、读写分离等。但是单主如果发生单点故障，从库切换成主库还需要作改动。因此，如果是双主或者多主，就会增加MySQL入口，提升了主库的可用性。 因此随着业务的发展，数据库架构可以由主从模式演变为双主模式。

        双主模式是指两台服务器互为主从，任何一台服务器数据变更，都会通过复制应用到另外一方的数据库中。

1.2 解决什么问题

1.读写分离​​​​​​​

        双主模式允许两个主节点同时处理写入和读取操作，从而提高了系统的读写性能。在这种模式下，一个节点可以处理写请求，而另一个节点可以处理读请求，有效地分担了负载。

2.提高可用性

        当一个主节点发生故障时，另一个主节点可以接管其职责，继续处理写入和读取操作。这种自动切换机制提高了系统的可用性和稳定性。

3.数据同步

        双主模式下的两个主节点保持数据同步。当一个节点发生故障时，另一个节点可以保证数据的完整性和一致性。

4.扩展性

        双主模式允许在系统需要更大容量或更高性能时进行扩展。可以通过增加更多的主节点来提高系统的处理能力和可用性通过将写入和读取操作分散到两个节点上，双主模式可以平衡系统负载，提高系统的处理能力。

 注意

        MySQL 双主模式需要配置较为复杂，并且需要谨慎处理冲突解决和数据一致性的问题。此外，这种模式在某些情况下可能导致数据的不一致或损坏，因此在使用时需要谨慎评估风险并做好备份工作。

1.3 存在什么问题

1.配置复杂

        双主复制需要复杂的配置和设置，包括在两个节点之间建立复制关系，确保它们之间的同步，以及解决冲突等。

2.性能问题

        由于两个主节点都同时进行写操作，这可能会导致性能问题。特别是在高负载的情况下，可能会出现性能瓶颈和延迟。

3.数据一致性问题

        由于两个主节点都同时进行写操作，可能会出现数据一致性问题。这可能会导致数据的不一致或出现冲突。

4.网络依赖

        双主复制需要节点之间的网络连接稳定可靠，如果网络出现故障或不稳定，可能会影响复制的同步和数据库的性能。

四、分库分表

1.1 基本概念

        互联网系统需要处理大量用户的请求。比如微信日活用户破10亿，海量的用户每天产生海量的数量;美团外卖，每天都是几千万的订单，那这些系统的用户表、订单表、交易流水表等是如何处理呢?

        数据量只增不减，历史数据又必须要留存，非常容易成为性能的瓶颈，而要解决这样的数据库瓶颈问 题，“读写分离”和缓存往往都不合适，目前比较普遍的方案就是使用NoSQL/NewSQL或者采用分库分表。

        使用分库分表时，主要有垂直拆分和水平拆分两种拆分模式，都属于物理空间的拆分。 垂直拆分:由于表数量多导致的单个库大。将表拆分到多个库中。 水平拆分:由于表记录多导致的单个库大。将表记录拆分到多个表中。分库分表方案:只分库、只分表、分库又分表。

1.2 解决什么问题

1.数据库性能瓶颈

        随着业务的发展，单台数据库服务器可能无法承受过大的并发请求，导致性能瓶颈。通过将数据分散到多个数据库实例中，可以提高系统的整体性能和并发处理能力。

2.数据库压力过大

        单台数据库服务器可能因为承载过多的数据表和数据行而面临过大的压力，导致响应速度变慢、崩溃等问题。通过将数据分散到多个数据库实例中，可以减轻单个服务器的压力，提高系统的可靠性和稳定性。

3.数据一致性问题

        在某些场景下，由于并发操作和事务的一致性要求，可能会出现数据一致性问题。通过分库分表，可以降低事务的一致性要求，减少并发操作的影响，提高系统的可用性和稳定性。

4.水平扩展问题

        在某些场景下，系统的并发处理能力和存储容量可能成为瓶颈。通过分库分表，可以实现系统的水平扩展，提高系统的性能和容量

1.3 存在什么问题

1.事务一致性问题

        当更新内容同时分布在不同库中，不可避免会带来跨库事务问题。跨分片事务也是分布式事务，没有简单的方案，一般可使用"XA协议"和"两阶段提交"处理。分布式事务能最大限度保证了数据库操作的原子性。但在提交事务时需要协调多个节点，推后了提交事务的时间点，延长了事务的执行时间。导致事务在访问共享资源时发生冲突或死锁的概率增高。

2.跨节点关联查询（join）问题

        切分之前，系统中很多列表和详情页所需的数据可以通过SQL JOIN来完成。