数据库读写分离如何保证主从一致性

当我们的数据库压力主键变大的时候，我们会尝试增加一些从节点来分摊主节点的查询压力。而一般来说，我们是用一主多从的结构来作为读写分离的基本结构。

而一般来说我们有两种常用的方法来实现读且分离架构：

客户端直接分离

这种方式是由客户端，或者我们的微服务直接进行数据库的读写选择。将读库选择路由到主库上进行，将查询路由到从主库上进行。

这种方式的优点在于因为是直连所以性能比较高，但是需要由业务团队了解数据库的实例细节，当数据库做调整的时候就需要业务侧同步改造。

使用数据中间件代理

这种方式是由一层代理层对数据的读写做分发，业务层将所有的请求都通过代理来实现。

这种方式的优点在于对于业务层不需要感知到数据库的存在，但问题在于数据中间件的性能要求较高，还需要专人来进行优化和维护，整体架构较为复杂。

但是我们发现，尽管这两种方式各有优劣。但核心都是通过数据的写入、查询请求的路由而实现的，那么这就会引发标题的问题：

主备同步存在延迟，所以在延迟时间内对插入的内容进行查询则无法查询到最新提交的事务。

那么如何保证主从一致性的问题，其实就变成了如何处理主从延迟的问题。

根据项目的大小，团队的规模以及主机的部署模式。我们处理问题的方法也有很多种。

最简单强硬的就是强制读主库。

一般情况下我们在不同的查询中会有不同程度的一致性要求。我们可以将需要保证数据一致性的请求配置强制查询主库，而对于无强依赖的查询请求仍然查询备库。

尽管这个方案不是很优雅，但是是最简单实现的方法，并且在Spring等框架的支持下一般只需要加一个注解就能实现。但这个方法的问题也是显而易见的，如果存在大量的强一致性要求的查询语句，则相当于没有进行读写分离与扩展。那么这种方法就会导致系统在数据库层面没有有效的扩展手段了。

由于问题产生的来源是主从延迟，所以在下一次查询的时候进行一段时间的等待以弥补这种延迟即可。

所以在进行主库的数据插入之后，让数据库数据连接或者对应的执行线程等待一段时间后返回。通过等待时间来消化掉主从备份的延迟时间。但是这个方法也有一些问题比如：这个等待时间一般是固定的，即便主从已经无延迟了也会继续等待到时间结束；如果在服务高峰时期，有可能数据在等待时间结束后仍然没有完成同步则仍然会存在一致性问题。

但这种方法优雅的地方是可以配合业务来进行实现，举例来说当用户下单之后，通过下单送卷或者下单抽奖的方式从前端拖住用户，从而当用户在一次连续 *** 作中再次查询自己订单的时候中间必然会间隔一定时间，也就让需要再次查询数据的时候保证了数据的一致性。

上述两种方案看起来可能不那么“技术”，感觉有点投机取巧。那么下面咱们可以分两种情况来讨论用更高技术的方法如何实现一致性。

对于主从复制来说，是当主库完成一个事务后，通知给从库，当从库接受到后，则主库完成返回客户端。所以当主库完成事务后，仅能确保从库已经接受到了，但是不能保证从库执行完成，也就是导致了主从备份延迟。

但是从库执行数据是有进度的，而这个进度是可以通过show slave status语句中的seconds_behind_master来进行描述，这个参数描述从库落后了主库数据多少秒，当这个参数为0时，我们可以认为从库和主库已经基本上没有延迟了，那么这时候就可以查询请求。

但seconds_behind_master是秒级的，所以只能大概地判断，由于精度较低，所以还是可能出现不一致的情况。

如果要求精准执行的话，我们可以比较同步文件的执行记录，具体来说是：

所以当Relay_Master_Log_File和Exec_Master_Log_Pos和其一致的时候，就说明从库的已执行数据已经追上主库了，那么这时就可以说保证了主从一致性了

但是比较同步文件的执行记录方法的问题在于，如果当前的这个事务的binlog尚未传入到从库，即Master_Log_File和Read_Master_Log_Pos未更新，也就无法保证从库已经包含最新的主库事务了。

