数据库读写分离的优点

数据库读写分离的优点读写分离的优点在传统的编码的过程中 往往是在数据库由于抗不住服务器的压力 或者是 IO 达到瓶颈之后 必须用到分库的时候 才采用读写分离的方案 个人认为读写分离的作用远不止此 今天 根据博主我作为程序猿的经验 来和大家分享一下数据库读写分离带来的优点 一 读写分离带来的扩展性更强在我们编码的过程中 随着项目的业务增多 必然会致使业务接口越来越多 接口越多 带来的维护成本就相对较高 如果没有对应文档的记录 即使作为研发人员的我们 都很大可能忘记那些接口有那些功能 那些接口被调用过多少次 以上就很可能带来一

读写分离的优点

在传统的编码的过程中,往往是在数据库由于抗不住服务器的压力,或者是IO达到瓶颈之后,必须用到分库的时候,才采用读写分离的方案,个人认为读写分离的作用远不止此。今天,根据博主我作为程序猿的经验,来和大家分享一下数据库读写分离带来的优点。

一,读写分离带来的扩展性更强

在我们编码的过程中,随着项目的业务增多,必然会致使业务接口越来越多,接口越多,带来的维护成本就相对较高,如果没有对应文档的记录,即使作为研发人员的我们,都很大可能忘记那些接口有那些功能,那些接口被调用过多少次。

以上就很可能带来一个很严重的问题,举例说明:在学校考试成绩管理系统中,我写了100个select接口,10个insert接口,10个update接口,10个delete接口,分别对应不同业务需求,这些接口被调用的次数无限,随着服务器的压力增加,需要对部分查询接口(查询最新的成绩等)进行优化,最开始的常见的查询方式可能是按照直接在数据库中查询时间最新的成绩记录,进行返回,优化的方案为给最新的成绩记录打一个标记。可是,后续的插入,修改,删除接口,都需要更新标记,如此多的接口,在没有文档的情况下,维护起来基本不可能,此时要怎么办呢?

此时都希望,要是所有的插入,修改,删除(即写接口)都可以调用一下我的维护标记接口就好了,对!要是按照读写分离的架构进行设计,我们就可以把我们的维护接口写到写接口里面,这样可以极大简化我们的维护量。

二,读写分离方便管理

按照数据库的常用接口,由于功能的特定性,增,删,改可以归为一类,查可以单独归为一类,采用读写分离的数据库设计,在业务调用起来更加规范,相对于增删查改一起,粒度较小,更容易管理。

而且写接口容易对数据造成影响,写文档的时候可能需要重点记录,读取接口由于不会影响数据,相对好管理一点,博主一向的原则是重点记录写接口,能复用的不增加接口。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/232980.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号