当前位置: 代码迷 >> 综合 >> DB slave master architecture - read, write separation
  详细解决方案

DB slave master architecture - read, write separation

热度:60   发布时间:2024-01-11 02:18:37.0

DB主从一致性架构优化4种方法 

  2016-05-18  58沈剑  架构师之路

需求缘起

大部分互联网的业务都是读多写少的场景,数据库层面,读性能往往成为瓶颈。如下图:业界通常采用一主多从,读写分离,冗余多个读库数据库架构来提升数据库的读性能。


这种架构的一个潜在缺点是,业务方有可能读取到并不是最新的旧数据


1)系统先对DB-master进行了一个写操作,写主库

2)很短的时间内并发进行了一个读操作,读从库,此时主从同步没有完成,故读取到了一个旧数据

3)主从同步完成

 

有没有办法解决或者缓解这类由于主从延时导致读取到旧数据”的问题呢,这是本文要集中讨论的问题。

 

方案一(半同步复制)

不一致是因为写完成后,主从同步有一个时间差,假设是500ms,这个时间差有读请求落到从库上产生的。有没有办法做到,等主从同步完成之后,主库上的写请求再返回呢?答案是肯定的,就是大家常说的“半同步复制”semi-sync


1)系统先对DB-master进行了一个写操作,写主库

2)等主从同步完成,写主库的请求才返回

3)读从库,读到最新的数据(如果读请求先完成,写请求后完成,读取到的是“当时”最新的数据)

方案优点:利用数据库原生功能,比较简单

方案缺点:主库的写请求时延会增长,吞吐量会降低

 

方案二(强制读主库)

如果不使用“增加从库”的方式来增加提升系统的读性能,完全可以读写都落到主库,这样就不会出现不一致了:


方案优点:“一致性”上不需要进行系统改造

方案缺点:只能通过cache来提升系统的读性能,这里要进行系统改造

 

方案三(数据库中间件)

如果有了数据库中间件,所有的数据库请求都走中间件,这个主从不一致的问题可以这么解决:


1)所有的读写都走数据库中间件,通常情况下,写请求路由到主库,读请求路由到从库

2记录所有路由到写库的key,在经验主从同步时间窗口内(假设是500ms),如果有读请求访问中间件,此时有可能从库还是旧数据,就把这个key上的读请求路由到主库

3)经验主从同步时间过完后,对应key的读请求继续路由到从库

方案优点:能保证绝对一致

方案缺点:数据库中间件的成本比较高

 

方案四(缓存记录写key法)

既然数据库中间件的成本比较高,有没有更低成本的方案来记录某一个库的某一个key上发生了写请求呢?很容易想到使用缓存,当写请求发生的时候:


1)将某个库上的某个key要发生写操作,记录在cache里,并设置“经验主从同步时间”的cache超时时间,例如500ms

2)修改数据库

 

而读请求发生的时候:


1)先到cache里查看,对应库的对应key有没有相关数据

2如果cache hit,有相关数据,说明这个key上刚发生过写操作,此时需要将请求路由到主库读最新的数据

3如果cache miss,说明这个key上近期没有发生过写操作,此时将请求路由到从库,继续读写分离

方案优点:相对数据库中间件,成本较低

方案缺点:为了保证“一致性”,引入了一个cache组件,并且读写数据库时都多了一步cache操作

 

总结

为了解决主从数据库读取旧数据的问题,常用的方案有四种:

1)半同步复制

2)强制读主

3)数据库中间件

4)缓存记录写key

 

3个方案在今年数据库大会(DTCC2016)上share过,相关的材料在网上能下载到。第4个方案是大会现场有其他同学share的一个好方法,感谢这位同学。

==【全文完,希望大伙有收获】==


MySQL 读写分离介绍及搭建

MySQL读写分离01

MySQL读写分离基本原理是让master数据库处理写操作,slave数据库处理读操作。master将写操作的变更同步到各个slave节点。

MySQL读写分离能提高系统性能的原因在于:

  • 物理服务器增加,机器处理能力提升。拿硬件换性能。
  • 主从只负责各自的读和写,极大程度缓解X锁和S锁争用。
  • slave可以配置myiasm引擎,提升查询性能以及节约系统开销。
  • master直接写是并发的,slave通过主库发送来的binlog恢复数据是异步。
  • slave可以单独设置一些参数来提升其读的性能。
  • 增加冗余,提高可用性。

MySQLProxy介绍

下面使用MySQL官方提供的数据库代理层产品MySQLProxy搭建读写分离。
MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy,然后经由MySQLProxy进行相应的分析,判断出是读操作还是写操作,分发至对应的MySQLServer上。对于多节点Slave集群,也可以起做到负载均衡的效果。

MySQL读写分离02

MySQL读写分离配置

MySQL环境准备

master 192.168.1.5

slave 192.168.1.6

proxy 192.168.1.2

MySQL:5.5.37

MySQL-proxy:mysql-proxy-0.8.4-linux-rhel5-x86-64bit.tar.gz

创建用户并分配权限

在配置了MySQL复制,以上操作在master执行会同步到slave节点。

启用MySQL复制

MySQL复制配置请参考这里

先关闭并清除之前的复制。

启用新的复制同步。启用之前需要清除日志

主库

从库

启用MySQLProxy代理服务器

代理服务器上创建mysql用户

解压启动mysql-proxy

其中proxy-backend-addresses是master服务器,proxy-read-only-backend-addresses是slave服务器。可以通过./mysql-proxy –help 查看详细说明。

查看启动后进程

4040是proxy端口,4041是admin管理端口

测试

保证mysqlproxy节点上可执行mysql 。通过复制同步帐号连接proxy

登录admin查看状态

2 rows in set (0.00 sec)
可以从以上查询中看到master和slave状态均为up。

1)登录proxy节点,创建数据库dufu,并创建一张表t

创建完数据库及表后,主从节点上应该都可以看到

2)关闭同步,分别在master和slave上插入数据

master

slave

3)proxy上查看结果

从结果可以看到数据是从slave上读取的,并没考虑master节点上的数据。

直接从proxy上插入数据

再次查询

结果显示查询数据没有变化,因为proxy上执行insert相当于写入到了master上,而查询的数据是从slave上读取的。

master上查询

启用复制,proxy查询

说明此时master上的数据同步到了slave,并且在proxy查询到数据是slave数据库的数据。此时,可以看到MySQLProxy实现了分离。


  相关解决方案