而为了保证在一主一备的情况下，从库里一定接受到数据了，也就是Master_Log_File和Read_Master_Log_Pos中的数据是和主库一致的，我们可以开启semi-sync replication半同步复制。

半同步复制的原理是在主库提交事务前先将binlog发送给从库，然后当从库接受后返回一个应答，主库只有在接受到这个应答之后才返回事务执行完成。这样就可以保证从库的Master_Log_File和Read_Master_Log_Pos与主库是一致的，从而解决了主从一致的问题。

半同步复制可以解决一主一备的情况，但是当一主多备的时候，只要主库接受到一个从库的应答，就会返回事务执行完成。而这时当请求打到未完成同步的从库上时就会发生主从延迟。

所以针对一主多备的情况，我们可以将目光集中在执行查询的从库上，即确保 我们即将查询的备库已经执行了我们预期的事务。 那么我们的问题就变成两部分：1 确认主库事务，2 查询数据条件。

确认主库事务

当我们提交完一个事务后，可以通过执行show master status来得到主库中的数据事务文件（File）和位置记录（Position）。

查询数据条件

当我们要查询从库数据的时候，我们可以通过语句select master_pos_wait(File, Position, 1);来查询当前是否已经执行到了该记录（当返回值>=0的时候说明已经执行过了）。其中最后的数字1表示阻塞时长。

通过先确认主库事务记录，再判确认备库是否已经执行了了主库对应的事务。

但是可以发现，这种方法要求查询的时候知道主库的事务信息，对场景有很大的限制。

主从一致的问题源自主从延迟，所以我们就是从如何消除延迟来解决问题。简单点的方案我们可以不走备库、或者直接等待一段时间来忽略延迟的影响。在一主一备的情况下我们可以粗力度的用seconds_behind_master来判断或者用Relay_Master_Log_File和Exec_Master_Log_Pos来判断。而当一主多从的情况下我们则需要在查询前传入主库执行的事务记录才能保证数据一致性。

可以看出，当数据规模和部署方式变更的时候，好的解决方案将会越来越多。我认为根据实际业务情况选择最合适的方法才是最重要的。

读写分离主要目的是提高系统吞吐量。某些网站同一时间有大量的读 *** 作和较少的写 *** 作。同时，读 *** 作对数据的实时性要求并没有那么高。在此前提下，可以这么设计解决方案。

所以你问题里“数据仍然需要同步”这个理解是不对的。事实上，正是由于允许用户读到几秒钟甚至几分钟前的数据，才可以使用读写分离的。

数据库里面concurrency control是最复杂的组件之一。因为transaction是原子性的，但要保证原子性就得上锁，要不然读写 *** 作之间就有inconsistency。为了减少锁的代价，数据库往往会提供多种consistency level供选择。

而如果读写分离了，那么只读 *** 作的那些服务器就完全不需要考虑锁的问题了，完全可以选哪个最低代价的consistency level。只有执行写 *** 作的服务器需要用强的consistency level。虽然读服务器也需要隔一段时间更新一下，但只有更新时才需要加锁。

所以这种方案其实就是以数据的时效性，换取了读 *** 作的吞吐率。

mysql

最常用的主从复制就是读写分离的功能

数据有修改，会通过网络将执行的内容传输到从库，追加到从库的重做日志（replay-bin），然后再通过重做日志还原主库的 *** 作以达到同步的效果

---------------------------------------

oracle

常用的读写分离方案有DG（备库可读）

*** 作写入archivelog，再通过网络传输到备库，备库再用archivelog还原数据，已到达同步的目的。

如果系统磁盘快满了，可能会影响系统性能。我们可以采取以下措施来解决这个问题：

1 删除不需要的文件或程序以释放磁盘空间。可以使用磁盘清理工具或手动删除文件。

2 移动一些较大的文件到外部存储设备上。例如，将照片、视频等移动到 USB 或外置硬盘。

3 优化数据库，减少其大小。可以采用数据压缩、分区等方法。

4 使用云存储技术，将数据存储在云端，减少本地磁盘占用。

5 增加磁盘空间，可以考虑更换更大容量的硬盘或扩展磁盘空间。

