高并发下处理主从数据库延时导致脏读的方案

本文以陈述基础为主,有意见欢迎大佬指正,综述参考的文章见文章末尾。
为了理解标题的问题,我们先了解一下以下几个基础概念:

什么是脏读

简而言之,脏读指的是某次事务读取到的数据是脏数据(即与最终数据库不一致的数据),发生的情形来自于由于不同事务交错操作导致的读取数据错乱。

举个例子,A事务读取B事务尚未提交的数据,此时如果B事务发生错误并执行回滚操作,那么A事务读取到的数据就是脏数据。就好像原本的数据比较干净、纯粹,此时由于B事务更改了它,这个数据变得不再纯粹。这个时候A事务立即读取了这个脏数据,但事务B良心发现,又用回滚把数据恢复成原来干净、纯粹的样子,而事务A却什么都不知道,最终结果就是事务A读取了此次的脏数据。

在这里插入图片描述

高并发与分布式

高并发与分布式更多是抽象理念,本文只阐述简单概念,帮助构造业务场景即可。
高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。
高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。

不可避免地,高并发会带来一系列的问题,比如cpu过高,内存溢出等等,所以又引入分布式这一概念理解。

分布式是为了解决单个物理服务器容量和性能瓶颈问题而采用的优化手段。该领域需要解决的问题极多,在不同的技术层面上,又包括:分布式文件系统、分布式缓存、分布式数据库、分布式计算等,一些名词如Hadoop、zookeeper、MQ等都跟分布式有关。

从理念上讲,分布式的实现有两种形式:
1.水平扩展:当一台机器扛不住流量时,就通过添加机器的方式,将流量平分到所有服务器上,所有机器都可以提供相当的服务;
2.垂直拆分:前端有多种查询需求时,一台机器扛不住,可以将不同的需求分发到不同的机器上,比如A机器处理余票查询的请求,B机器处理支付的请求。

主从数据库

用来建立一个和主数据库完全一样的数据库环境,称为从数据库;主数据库一般是准实时的业务数据库。这样做有什么好处呢?

第一,备份功能,如果主库数据丢失或者损坏,可以及时切换至从库,避免在线的损失;
第二,提高数据库性能,随着业务量的增加,I/O访问频率也会更高,单机无法满足,此时建立多个从库可以有效分配存储,降低对单个库的I/O频率,提高单机的性能;
第三,读写分离,对于报表尤其重要,部分慢查询可能导致锁表,严重降低了前台服务的效率(如页面SEO),但如果分主从库后,前台使用master,报表使用slave,那么报表sql将不会造成前台锁,保证了前台速度。

问题场景

当主库的TPS并发较高时,产生的读写数量超过slave一个sql线程所能承受的范围,那么延时就产生了,主库数据更新前,从库已经读取旧数据,此时出库更新操作,从库刚好读完,得到的还是旧数据,即脏读操作。

解决方案

综合网上大部分文章和导师的方案可以分为以下几类:
1.复制类:具体分为主从复制,半同步复制和异步复制。
2.减少锁的竞争
3.提高机器配置
4.强制主库操作
5.使用中间件mysql_proxy
具体的文章可以参照参考文章[4],不做赘述。

参考文章:
[1] 快速理解脏读、不可重复读、幻读
[2] 分布式、高并发、多线程,到底有什么区别?
[3] 主从数据库详解
[4] MySQL 主从同步延迟的原因及解决办法
[5] 先更新缓存还是先更新数据库

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值