数据库主从复制，读写分离，负载均衡，分库分表分别表达的是什么
数据库主从复制：将一个数据库的数据同步到多个服务器上。读写分离：将读操作和写操作分别放在不同的服务器上进行处理。负载均衡：将大量的请求分散到多个服务器上。分库分表：将一个大型的数据库拆分成多个小型数据库。
一、主从复制
主从复制是指将一个数据库的数据同步到多个服务器上，其中一个服务器是主服务器，负责写操作，其他服务器是从服务器，负责读操作。主从复制可以提高系统的可用性和容错性，同时也可以减轻主服务器的压力。
1、解决的问题
- 数据分布：通过复制将数据分布到不同地理位置
- 负载均衡：读写分离以及将读负载到多台从库
- 备份：可作为实时备份
- 高可用性：利用主主复制实现高可用
2、复制原理
- 在主库上把数据更改记录到二进制日志binary log中，具体是在每次准备提交事务完成数据更新前，主库将数据更新的事件记录到二进制日志中去，Mysql会按照事务提交的顺序来记录二进制日志的。日志记录好之后，主库通知存储引擎提交事务。
- 从库会启动一个IO线程，该线程会连接到主库。而主库上的binlog dump线程会去读取主库本地的binlog日志文件中的更新事件。发往从库，从库接收到日志之后会将其记录到本地的中继日志relay-log当中。
- 从库中的SQL线程读取中继日志relay-log中的事件，将其重放到从库中。（在5.6版本之前SQL线程是单线程的，使得主从之间延迟更大）
3、两种复制方式
- 基于语句复制：基于语句的复制相当于逻辑复制，即二进制日志记录了操作的语句，通过这些语句在从库进行重放来实现复制。这种方式简单，二进制日志占用空间少，使得带宽小传输效率较高。但是基于语句的更新依赖于其他因素，比如插入数据时利用时间戳函数调用当前时间作为时间值也会出现问题，因为由于主从之间的延迟导致时间值不一致。存储过程和触发器也可能出现问题。所以在开发当中我们应该将逻辑尽量放在代码层，而不应放到mysql中，不易扩展。
- 基于行复制：基于行的复制相当于物理复制，即二进制日志记录了实际更新数据的每一行。这样导致行复制的压力比较大，因为日志占用空间较大，传输占用带宽也较高。但是比基于语句复制更加精确，可以屏蔽一些由于主库从库之间的差异导致的不一致。如刚才提到的时间戳函数。
4、两种复制方式对比
- 语句复制：传输效率高，减少延迟。在从库更新不存在的记录时，语句赋值不会失败。而行复制会导致失败，从而更早发现主从之间的不一致。设表里有一百万条数据，一条sql更新了所有表，基于语句的复制仅需要发送一条sql，而基于行的复制需要发送一百万条更新记录。
- 行复制：不需要执行查询计划。不知道执行的到底是什么语句。
例如一条更新用户总积分的语句，需要统计用户的所有积分再写入用户表。如果是基于语句复制的话，从库需要再一次统计用户的积分，而基于行复制就直接更新记录，无需再统计用户积分。因为两种方式各有优缺点，所以mysql在这两种复制模式进行动态的切换。
二、读写分离
读写分离是指将读操作和写操作分别放在不同的服务器上进行处理。通过这种方式，可以减轻主服务器的压力，提高系统的并发处理能力和稳定性。当然，需要注意的是，因为从服务器的数据可能会出现延迟，所以在进行数据访问时需要考虑数据同步的时间问题。
1、解决的问题
大多数互联网业务，往往读多写少，这时候，数据库的读会首先称为数据库的瓶颈，这时，如果我们希望能够线性的提升数据库的读性能，消除读写锁冲突从而提升数据库的写性能，那么就可以使用“分组架构”（读写分离架构）。用一句话概括，读写分离是用来解决数据库的读性能瓶颈的。
2、实现读写分离的原理与方案
- 基于MySQL proxy代理的方式：在应用和数据库之间增加代理层，代理层接收应用对数据库的请求，根据不同请求类型转发到不同的实例，在实现读写分离的同时可以实现负载均衡。
- 基于应用内路由的方式：基于应用内路由的方式即为在应用程序中实现，针对不同的请求类型去不同的实例执行sql。
- 基于mysql-connector-java的jdbc驱动方式：使用mysql驱动Connector/J的可以实现读写分离。即在jdbc的url中配置为如下的形示：jdbc:mysql:replication://master,slave1,slave2,slave3/test。
- 基于sharding-jdbc的方式：sharding-sphere是强大的读写分离、分表分库中间件，sharding-jdbc是sharding-sphere的核心模块。
三、负载均衡
负载均衡是指将大量的请求分散到多个服务器上，以避免单一服务器被过度压力而导致系统性能下降。通过负载均衡，可以提高系统的并发处理能力和稳定性。常见的负载均衡算法有轮询、加权轮询、随机等。
1、产生背景
SLB（服务器负载均衡）：在多个提供相同服务的服务器的情况下，负载均衡设备存在虚拟服务地址，当大量客户端从外部访问虚拟服务IP地址时，负载均衡设备将这些报文请求根据负载均衡算法，将流量均衡的分配给后台服务器以平衡各个服务器的负载压力，避免在还有服务器压力较小情况下其他服务达到性能临界点出现运行缓慢甚至宕机情况，从而提高服务效率和质量。因此对客户端而言，RS（real server 实际服务器）的IP地址即是负载均衡设备VIP（虚拟服务地址IP）地址，真正的RS服务器IP地址对于客户端是不可见的。
2、三种传输模式
七层SLB和四层SLB的区别：四层SLB：配置负载均衡设备上服务类型为tcp/udp，负载均衡设备将只解析到4层，负载均衡设备与client三次握手之后就会和RS建立连接；七层SLB：配置负载均衡设备服务类型为 http/ftp/https 等，负载均衡设备将解析报文到7层，在负载均衡设备与client三次握手之后，只有收到对应七层报文，才会跟RS建立连接。在负载均衡设备中，SLB主要工作在以下的三种传输模式中：
- 反向代理模式
- 透传模式
- 三角模式
根据不同的模式，负载均衡设备的工作方式也不尽相同，但无论在哪种模式下，客户端发起的请求报文总是需要先到达负载均衡设备进行处理，这是负载均衡设备正常工作的前提。
四、分库分表
分库分表是指将一个大型的数据库拆分成多个小型数据库，并将其分配到多个服务器上进行管理。这样可以减小单个数据库的数据量，提高查询性能和写入速度。分库分表需要考虑数据的拆分规则、数据的一致性、跨库查询等问题。
数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分。
1、垂直（纵向）切分
垂直切分常见有垂直分库和垂直分表两种。
垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与”微服务治理”的做法相似，每个微服务使用单独的一个数据库。如图：
垂直分表是基于数据库中的”列”进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例如一个大表有100多个字段），通过”大表拆小表”，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。
优点：
- 解决业务系统层面的耦合，业务清晰
- 与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等
- 高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈
缺点：
- 部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度
- 分布式事务处理复杂
- 依然存在单表数据量过大的问题（需要水平切分）
2、水平（横向）切分
当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。如图所示：
库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，较好通过分库分表来解决。
优点：
- 不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力
- 应用端改造较小，不需要拆分业务模块
缺点：
- 跨分片的事务一致性难以保证
- 跨库的join关联查询性能较差
- 数据多次扩展难度和维护量极大
延伸阅读1：数据库常见的架构方案
- 主备架构：只有主库提供读写服务，备库冗余作故障转移用
- 双主架构：两个主库同时提供服务，负载均衡
- 主从架构：一主多从，读写分离
- 双主+主从架构：看似完美的方案
版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系邮箱：hopper@cornerstone365.cn 处理，核实后本网站将在24小时内删除。
相关文章推荐
