是什么?
主从架构,进行读写分离,让主服务器(Master)处理写请求,从服务器(Slave)处理读请求,这样同样可以提升数据库的并发处理能力。
为什么?
首先不是所有的应用都需要对数据库进行主从架构的设置,毕竟设置架构本身是有成本的,如果我们的目的在于提升数据库高并发访问的效率,那么首先需要考虑的应该是如何优化你的 SQL 和索引,这种方式简单有效。
其次才是采用缓存的策略,比如使用 Redis,通过 Redis 高性能的优势将热点数据保存在内存数据库中,提升读取的效率。
最后才是对数据库采用主从架构,进行读写分离。按照上面的方式进行优化,使用和维护的成本是由低到高的。主从同步设计不仅可以提高数据库的吞吐量,还有以下 3 个方面的作用。
主从同步的优势:
1. 负载均衡,减少了锁表的影响(主表写,不影响从表读)
2. 数据备份
3. 高可用性(主服务器宕机,可以切换到从服务器上)
怎么实现?
主从同步的原理
数据库中有一个重要日志文件,那就是 Binlog 二进制日志(存储的是事件,这些事件分别对应着数据库的更新操作),它记录了对数据库进行更新的事件。实际上主从同步的原理就是基于 Binlog 进行数据同步的。
在主从复制过程中,会基于 3 个线程来操作,一个主库线程,两个从库线程。二进制日志转储线程(Binlog dump thread)是一个主库线程。
当从库线程连接的时候,主库可以将二进制日志发送给从库,当主库读取事件的时候,会在 Binlog 上加锁,读取完成之后,再将锁释放掉。
从库 I/O 线程会连接到主库,向主库发送请求更新 Binlog。这时从库的 I/O 线程就可以读取到主库的二进制日志转储线程发送的 Binlog 更新部分,并且拷贝到本地形成中继日志。从库 SQL 线程会读取从库中的中继日志,并且执行日志中的事件,从而将从库中的数据与主库保持同步。
如何解决主从同步的数据一致性问题
主从之间数据复制方式:
方法 1:异步复制(提交后不等待)
异步模式就是客户端提交 COMMIT 之后不需要等从库返回任何结果,而是直接将结果返回给客户端,这样做的好处是不会影响主库写的效率,但可能会存在主库宕机,而 Binlog 还没有同步到从库的情况,也就是此时的主库和从库数据不一致。
这种复制模式下的数据一致性是最弱的。
方法 2:半同步复制(提交后等待)
MySQL5.5 版本之后开始支持半同步复制的方式。原理是在客户端提交 COMMIT 之后不直接将结果返回给客户端,而是等待至少有一个从库接收到了 Binlog,并且写入到中继日志中,再返回给客户端。这样做的好处就是提高了数据的一致性,当然相比于异步复制来说,至少多增加了一个网络连接的延迟,降低了主库写的效率。
方法 3:组复制(提交前等待)
读写事务想要进行提交,必须要经过组里“大多数人”(对应 Node 节点)的同意,大多数指的是同意的节点数量需要大于(N/2+1),这样才可以进行提交,而不是原发起方一个说了算。而针对只读事务则不需要经过组内同意,直接 COMMIT 即可。
主从复制:是主数据库的数据通过二进制日志自动复制到从数据库中。
读写分离:由原本一个服务器的读写请求转变为现在的主服务器处理写请求,从服务器处理读请求,减少了主服务器的压力。
负载均衡:让不同的读请求按照策略均匀地分发到不同的从服务器中,让读写更加顺畅。