后期数据库主从架构的痛点,真的痛

2024-05-24 14:18

本文主要是介绍后期数据库主从架构的痛点,真的痛,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

原创:猿天地(微信公众号ID:cxytiandi),欢迎分享,转载请保留出处。

读写分离是什么?读写分离的作用就不讲了,如果有不了解的同学可以自己去搜索资料进行了解。或者查看我之前的文章读写分离。

一开始的场景肯定都基于主库去做增删改查的操作,等后面压力慢慢上来后才会考虑加数据库的从节点,通过读写分离的方式来提高查询的性能。

image.png

首先读写分离默认查询都是走从节点的。

image.png

从我们的使用习惯或者业务的场景来说,查询的场景是大于增删改的。所以我们会在需要走主库进行数据操作的业务场景下,手动去控制这条Sql要去主库执行,这个控制的逻辑可以自己写,也可以利用框架自带的功能实现,就不细讲了。

比如我们定义一个注解 @Master 用于标记此方法走主库操作,然后通过Aspect可以去切换数据源。这其实是很常见的实现方式,如果说你一开始就有从节点,就规范了这么做是没问题的,如果是后面新增了从节点要开始做读写分离,这么做是存在问题的。

一旦这么做的话,对于增删改的操作没有问题,对于查的操作可能会有问题。这个问题不是说有Bug,而是有一些体验上的问题可能会导致Bug。大家都知道主从架构其实是存在数据延迟的问题,只要有延迟那么就有可能出现问题。

某些业务场景下,你新增了一条数据,然后会马上跳到详情去,此时如果数据有延迟,到详情的时候去查询从节点,就查不到刚刚新增的数据,会存在这样的问题。

解决办法就是把所有业务场景都整理下,然后让测试整体回归一遍,将需要走主库操作的查询方法都加上 @Master 注解,就不会有问题了。

看似没有任何问题,其实大家忽略了一点就是时间成本问题。要整理业务场景,要整体回归测试,这些都是要花时间的,时间就是最大的成本。

所以我们在后期做读写分离的时候,基本上不会采用上面的方式去实现,因为业务功能越多,成本越高。

真正的做法是反着来,无论实现任何新功能,我们都要考虑的点就是如何让影响最小?如何不影响之前的逻辑?

方法就是所有的老逻辑都不动,默认还是走主库,但是我们程序中已经做了读写分离的功能,默认查询就是会走从库的,所以第一步就是要将所有查询的Sql都发往主库,可以通过Aspect实现。

image.png

做完了上面这一步就可以直接上线了,因为所有的操作还是走的主库,跟以前没有任何区别,不会影响任何老的逻辑。

现在就要考虑哪些查询可以走从库了,但是这个动作可以慢慢做,可以慢慢梳理。这样就会比较轻松了,每个迭代我们可以梳理几个走从库的查询,直接加个 @Slave 的注解让它强制走从库,这个场景我们梳理过,验证过是没问题的。就这样慢慢的整理,直到所有老逻辑都梳理完。

image.png

好的思路能够保证稳定性和易用性,如果有收获那就点个赞呗!

关于作者:尹吉欢,简单的技术爱好者,《Spring Cloud微服务-全栈技术与案例解析》, 《Spring Cloud微服务 入门 实战与进阶》作者, 公众号猿天地发起人。

这篇关于后期数据库主从架构的痛点,真的痛的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/998640

相关文章

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

mybatis的整体架构

mybatis的整体架构分为三层: 1.基础支持层 该层包括:数据源模块、事务管理模块、缓存模块、Binding模块、反射模块、类型转换模块、日志模块、资源加载模块、解析器模块 2.核心处理层 该层包括:配置解析、参数映射、SQL解析、SQL执行、结果集映射、插件 3.接口层 该层包括:SqlSession 基础支持层 该层保护mybatis的基础模块,它们为核心处理层提供了良好的支撑。

百度/小米/滴滴/京东,中台架构比较

小米中台建设实践 01 小米的三大中台建设:业务+数据+技术 业务中台--从业务说起 在中台建设中,需要规范化的服务接口、一致整合化的数据、容器化的技术组件以及弹性的基础设施。并结合业务情况,判定是否真的需要中台。 小米参考了业界优秀的案例包括移动中台、数据中台、业务中台、技术中台等,再结合其业务发展历程及业务现状,整理了中台架构的核心方法论,一是企业如何共享服务,二是如何为业务提供便利。

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

如何解决线上平台抽佣高 线下门店客流少的痛点!

目前,许多传统零售店铺正遭遇客源下降的难题。尽管广告推广能带来一定的客流,但其费用昂贵。鉴于此,众多零售商纷纷选择加入像美团、饿了么和抖音这样的大型在线平台,但这些平台的高佣金率导致了利润的大幅缩水。在这样的市场环境下,商家之间的合作网络逐渐成为一种有效的解决方案,通过资源和客户基础的共享,实现共同的利益增长。 以最近在上海兴起的一个跨行业合作平台为例,该平台融合了环保消费积分系统,在短

系统架构设计师: 信息安全技术

简简单单 Online zuozuo: 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo 简简单单 Online zuozuo :本心、输入输出、结果 简简单单 Online zuozuo : 文章目录 系统架构设计师: 信息安全技术前言信息安全的基本要素:信息安全的范围:安全措施的目标:访问控制技术要素:访问控制包括:等保

深入理解数据库的 4NF:多值依赖与消除数据异常

在数据库设计中, "范式" 是一个常常被提到的重要概念。许多初学者在学习数据库设计时,经常听到第一范式(1NF)、第二范式(2NF)、第三范式(3NF)以及 BCNF(Boyce-Codd范式)。这些范式都旨在通过消除数据冗余和异常来优化数据库结构。然而,当我们谈到 4NF(第四范式)时,事情变得更加复杂。本文将带你深入了解 多值依赖 和 4NF,帮助你在数据库设计中消除更高级别的异常。 什么是

DM8数据库安装后配置

1 前言 在上篇文章中,我们已经成功将库装好。在安装完成后,为了能够更好地满足应用需求和保障系统的安全稳定运行,通常需要进行一些基本的配置。下面是一些常见的配置项: 数据库服务注册:默认包含14个功能模块,将这些模块注册成服务后,可以更好的启动和管理这些功能;基本的实例参数配置:契合应用场景和发挥系统的最大性能;备份:有备无患;… 2 注册实例服务 注册了实例服务后,可以使用系统服务管理,

速了解MySQL 数据库不同存储引擎

快速了解MySQL 数据库不同存储引擎 MySQL 提供了多种存储引擎,每种存储引擎都有其特定的特性和适用场景。了解这些存储引擎的特性,有助于在设计数据库时做出合理的选择。以下是 MySQL 中几种常用存储引擎的详细介绍。 1. InnoDB 特点: 事务支持:InnoDB 是一个支持 ACID(原子性、一致性、隔离性、持久性)事务的存储引擎。行级锁:使用行级锁来提高并发性,减少锁竞争

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者