以上方法都可以帮助缓解系统磁盘快满的问题，同时实时读取数据库数据也不会受到太大影响

业务发展初期，数据库的压力相对较小，这时候使用单独一个库就可以。

引出的问题：如果数据库出现故障，我们的业务就不能使用，只能说是停机重启修复故障。

由于单体带出的问题，这时候我们就需要加一个备用库，紧急情况可以用备库顶上，相当于加一个替补队员。

通过MySQL自带的主从同步机制，就可以放我们的替补队员上线。

当正式队员（主库）发生故障，我们就可以人工让其下线，让替补队员（备库）顶上。

引出的问题：随着业务大规模爆发，主库的压力过大，我们就想让备库承担起更大的责任来。

读写分离架构本质也就是主备架构，与主备架构没有本质区别，就是在主备架构的基础上，增加一层对读写请求的处理，使其能够更大程度上利用备用库为我们分担一些读的压力。

读写分离架构，需要在中间加一层控制读写请求的路由

分库分表的本质上是切分数据，是由于数据量级的提升，不对数据切分会严重影响数据库读写性能。

甚至是如果不切分，磁盘、内存、CPU无法承载这样的压力，数据库随时在奔溃的边缘。

分库分表与前三者是有本质区别的，分库分表后每一个库分片都可以采取以上三种方式的任意一种，可以是单体分片，也可以是主备分片，也可以是做了读写分离的分片。

分库分表和前三者中的一种是共生的关系。

不知道如何进行分库分表设计的可以读我之前的这篇文章《收好这份武林秘籍，让你分库分表再无烦恼》

在应用程序和数据库之间增加代理层，代理层接收应用程序对数据库的请求，根据不同请求类型转发到不同的实例，实现读写分离的同时还可以实现负载均衡（读请求按照负载均衡的规则传入各个从节点）。

代理也就是借助中间件的方式，控制不同类型请求，进入不同的数据库。

目前常用的mysql的读写分离中间件有：

在程序中进行控制，我们利用持久层框架的拦截器实现，动态路由不同数据源。

利用Sharding-JDBC也可以实现

实现思路：

主从复制模式，一般都是异步写数据到从库，当然这个异步也可以设置为同步，只有当从库写完成，主库上的写请求才能返回。

这种方案是最佳单也是最有效的一种，但也是性能最差的一种，尤其是有大量从库的情况下，严重影响请求效率。

写请求时缓存记录一个key，这个key的失效时间设置为主从同步的延时，读请求的时候先去缓存中确认是否存在key，如果key存在说明发生了写请求，数据未同步到从库，这时走主库即可，若不存在这个key，直接走从库的查询即可。

中间件应该也是可以判断是否同步完成，与使用缓存记录类似。

这种方案最大的弊端是引入了缓存，系统复杂度上升。

对于一些特殊的业务场景，采用强制读主库。

弊端，需要把每一个这种情况都找出来，设置成强制走主库。

MySQL 在执行完事务后，会将该事务的 GTID 会给客户端，然后客户端可以使用该命令去要执行读 *** 作的从库中执行，等待该 GTID，等待成功后，再执行读 *** 作；如果等待超时，则去主库执行读 *** 作，或者再换一个从库执行上述流程。

MariaDB 的 MaxScale 就是使用该方案，MaxScale 是 MariaDB 开发的一个数据库智能代理服务(也支持 MySQL)，允许根据数据库 SQL 语句将请求转向目标一个到多个服务器，可设定各种复杂程度的转向规则。

有延迟就有延迟，对数据强一致性要求不高的场景可以放任不管。

不同软件或网站可以使用同一个数据库，注意事项

软件要注意设置连接方式正确，账户密码正确。

不同的软件或网站，设置同一个数据库时可以设置不同的表头名称，即可在同一个库内区分不同的应用对应的不同数据归属，同时进行读写编辑。

以上就是关于数据库读写分离如何保证主从一致性全部的内容，包括:数据库读写分离如何保证主从一致性、为什么数据库读写分离能提高数据库的性能、数据库的读写分离数据库是怎么同步的等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！