数据库读写分离,主从 读写分离

程序员看过来,每天一道大厂Java面试真题分享:主从数据库不一致如何解决?答案:场景描述,对于主从库,读写分离,如果主从库更新同步有时差,就会导致主从库数据的不一致1、忽略这个数据不一致,在数据一致性要求不高的业务下,未必需要时时一致性 。
DB读写分离情况下,如何解决缓存和数据库不一致性问题?
【数据库读写分离,主从 读写分离】有两种方案 。先来了解什么情况下会产生缓存和数据库数据不一致 。查询数据时优先从缓存中取,如果缓存没有就查询数据库并且写入缓存 。如果数据库数据改变了则清除缓存 。在正常情况下是没有问题的 。但是在服务的并发非常高的情况下,删除了缓存此时数据库还没来得及更新完数据就又有查询请求来了,这时候读到的还是旧数据并且还会将旧数据写入缓存 。
此时就造成了缓存和数据库不一致 。第一种解决方案:延时删除 。在改变数据库数据时清除缓存的操作延时一段时间,这段时间可以非常短,只需要保证数据库写操作完成就可以了 。但在实际环境中我们并不知道数据库什么时候才把数据写完成,因此这段时间不好控制,短了的话起不到作用,长了的话影响体验 。不过在一般情况下这种方式已经可以解决问题了 。
MYSQL中读写分离有什么样的好处呢,为什么一些人都选择读写分离?
现在绝大部分软件项目,都会使用到关系型数据库,比如MySQL、Oracle、DB2等等,目前这些数据库的单机性能已经是不断优化和提高了,但是随着数据增长的速度和并发访问量的增加,在某些公司、某些场景下,单机数据库已经很难满足业务的需要了,所以必须考虑数据库集群的方式来提高系统的可用性;最常见的两种方法:分库分表:把数据分散到不同的数据库上,每台数据库中存储的数据是不相同的(这里先不考虑每个库做备份或读写分离);分库分表既可以分散数据库访问的压力,也可以分散数据存储的压力;但是使用分库分表方案的时候,会带来扩容、事务、关联查询等问题和难点,具体这里就不展开讲了 。
读写分离:将数据库读操作和写操作分散到不同的节点上,通常是一台数据库做写操作,1到N台做读操作;读写分离的架构,每一台数据中的数据是相同的(这里先忽略延迟的问题),所以只分散了数据库访问的压力,并没有分散数据存储的压力;我们这里主要讲一讲读写分离 。读写分离基本架构MySQL读写分离的基本架构,可以参考下图:如上图,读写分离实现的基本步骤是:数据库服务器搭建多台,一主N从(N大于等于1);主数据库只负责写操作,从数据库只负责读操作;主数据库复制数据到从数据库上;客户端写操作路由到主数据库上,读操作路由到从数据库上 。
读写分离还有另外一种架构,就是在MySQL数据库和客户端之间,增加一层中间代理层,客户端只连接代理,由代理根据请求类型,把请求分发到不同的数据库上:第一种架构,整体架构比较简单直接,性能会稍微高一些,但是如果才用直连的方式,客户端可能会稍微麻烦一些(通常需要引入一些组件,负责管理数据库);第二种架构,对客户端比较友好,因为客户端只需要和代理交互,并不用关注数据库的具体信息;但是因为多了一层代理,多多少少会对性能有一定的影响 。
读写分离带来的好处读写分离结构中,会有两台甚至更多台数据库,这种冗余的设计,可以提高数据的安全性和系统的可用性;就算是在分库分表的架构中,每一台子库,也可以一主多备的部署方式;读写分离更多的时候使用在读操作远远大于写操作的场景下,这样可以保证写操作的数据库承受更小的压力,也可以缓解X锁和S锁争用;服务器数量的增加,意味着可以有效地利用多台服务器的资源;读操作被分摊,提高了系统的性能;如果写操作比读操作多,或者相近,可以采用双主相互复制的架构 。

推荐阅读