读写分离
读写分离,字面上理解是讲读和写分开。拥有多台数据库,主节点负责写入和少量读取,多个从节点负责分担查询。
缓存,在绝大多数项目的地位举足轻重。缓存,它具有在快速响应大量请求,保护下层数据库不被过量请求压垮等优点。但是,缓存能完全代替数据库吗?当然是不能。
那么,接下来,看这样一个例子
大多数的应用最开始都是单体结构,一个程序包,一个数据库,好一点会有一个缓存层。现在有每秒8000个请求,其中1000个是写入请求,7000个是读取请求。4000个读取请求能在缓存层得到结果并正确响应。那么,这个时候,将会有3000个读取请求进入数据库,1000个写入请求进入数据库,共4000个请求,4000个请求进入数据库后,如果数据库性能低一点,会直接将数据库冲垮。那有没有好的解决方法呢?有,MySql主从复制。主库负责写入,从库负责分担查询。
MySql主从复制
这张图是MySql经典架构图。在这里引用,向大家说明基本原理。使用MySql主从复制最少需要两台数据库做主从架构,1台主数据库,用来进行写入操作。1台从数据库,用来分担查操作。
主库把SQL请求记录到自己的binlog日志中,从库去请求主库的binlog日志,并将binlog日志写到中继日志中,然后从库重做中继日志的SQL语句,并执行到从库。
这个同步过程可以同步进行,也可以异步进行。同步是指,主库确认从库收到消息才会提交。异步则是写入和推送消息变更分开。大多数情况下,我们的业务都是需要异步同步。
MySql主从复制延时
由此发现,异步同步数据的方式,同步时间不太好掌握。这样会带来一些问题。比如:
- 连续多次对同一数据进行变更。第一次变更后的数据还未同步到从库,第二次变更紧接着就进行。这样会导致,第二次变更的内容有可能是错误的。
- 数据变更后,页面进行列表展示,有可能展示到变更前的数据。
- 内部系统调用,内部实时统计有可能读取到旧数据。
如何解决这一问题呢?
- 程序上进行规避(例如:使用缓存层对新添加或者新修改的内容进行缓存一定时间)
- 数据库同步时间以及同步效率进行摸底,并配置相应的参数(MySql同步模式配置、参数调整)
一般情况下,MySql主从同步时间是毫秒内延时,压力上来后,才会明显感觉到延时问题存在。
MySql主从复制优缺点
优点:
- 对开发者透明
- 打破系统读性能瓶颈
- 数据库进行备份时,可是选择从库进行备份,降低对主库影响
- 使持久层变成高可用、高性能架构
缺点:
- 主从同步延时
- 需要系统对同步延时造成的数据不一致进行补偿
云顶云(yundingyun.com)是国内首批专注于云计算与大数据服务的提供商,致力于“让云计算更简单”。做为阿里云五星授权服务中心,云顶云致力于为企业和*提供方案咨询、架构设计、部署实施、系统定制、运维托管、技术培训等全方位“4S”级公有云、私有云定制化服务。