ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

BAT这种大厂履历意味着什么?架构师必备!

2021-05-10 10:03:22  阅读:142  来源: 互联网

标签:BAT Spring 履历 系统 插入 源码 架构师 数据 id


前言

最近一段时间发现经常看到很多人,对Spring源码比较感兴趣,日常开发中,无论你做什么什么项目,大部分都离不开Spring生态的那一套东西,所以很多人对Spring底层源码实现很感兴趣,但是有些从来没有接触过源码的开发者,在看Spring源码的过程中确实及其难受的,为什么,大部分人看源码基本都是debug一点一点去看的,最后发现,越追越离谱,越追越深,到最后都追到JDK源码了,也没有明白是什么意思!

对于学习源码,我的看法是,先去完全的熟悉它的用法,想一下如果让你来实现,你会怎么实现!有了这些想法之后,再去看源码去印证你自己的观点,远比你自己去死扣源码快的多。

而且,我问过一些读者还有同事,我发现有很多人,看源码容易陷入一个误区,就是刚开始看源码就死扣着一个细节不放,非得搞懂,我并不是说这样看源码有什么不对,但是在没有对整个框架有一个全局了解的情况下,不要这样看,你应该先把它的大体框架给搞清楚,在后再分功能一步一步的了解每一个功能项!这样做,首先你对整个框架的架构有了一个模糊的认识,再扣细节的途中有时候即使你不知道这个代码在干什么,你也隐约能猜出来,再通过debug 与自己的猜测相互印证,最终达到事半功倍的效果。当然这个建议只针对刚开始看源码的同学,如果你看的源码很多了,那么你肯定又自己的一套学习方法,可以的话,可以在评论区分享一下。

为了帮助一些萌新们或者想要了解Spring源码的小伙伴,我会把Spring的一些大体逻辑分析一下,让你了解整个Spring的骨架!

系统介绍

整个系统可以从功能上分为3块:

  1. 业务系统:在上游有很多的业务系统,业务系统的运行产生很多的数据,这些数据分散在很多的数据库中,大部分是MySQL数据库
  2. 数据智能平台:数据智能平台属于中台系统,主要为业务系统提供强大的数据支撑服务,下层连接数仓。
  3. 数据仓库: 数据仓库统一集中的管理所有的数据,数仓会将业务系统产生的数据按天进行加工、抽取、转换到数据仓库存储。

当一天结束后,各个业务系统产生了大量的数据,这些数据由定时任务进行加工、抽取到数据仓库存储,当半夜你还在睡觉的时候,这些定时任务就在默默的运行着。

而每天加工的数据通常要求在上班工作时间之前加工完成,然后通过数据智能平台的查询系统供业务系统查询调用,这一次数据没有查询到是因为在第二天早上10点,数据还没有加工完成。下面就是找问题优化了,因为正常来讲,即使定时任务链再长,也不会慢到第二天10点钟数据还没有出来。下面就是找问题,然后进行优化了。

任务优化

通过任务日志发现有一个上游系统的数据抽取执行时间有3个小时,而数据量仅100万。当然,光凭这样还无法确定这个任务是否是可以被优化的。

查看任务代码,逻辑还比较简单:有一张原始数据表,记录商品信息以及定义的分类(这一点是虚构的,实际情况要复杂一些,我这里精简然后转换了一下,便于理解),而数仓的目标表是将分类和商品分别存储在不同的表中,大致结构如下。

那为什么需要进行这样的转换呢? 这是因为整个大的系统,一般来说只能定义一些基本的规范,而具体的细节规范则无法约束,比如A系统的身份证字段名称为card_no,而B系统的身份证字段名称为crdt_no(这种情况大家应该经常遇到);再比如处理实体关系的时候,处理方式也是不同的,1对1的关系,可以建两张表关联,也可以一张表都存储,这就造成了多个系统的不统一性,而这种情况是不可避免的,因为从业务系统来说,都保证了系统的正常运行。

