读写分离之MySql主从复制

读写分离

读写分离,字面上理解是讲读和写分开。拥有多台数据库,主节点负责写入和少量读取,多个从节点负责分担查询。

缓存,在绝大多数项目的地位举足轻重。缓存,它具有在快速响应大量请求,保护下层数据库不被过量请求压垮等优点。但是,缓存能完全代替数据库吗?当然是不能。

那么,接下来,看这样一个例子
读写分离之MySql主从复制
大多数的应用最开始都是单体结构,一个程序包,一个数据库,好一点会有一个缓存层。现在有每秒8000个请求,其中1000个是写入请求,7000个是读取请求。4000个读取请求能在缓存层得到结果并正确响应。那么,这个时候,将会有3000个读取请求进入数据库,1000个写入请求进入数据库,共4000个请求,4000个请求进入数据库后,如果数据库性能低一点,会直接将数据库冲垮。那有没有好的解决方法呢?有,MySql主从复制。主库负责写入,从库负责分担查询。

MySql主从复制

读写分离之MySql主从复制

这张图是MySql经典架构图。在这里引用,向大家说明基本原理。使用MySql主从复制最少需要两台数据库做主从架构,1台主数据库,用来进行写入操作。1台从数据库,用来分担查操作。

主库把SQL请求记录到自己的binlog日志中,从库去请求主库的binlog日志,并将binlog日志写到中继日志中,然后从库重做中继日志的SQL语句,并执行到从库。

这个同步过程可以同步进行,也可以异步进行。同步是指,主库确认从库收到消息才会提交。异步则是写入和推送消息变更分开。大多数情况下,我们的业务都是需要异步同步。

MySql主从复制延时

由此发现,异步同步数据的方式,同步时间不太好掌握。这样会带来一些问题。比如:

  1. 连续多次对同一数据进行变更。第一次变更后的数据还未同步到从库,第二次变更紧接着就进行。这样会导致,第二次变更的内容有可能是错误的。
  2. 数据变更后,页面进行列表展示,有可能展示到变更前的数据。
  3. 内部系统调用,内部实时统计有可能读取到旧数据。

如何解决这一问题呢?

  1. 程序上进行规避(例如:使用缓存层对新添加或者新修改的内容进行缓存一定时间)
  2. 数据库同步时间以及同步效率进行摸底,并配置相应的参数(MySql同步模式配置、参数调整)

一般情况下,MySql主从同步时间是毫秒内延时,压力上来后,才会明显感觉到延时问题存在。

MySql主从复制优缺点

优点:

  1. 对开发者透明
  2. 打破系统读性能瓶颈
  3. 数据库进行备份时,可是选择从库进行备份,降低对主库影响
  4. 使持久层变成高可用、高性能架构

缺点:

  1. 主从同步延时
  2. 需要系统对同步延时造成的数据不一致进行补偿

云顶云(yundingyun.com)是国内首批专注于云计算与大数据服务的提供商,致力于“让云计算更简单”。做为阿里云五星授权服务中心,云顶云致力于为企业和*提供方案咨询、架构设计、部署实施、系统定制、运维托管、技术培训等全方位“4S”级公有云、私有云定制化服务。

上一篇:阿里云SaaS生态战略发布,用宜搭5分钟部署OCR文字识别


下一篇:python 批量修改文件名