而数仓对多个原始数据处理的时候就需要考虑到兼容的问题,所以就会出现如上图的转换过程。

而这个任务执行3个小时的原因在于原始表中的一条记录,会转换到数仓表中的三张表中,而且这三张表是通过id进行关联,整个代码流程如下。

然而问题来了,100万的数据,跑了3个小时,然后我开始尝试去优化程序的执行流程,大概从一下几点入手

  1. 将分类缓存,分类在系统中已经固定,不会发生变化,缓存可以减少查询数据库的次数
  2. 每次从原表中读取的数据更多,从原来的500/次 -> 2000/次

经过优化,效率有一些提升,但并不是很明显(有同学可能要问了,这些都是很基本的,为什么最开始做? 咳咳。。。这个嘛,历史原因吧,在最开始数据可能不多,不论以什么方式执行,都差别不大,比如执行10分钟和执行20分钟,看似2倍的执行效率,但是由于没有影响到业务系统,且一直正常运行,也就没有看出问题)。

这里数据是需要关联的,所以我们是需要插入数据并拿到这条记录的自增长id,然后插入到关联表,而表结构基本不可能去动的(表结构动了那真是牵一发而动全身了,第二天准得被叫去喝茶)。

那么我们先来分析一下这里为什么执行这么慢呢。

  1. 原表100万的数据,每次查询出2000条,所以查询的总次数就是1000000/2000 = 500次,这肯定消耗不了多少时间。这里基本没有优化的空间,就算一次全部查询出来,也仅仅节省499次的查询时间(也不可能一次查询这么多数据)
  2. 查询的2000条数据,数据转换,然后依次插入到信息表以及关联表中,这里是一条一条解析执行的,总计插入数据库4000次,毫无疑问,这里是最耗时的。数据转换是必须的,而且是在内存中操作,所以耗时不是特别多;那么剩下的就是总计100万 * 2的数据库插入次数,能否进行优化呢?

首先想到的就是批量插入,批量插入可以有效的降低数据库访问次数。但是这里不能进行批量插入是因为需要取到自增长id,感觉陷入了困境。

当天晚上昨晚运动之后,抛开烦恼,觉得浑身舒坦。

突然,脑袋灵光一闪,数据库的自增长id是由数据库控制的数值,而自增长的步长我们是知道的,比如自增长步长为1,当前自增长id为1的话,那么可以肯定,下一条记录的自增长id就为2,以此类推。

那是否可以插入一条记录,取到自增长id,然后就可以计算出之后所有数据的自增长id,而不再需要每条记录都去取自增长id了。

但是这样也有一个问题,就是在数据转换导入的过程中,不能有其他的程序向表中插入数据,不然会导致程序计算的自增长id匹配不上。而这个问题根本不存在,因为数仓的数据都是由原始表计算插入的,在同一时间是没有其他的任务写这张表,那么我们就可以放心大胆的干了。

写在最后

学习技术是一条慢长而艰苦的道路,不能靠一时激情,也不是熬几天几夜就能学好的,必须养成平时努力学习的习惯。所以:贵在坚持!

最后再分享的一些BATJ等大厂20、21年的面试题,把这些技术点整理成了视频和PDF(实际上比预期多花了不少精力),包含知识脉络 + 诸多细节,由于篇幅有限,上面只是以图片的形式给大家展示一部分。

领取方式:戳这里即可免费领取

蚂蚁金服三面直击面试官的Redis三连,Redis面试复习大纲在手,不慌

Mybatis面试专题

蚂蚁金服三面直击面试官的Redis三连,Redis面试复习大纲在手,不慌

MySQL面试专题

蚂蚁金服三面直击面试官的Redis三连,Redis面试复习大纲在手,不慌

…(img-DaVZzWyv-1620611722935)]

MySQL面试专题

[外链图片转存中…(img-Mq8we6vg-1620611722936)]

并发编程面试专题

标签:BAT,Spring,履历,系统,插入,源码,架构师,数据,id
来源: https://blog.csdn.net/m0_56213615/article/details/116587386

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有