敖丙

敖丙 查看完整档案

杭州编辑北京邮电大学  |  计算机科学与技术 编辑蘑菇街  |  算法工程 编辑 juejin.im/user/59b416065188257e671b670a 编辑
编辑

个人动态

敖丙 发布了文章 · 10月20日

程序人生|从网瘾少年到微软、BAT、字节offer收割机逆袭之路

引言

今天给大家分享一个我的读者的故事,这个故事很长,从游戏boy到offer收割机,从富士康到百度再到微软,国内知名大厂的公司他都拿了一遍offer。

这当中有太多心酸和努力,在他的身上我也能看到一些自己的影子,希望大家可以从他的文章里有所收获,有所感悟。

话不多说,我们来听他的故事。

正文

国庆节的第一天,自习室里已经没有什么人了。窗外,西安的秋天飘一点点雨,坐在电脑前心情十分平静。想在这个难得的闲暇里,想起记录一下自己这些年的经历,也是给自己留一点以后可以回忆的故事。

个人2014年入学,武汉某大学计科相关专业,学科评估200名开外。

大一上学期一门专业课差点挂科,直接奠定了无法保研的局面,开始浑浑噩噩混了两年。除了高数上下,其他能逃的课基本都用来打英雄联盟了。

16年升大三的暑假,一个偶然的机会看到隔壁院的师兄发在群里的一条实习招聘,是武汉富士康招聘软件测试实习生。

暑期岗位,能签实习证明,有班车来学校接送,一天还有220工资。我觉得这是个很好的机会,起码富士康这个厂也算有些名气,能赚个实习经历还有点工资。

我向师兄报了名,简历里面特别注明了大学C语言92分,班级第二。简历通过的还算顺利,也没有面试,直接就让去了。

当时负责的任务主要是Windows 10 SP1的多国版本测试任务,跟我以为的进去的写代码相差甚远,就是个黑盒测试吧,或者再说直白些,就是点点点的无脑操作没什么技术含量。

不过由于是对接外企,所以任务都是英文下达的,有时候翻译还是得花点功夫,英文能力倒是得到些许锻炼。测试需要自己组装机器,选择各型号的cpu和显卡等配件。

因为是第一份实习,我学习的非常认真,直到现在我仍然能够闭上眼睛,清晰完整的回忆出一台整机的拼装全过程。

CPU的引脚,内存条的金手指和各式各样的SATA线束是那段时间接触最多的东西。

机器点亮后就开始做DASH(从服务器上下载测试版本的系统并安装),然后是激活系统开始对照着测试用例展开测试。

差不多两个星期之后,常规的操作已经比较熟练了,任务也显得逐渐无聊了起来。由于DASH的过程很漫长,我经常会在三楼到四楼的楼梯口望着窗外的太阳,不知道是哪个有趣的同事在窗台用矿泉水瓶养了一个小叶子,我看着这抹绿色总是很舒服。

富士康的生活很规律,八点半到工位,五点半出公司,日复一日的装配着各种方案让我在想,以后我要从事这种枯燥但是轻松的工作吗? 想了想还是写代码做需求比较有意思。

由于本科学校不太好找工作,而我自认代码能力还可以,所以我决定通过考研来获得一个更好的教育背景或者说,一个让公司能够看上的背书。

大三暑假正值备考,跟我关系不错的老师给了我一个机会,说有个师兄在美团,想把我的简历推给他。我当然很激动,花了一下午的时间准备了一份简历:xx学校,计算机专业,主语言java,曾经做过xx校园app的后端功能以及一个在线OJ评测网站... ...

简历发给了老师,一天,两天,一个星期过去了,老师说那边认为简历还是太单薄了,不能发起面试。

那天我感到一阵失落,我以为起码能有个面试机会,结果却是简历都过不了。

我对自己的代码水平还是比较有信心,但恰恰是这种信心带给了我更大的失落。我生气的跟舍友说,以后绝对不去美团,他求我去我都不去。这当然是一个大话,只是孩子心气地不肯承认罢了。

考研历时五个半月,还算顺利地通过了初试复试,来到了西安的一所高校开始了研究生阶段的学习。

那时候有同学说,一个叫字节跳动的公司能开很高的工资,不过对算法题的要求很高。

这也是我第一次听说字节跳动,研究生的课和本科其实没有太大的区别,至少对我来说都是不怎么听的进去的(当然也有部分非常优秀的课程,这是后话了)。

但我在课上发呆的时候,慢慢地却不会再去想我要怎么操作我的英雄站在兵线前面干掉对面的玩家,LOL至今都没时间再玩了,时不时看看比赛倒也对青春有个交代。

<img  style="border-radius: 0.3125em;
box-shadow: 0 2px 4px 0 rgba(34,36,38,.12),0 2px 10px 0 rgba(34,36,38,.08);" 
data-original="https://m.qpic.cn/psc?/V12w6YIp4GQ5pr/bqQfVz5yrrGYSXMvKr.cqXpLZKuvoQw5kIZ6DG1L4Gst9rS7q3SpJaiYiZE.lzn1t*nvJ7he89lfvt*BtlKvuJGoGUgVsPhWzNMYR73Va9Y!/b&bo=gAc4BAAAAAABB5s!&rf=viewer_4">

研究生阶段无聊的时候,一般我会打开牛客网,在上面做几道题目,看着各种计算机网络和操作系统的知识,总觉得自己永远也学不完了。在浏览讨论贴的过程中,我渐渐发现网友会去做一些算法题的训练,一般在leetcode上。我也随之注册了这个网站,全英文的界面让我觉得很有范。

没多久我就决定要开始我的刷题之路,我仍然记得第一题好像是求两数之和,其实这个题目我在备考时的九度OJ上做过,感觉应该难度不算太大,磨了一些边界之后,当一个绿色的Accept出现在眼前,我觉得这种感觉就像是我用XX√√√完成了一局BO5晋级赛。

于是我的生活变得更简单了,能逃的课就在寝室和图书馆刷LEETCODE,不能逃的课就在课上刷LeetCode。我尽量保持在一天6+的题量,有时候会做到10+,我喜欢看到登录界面上的绿点连成一片的样子。

不过由于课程作业和考试原因,有时候也会中断好一会。我非常清楚的记得在一个下雪的午后,我完成了在Leetcode上的第一百个Accept,那一题调了两个小时,是LRU置换算法的实现。我激动的发了一条朋友圈,拍下100/1300的标记。

我觉得我好像会离字节这样的公司近一点了,在刷题的过程中我也会穿插着学习一些计算机网络的东西,主要是为了应付面试。搜索的资料很杂,大部分来自博客和B站。

包括在刷题的过程中我看的算法视频也是在B站搜罗的盗版,主讲人是左程云左神,也是我心目中永远的真神。那一版的视频左神的桌面还是齐天大圣飘着红色披风的背影,后来在北京时期我补上了欠左神的正版课,这也是后话了。

研一暑期我也开始投一些公司的实习,我惊奇的发现,大部分的笔试都拦不住我了,反正基本没有因为笔试挂过的公司,也拿到了一个不错的机会,但因为一些原因未能成功去实习。

后来看着同学们都出去了外面的公司实习,我的心里又开始痒痒了,打开牛客网,翻查着有限的实习信息,看到一个爱奇艺的招聘机会。

一轮大概50分钟左右的面试,主要是针对OJ项目,后面问到了Java异常机制,泛型的实现,FutureTask的实现思路,以及一些线程池的问题,线程池这个我没用过所以就说不会。

当天晚上八点,面试官问我公司在北京,能不能来实习,我想都没想就说地点绝对不是问题,于是我定了第三天最早的一班高铁,花了一天的时间收拾东西,其实我不是为了带走什么,只是要把它们放在朋友那里。

我带走的只有一个背包,里面放了两天的换洗衣物,我的各种证件,一小盒谷维素(改善失眠)和一本深入理解Java虚拟机。我觉得做Java的人,这个东西带在身上就很有安全感,有信仰陪着我,虽然我从来也没有翻开过。

房子是在高铁上租的,转租的人是个字节跳动的运营,地点就在人大旁边,离爱创大厦很近。

我还记得当时我的leader在做完新手教程后,就过来帮我搬电脑,带我整理工位,简单的交代了一下之后,就慢慢的开始了开发流程。

第一次进入大公司实习,第一次来到首都北京,红绿灯前等待的全部都是清一色年轻的面孔,有那么一个瞬间我恍惚地看到,斑马线变成了律动地音符,而这个城市年轻人的心跳就是它的节拍。

我喜欢早上骑着师兄传给我的美利达,再放一首Young For You, 我觉得我就是属于这个时代的年轻的人儿。

作为新人,要学习的东西很多,一般我会十点半以后下班。而且我喜欢前紧后松,所以会把心中的工期排的靠前一点。

我惊讶于自己学了一年没学懂的Spring框架在公司捣把捣把竟然就能上手一些项目了,这种学习的速度是我从来没有想过的。

周末我也会在公司赶需求或者自我学习,累了就去对面吃一个麦当劳甜筒,有时候也会去咖啡厅坐会。那通常是因为我解决了一个困扰很久的Bug.虽然在爱奇艺的生活很充实,但是心中还是有一份大厂梦。

19年的国庆,整整八天我都呆在公司看着各种字节跳动的面经和算法题,只要有一题我觉得我可能不能100%实现,我都会上Leetcode立马把它AC掉。

行内的朋友可能知道这是怎样的痛苦,因为一道题有思路和真正稳稳地实现它,中间的差距实在太大了。

7号的晚上,我坐在电脑前,关上所有的页面,打开Eclipse,花一分钟或者几十秒撸了一发快排,测试用例直接写在main里,一把过,我关上了电脑回家。

这是我自己的习惯,每逢大战,我都会在最后以一个快排收尾,因为当年就是这个代码断了我的保研路。开发的时候我用的更多的是IDEA,但是写算法题我只用Eclipse, 因为算法题对依赖环境的要求很低,基本上有个JDK就足够。

而我是个恋旧的人,所以我把自己最擅长的方面,留给我的老朋友Eclipse。

结果并不像过程一般顺利,也不是每个幸运都会眷顾努力。

12号一天两个公司面试,分别在早上10点和晚上7点开始。紫金数码园成为了我永远的痛,我记得他们问的都是比较深入的问题,诸如TCP,UDP能不能绑在同一个端口,Java的线程底层是如何实现的,TCP和IP的详细报文结构,报头,进程切换的上下文到底包括什么,哪些寄存器,CFS算法如何实现的等等。

最后我实在烦了,我说我就不会操作系统,他又问了个字符串匹配算法,我给他详细的讲了KMP的实现,然后他让写个树的深度遍历。我火一下子上来了,我觉得你可以挂我,但是不要用这种简单的东西来拖一下面试时间让我体面的离开。

我就说:这个东西太简单了,我不想写,你可以问个难点的。

他让我写Linux的定时器算法,我想了很久,没想出来,事实上我都没听过这个东西,自己设计了一个类似哈希表的结构希望来存放这些定时任务。他表示摇头,我知道今天就到这里了。

现在回想起来,我并没给到面试官足够的尊重,多少年少轻狂了点。

直到最近这个月,我开始认真的阅读深入理解Linux内核,才明白当时我到底错在哪(当然时间轮算法是我在第二天就去看了的)。

字节的面试是在晚上,七天的努力好像什么效果也没有,因为我准备的面经基本一点也没被问到。

走在中关村大街上,我觉得今天有点格外的冷,只能把耳机的声音调的再大一点,宝石老舅的Disco让我的情绪稍微得到了一些缓和。

细心的朋友可能发现,那天的面试有两场,这个机会说来很巧,我某次跟同学提到我想换个更大的厂,她说百度给她打过电话面试,是个私人号码,她自己已经有公司了所以不想面试。

我意识到这是个机会,招聘信息里面大部分是邮箱或者工作电话,其实联系的成功率并不高,但是这种私人电话基本是点对点,中间不存在邮箱这种轮询或者工作号码背后的一层Nginx。

我直接把号码拨过去,询问对面是不是需要招收实习生,表明了自己的学校和来意,希望对面能安排一个面试机会。

答复是肯定的,我特意要求在跟字节同一天,这样子免得我需要频繁请假,所有才有了一天之内字节和百度的两次面试。

来北京的第一个星期我就去拜访过百度大厦,西二旗地铁的一侧静静躺着一个熊掌,当我近距离看到这个标志的时候心中翻起的是澎湃和向往。

不过这次的面试在百度科技园,如果说大厦给我的感觉是大气,那么科技园就是真正的气势恢宏。

回字型的无限大标志由七栋大楼构成,K2和K1的连廊接在三楼,直接跨过了一个双向车道。面试的整体过程比较顺利,给我的面试体验也非常好,面试官会针对我简历上的技术栈由浅入深的进行询问,有些原理还会给我讲解。

三轮面试一共做了四个题,刚好打在了我的强项上。分别是最短编辑距离,最长回文字符串,变态跳楼梯和树的最长直径。我把这些题全部通关,中间还在百度食堂吃了个饭。

面试耗时3个半小时,到我出公司的时候已经是下午两点半了。

我非常感谢百度,不仅仅是因为它给了我实习的机会,更多的是对我这样一个要强的人来说,一天内连续挂掉两家公司的局面可能真的是无法接受的。

特别是字节的面试让我觉得毫无还手之力,在这种情况下,熊度就显得格外可亲。

进入百度是一个新的开始,我需要做的事情很多:学习一门新的语言,学习服务器上的开发,学习百度的一些内部工具以及...学习使用Mac。

在这些需求里面我直接砍掉了Mac的学习,把重心放在了语言和Linux上,具体的做法是我向Mentor提出把Mac换成ThinkPad。

我Mentor奇怪地跟我说:大部分人都是Windows本想换Mac,很少有你这样Mac想换Win的,我就笑笑说我时间不够用。

其实很巧的是我的Mentor也是ThinkPad,而他的技术非常强,是我们组绝对的实力担当 ,我觉得我技术路线的尽头应该就是我Mentor的样子。白天我看公司内部的各种文档,八点半下班以后我会花两个小时看Linux视频,并且做一些笔记,因为我觉得在工作时间看视频总给人一种在偷玩的感觉。

十点的西北旺还是灯火通明,出了科技园会看到旁边的网易,新浪和腾讯北京。我顺着腾讯的大楼先走到马连洼地铁站,回中关村的地铁一共要倒两趟,然后再从苏州街走回人大。

通勤时间大概在一小时四十分钟,所以到家一般都是十一点多了,我经常会在楼下的KFC买个吮指原味鸡或者鸡米花,静静地坐着吃完再回去洗澡睡觉。

期间我也想过换个住处,但是想了想,现在的房子地段很好,各种生活用品和娱乐都很多,西北旺那片还是有些冷清,还是算了。

还有一个原因是我特别喜欢人大,我在任何一个地方租房都喜欢租在学校旁边,校园的景色和人文气息都让我很舒服。

在百度的周末我一般也用来学习,通常是花一天的时间看Linux,另外一天去公司看文档。我看的书是Linux编程手册,这是我一个大牛同学推荐给我的,他初中就开始玩Linux,在社区比较活跃。

很难想象我这么一个不爱学习的人能静下心来看一本大部头的书看一下午,最深的原因是,我在北京有个漂亮的女同学,我一般都会喊她陪我在她们学校的自习室看一下午,然后去吃个饭看个电影啥的。如果这我都看不进去的话,那我真的不知道该说对不起谁了。

那段时间可能是我在北京最快乐最回忆的时光,每当地铁报站到了芍药居的时候,我都会有些悸动。

我们一起去过中关村的店,后海的店,印象最深的是第一次在万泉河的一家西餐厅。

那天她穿黑色的裙子,化了妆,坐在西餐厅的白色桌布前。我直接想到了十年以后,天是那么蓝,花静静躺在路边,我觉得我一定要好好写代码,成为一个厉害的人因为... ...

这样规律的日子我过了大概有三个月,也是我在百度呆的大半时间,我每周最大的期待就是周末可以看书的时光,因为去别人学校学习知识当然让人快乐啊。

百度楼下的蛋糕店有很好吃的慕斯蛋糕,有时候我会六点就下班,然后大概一个多小时通勤给同学带一个吃,因为这个蛋糕到六点以后基本上就买不到了。

不过很认真的说,我能坚持看Linux很重要的原因也是在字节的面试给我的打击太大了,让我认识到我在Linux这块就是一片空白。并且工作中确实遇到了相关的问题,有一次我做了一个定制化的HDFS上传程序,fork的时候在父进程中没有wait,导致服务器上产生了大量处于僵死状态的进程。

这些进程的执行流已经结束了,可是由于父进程未对它们进行最终处理,导致进程号一直被占用,久而久之可能会影响到服务器上其他进程的pid分配。

还有我们的HDFS资源比较有限,处理的数据量很大,大家的MR任务和Spark任务都在一个HDFS空间上,细碎的文件很多导致INode被占用的很严重,有时候还有磁盘,却没有足够的INode能分配了,导致任务执行失败等等。后来这种类似的问题我都在Linux编程手册中找到了对应的知识点,也让我越来越认识到它的重要性。

差不多两个月之后,我对Python和服务器上的开发已经有了一点点认识了,也开始接了一个新的项目。这个项目在工作计划上的执行人其实是我Mentor,不过他比较忙,我看了下这个活应该可以做,我就接了下来。项目的具体内容在此不方便多提,但是这个项目让我真正的接触到了很多开发中的交流,合作,踩坑,出坑,设计等等等等。

印象最深的是来自Google响应报文里面一个隐式编码的问题,Chunk协议在一些报文中会被使用,用作数据交流格式的标准。

Google的响应报文中使用了这种编码,却没有显式地声明出来,我在对报文进行了DOM树构建和重写之后,改变了报文的字符数,而Google用一个16进制的数字声明了这个长度。这个细节直接导致所有被我篡改的报文均不能在浏览器端被正常解析,表现为无限等待的界面。

这个Bug我足足改了七天,中间有一天我已经无限接近这个答案了,我把一个疑似表示长度的十六进制数进行了还原,想看看它是否指代长度。坑爹的是在服务器上看到的长度是字节数,中间涉及到编码的问题,而这个16进制数指代的是字符数,中间的差值让我一直不敢确定这个是代表长度(其实就算知道了也不可能改对,因为中文字符的字节数在UTF-8下是不同于字符数的)。

在这个开发周期中我熬过最多的夜就是这个时期了,以至于之后的需求性开发我都很轻松的完成,因为我觉得应该没有比这个Bug更加难弄的情况了(中间还有其他的问题,比如URL编码异常,Gzip的隐式刷流,开源库的DOM化缺陷,但是这些慢慢处理就好)。

这期间最让我印象深刻的是在我解决了这个问题之后一天的晚上,隔壁组对接的开发过来问我的经历我是今年的新同事吗,工作多久了。

经理哈哈大笑,说“怎么样,xx牛*吧”。隔壁的开发说确实很不错,我经理又补了一句“xx是我们的实习生”,隔壁的开发惊讶了说“我以为xx都早工作了”。

我全程背对着他们,那一刻我靠在椅子上,他们看不到我嘴角咧起的笑。我很喜欢看程序员生涯记录之类的小说,《疯狂的程序员》里面这样子写道“很多时候,我们开发一个项目,做一个需求,加班,熬夜,干耗,不是为了赶某个工期,或者是任务完成后领导给的拿一笔钱,更重要的是,我们享受这种克服万难,成人所不能的感觉,这种感觉跟钱是不一样的东西”。

正是这样子的瞬间,让我在程序的世界里真正的发现了自己。

故事直到这里,好像都跟微软没什么关系,可能有些朋友很想看如何去微软的过程,但是我个人觉得此处实在是乏善可陈,同时这个事情本身也没那么重要了。

一月下旬我从北京回湖北过年,没几天就遇到了疫情,在老家被辗转着隔离,家里也有亲人感染,可以说整个二月都是在隔离中度过。心里的压力更多来自对亲人健康的关心,到了二月中旬,情况渐渐好转,基本处于康复期了,恰逢学校群里有人发布微软春季实习生招聘,我就发了简历。

二月下旬开始,我在隔离的地方用手机开着热点,抱着公司的ThinkPad开展了新一轮的征程。

实习期间大量的开发任务确实很难抽出时间做这种集中式的复习,这次刷题我的目标很明确,牛客上的剑指Offer和LeetCode148一题不漏全部写完。

其实之前已经实现了大概80%,但是剩下的20%无疑是更加麻烦的,中间穿插着各种DP的训练,还是老规矩,AC才算过。刷累的时候会去整理在爱奇艺和百度的项目,它们的需求点,难点和结果。

这中间还有天在群里吹水,跟人吵起来AVL和红黑树哪个更难,我为了证明红黑树更难还专门花了半天去实现了一个可用的AVL。

写的时候我内心已经是很平静了,记得大学刚学树的时候,我觉得这种代码只能靠背,而且还背不下来。

到现在,这种东西只是去看一遍它的思路,然后在心中大概的复现一次,遇到有问题的点就停下来详细想想。一个数据结构无非ADT和对应的增删改查,然后再想想哪块的代码可以复用,抽离出来。

接下来就是各种边界和小case,头一天晚上我看到两点钟,把全部的思路复现了一遍。第二天起来吃完隔离点送过来的早饭就开始写,直接在记事本里面开始进行实现,然后微调了下,过我自己的case,没啥磕绊就完成了。

后面的微软面试一共做了五个题,最后一面的leader说我对边界条件的分析很到位,是她今天面试的所有人里面最全面最准确的,我当她给了个好消息吧。

同年的四月,我在师弟的帮助下,再次进行了字节跳动的面试,一下午三面过关斩将,也在不久之后收到了字节跳动的意向书。

![](https://tva1.sinaimg.cn/large/007S8ZIlly1gjv21j04xnj315s0kuard.jpg)


坦白来说,这个时期的我心中已经没有了什么波澜,不会特别高兴,也不会再对哪家公司产生特别的展开追逐的那种意愿。一来我已经呆过好几个公司了,那种大公司的憧憬和新鲜感对我而言已经没有那么大的吸引力,同时我也开始认为,一个程序员,他的目光不应该全部放在对哪家公司的追求上。

第一,我们服务于我们具体的业务和相应的技术,具体的业务是比公司这种平台性的东西更加值得讨论的。

第二,追求公司的本质是希望自我的提升,在这种前提下更应该把精力放在如何精进自己的技术水平上,因为公司本身并不能成为一个努力的方向和路线,它只是一个结果。

最后,又是一年的国庆,还是坐在电脑前。闭上眼睛,一路的回忆像浮光搬掠过眼前。

我喜欢看别人故事的原因是,几千个字的篇幅其实写尽了这个人很长的一段经历,浮浮沉沉,故事中的低潮可能在几行文字中就轻描淡写的过去了,读者喜欢去看走出这个低潮再见阳光的感动,其实对这个人来说,这一段恰恰是最难熬最难经历的一段。

我们看着故事中的人,好像自己也会离开这样的谷底。真实的说,这个故事中应该花大篇幅描述的难过我都略去了。

许多面试时候被否定的环节,被问到哑口无言的时刻,丹棱街SOHO微软大楼明灭的红光,冬天寒冷的西北旺东路到万泉河路海淀中街,爱奇艺十点半下班回去还在床上抱着电脑看一两个小时博客的那种追逐,西二旗人头多过Integer.MAX_VALUE的地铁站,一道题一个Bug困整整一个下午的纠结,二月新冠疫情落在家庭的恐慌,隔离时期对于家人的担心,老家甚至没有Wifi的手机热点面试,包括出来实习需要顶住的学业压力。

我把这个故事记录下来,是因为我喜欢《疯狂的程序员》里面的绝影,Boss绝,我想成为他那样的程序员,一个执着于代码,纯粹于代码的程序员。

本科期间我有些想做的事情未能完成,大三的时候武汉一个比中兴还低的本地的国企IT公司我都觉得很不错了,而时至今日我已经去过好几家大型互联网公司实习,拿遍了头部互联网的Offer,亦或者去到微软。

这些东西其实我在那时候并没想过,但是我也更加没想过绝对到不了今天。在晚归的中关村大街上,我经常会想到一首歌《奉献》,这是电影[飞驰人生]的主题曲。长路奉献给远方,岁月奉献给季节,我拿什么奉献给你。我们经常提起奉献,却很少真正理解奉献的样子。

对啊,到这一步,做到纯粹,更多的是热爱带来的奉献,我不是要执着于哪个Boss,或者执着于哪个公司,我是执着于我所热爱的程序,我所热爱的行业。

因为热爱,所以我不计回报,所以我做到比自己更多一点,因为喜欢,所以回忆里更多的是那些奉献与努力的时刻。

再回望去年随便收拾了两件衣服就踏上北京的自己,有些面试官听到我这个经历的时候会先大笑一下,然后说这样子是否有些冒进。也有些面试官因为这个性格将我挂掉,但是我已经过了那种因为别人评价感到疑问的阶段。如果再给我一次机会选择,或者说再给我一百次机会选择,在爱奇艺的那个电话里给的回复也还会是YES。

因为年轻,就是有无限的可能,青春就是不设限的。

阿里的招聘页面上有句话:If not now, when? If not me, who? 官方给出的翻译是“此时此刻,非我莫属”,我觉得差点意思。

时不我待,舍我其谁。

2020年10月3日于西安

写在最后

故事结束了,但是属于这个少年的未来才刚刚开始。

其实这个故事结尾最好的并不是他收到了多少offer,而是他终于找到了这份工作对于他的意义,找到了自已真正热爱的事业。单从这一点来说,他就已经成功了。

而当他拿到那些曾经遥不可及的大厂offer之后再回首,那些在暗淡时的迷茫困顿却不屈不挠用力生长的经历,每一秒都熠熠生辉。

我是敖丙,你知道的越多,你不知道的越多,我们下期见。

查看原文

赞 19 收藏 8 评论 2

敖丙 发布了文章 · 10月14日

打工四年总结的数据库知识点

国庆在家无聊,我随手翻了一下家里数据库相关的书籍,这一翻我就看上瘾了,因为大学比较熟悉的一些数据库范式我居然都忘了,怀揣着好奇心我就看了一个小国庆。

看的过程中我也做了一些小笔记,可能没我之前系统文章那么有趣,但是绝对也是干货十足,适合大家去回顾或者面试突击的适合看看,也不多说先放图。

存储引擎

InnoDB

InnoDB 是 MySQL 默认的事务型存储引擎,只要在需要它不支持的特性时,才考虑使用其他存储引擎。

InnoDB 采用 MVCC 来支持高并发,并且实现了四个标准隔离级别(未提交读、提交读、可重复读、可串行化)。其默认级别时可重复读(REPEATABLE READ),在可重复读级别下,通过 MVCC + Next-Key Locking 防止幻读。

主索引时聚簇索引,在索引中保存了数据,从而避免直接读取磁盘,因此对主键查询有很高的性能。

InnoDB 内部做了很多优化,包括从磁盘读取数据时采用的可预测性读,能够自动在内存中创建 hash 索引以加速读操作的自适应哈希索引,以及能够加速插入操作的插入缓冲区等。

InnoDB 支持真正的在线热备份,MySQL 其他的存储引擎不支持在线热备份,要获取一致性视图需要停止对所有表的写入,而在读写混合的场景中,停止写入可能也意味着停止读取。

MyISAM

设计简单,数据以紧密格式存储。对于只读数据,或者表比较小、可以容忍修复操作,则依然可以使用它。

提供了大量的特性,包括压缩表、空间数据索引等。

不支持事务。

不支持行级锁,只能对整张表加锁,读取时会对需要读到的所有表加共享锁,写入时则对表加排它锁。但在表有读取操作的同时,也可以往表中插入新的记录,这被称为并发插入(CONCURRENT INSERT)。

可以手工或者自动执行检查和修复操作,但是和事务恢复以及崩溃恢复不同,可能导致一些数据丢失,而且修复操作是非常慢的。

如果指定了 DELAY_KEY_WRITE 选项,在每次修改执行完成时,不会立即将修改的索引数据写入磁盘,而是会写到内存中的键缓冲区,只有在清理键缓冲区或者关闭表的时候才会将对应的索引块写入磁盘。这种方式可以极大的提升写入性能,但是在数据库或者主机崩溃时会造成索引损坏,需要执行修复操作。

InnoDB 和 MyISAM 的比较

  • 事务:InnoDB 是事务型的,可以使用 Commit 和 Rollback 语句。
  • 并发:MyISAM 只支持表级锁,而 InnoDB 还支持行级锁。
  • 外键:InnoDB 支持外键。
  • 备份:InnoDB 支持在线热备份。
  • 崩溃恢复:MyISAM 崩溃后发生损坏的概率比 InnoDB 高很多,而且恢复的速度也更慢。
  • 其它特性:MyISAM 支持压缩表和空间数据索引。

索引

B+ Tree 原理

数据结构

B Tree 指的是 Balance Tree,也就是平衡树,平衡树是一颗查找树,并且所有叶子节点位于同一层。

B+ Tree 是 B 树的一种变形,它是基于 B Tree 和叶子节点顺序访问指针进行实现,通常用于数据库和操作系统的文件系统中。

B+ 树有两种类型的节点:内部节点(也称索引节点)和叶子节点,内部节点就是非叶子节点,内部节点不存储数据,只存储索引,数据都存在叶子节点。

内部节点中的 key 都按照从小到大的顺序排列,对于内部节点中的一个 key,左子树中的所有 key 都小于它,右子树中的 key 都大于等于它,叶子节点的记录也是按照从小到大排列的。

每个叶子节点都存有相邻叶子节点的指针。

操作

查找

查找以典型的方式进行,类似于二叉查找树。起始于根节点,自顶向下遍历树,选择其分离值在要查找值的任意一边的子指针。在节点内部典型的使用是二分查找来确定这个位置。

插入

  • Perform a search to determine what bucket the new record should go into.
  • If the bucket is not full(a most b - 1 entries after the insertion,b 是节点中的元素个数,一般是页的整数倍),add tht record.
  • Otherwise,before inserting the new record

    • split the bucket.

      • original node has 「(L+1)/2」items
      • new node has 「(L+1)/2」items
    • Move 「(L+1)/2」-th key to the parent,and insert the new node to the parent.
    • Repeat until a parent is found that need not split.
  • If the root splits,treat it as if it has an empty parent ans split as outline above.

B-trees grow as the root and not at the leaves.

删除

和插入类似,只不过是自下而上的合并操作。

树的常见特性

AVL 树

平衡二叉树,一般是用平衡因子差值决定并通过旋转来实现,左右子树树高差不超过1,那么和红黑树比较它是严格的平衡二叉树,平衡条件非常严格(树高差只有1),只要插入或删除不满足上面的条件就要通过旋转来保持平衡。由于旋转是非常耗费时间的。所以 AVL 树适用于插入/删除次数比较少,但查找多的场景。

红黑树

通过对从根节点到叶子节点路径上各个节点的颜色进行约束,确保没有一条路径会比其他路径长2倍,因而是近似平衡的。所以相对于严格要求平衡的AVL树来说,它的旋转保持平衡次数较少。适合,查找少,插入/删除次数多的场景。(现在部分场景使用跳表来替换红黑树,可搜索“为啥 redis 使用跳表(skiplist)而不是使用 red-black?”)

B/B+ 树

多路查找树,出度高,磁盘IO低,一般用于数据库系统中。

B + 树与红黑树的比较

红黑树等平衡树也可以用来实现索引,但是文件系统及数据库系统普遍采用 B+ Tree 作为索引结构,主要有以下两个原因:

(一)磁盘 IO 次数

B+ 树一个节点可以存储多个元素,相对于红黑树的树高更低,磁盘 IO 次数更少。

(二)磁盘预读特性

为了减少磁盘 I/O 操作,磁盘往往不是严格按需读取,而是每次都会预读。预读过程中,磁盘进行顺序读取,顺序读取不需要进行磁盘寻道。每次会读取页的整数倍。

操作系统一般将内存和磁盘分割成固定大小的块,每一块称为一页,内存与磁盘以页为单位交换数据。数据库系统将索引的一个节点的大小设置为页的大小,使得一次 I/O 就能完全载入一个节点。

B + 树与 B 树的比较

B+ 树的磁盘 IO 更低

B+ 树的内部节点并没有指向关键字具体信息的指针。因此其内部节点相对 B 树更小。如果把所有同一内部结点的关键字存放在同一盘块中,那么盘块所能容纳的关键字数量也越多。一次性读入内存中的需要查找的关键字也就越多。相对来说IO读写次数也就降低了。

B+ 树的查询效率更加稳定

由于非叶子结点并不是最终指向文件内容的结点,而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同,导致每一个数据的查询效率相当。

B+ 树元素遍历效率高

B 树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题,B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的,而 B 树不支持这样的操作(或者说效率太低)。

MySQL 索引

索引是在存储引擎层实现的,而不是在服务器层实现的,所以不同存储引擎具有不同的索引类型和实现。

B+ Tree 索引

是大多数 MySQL 存储引擎的默认索引类型。

  • 因为不再需要进行全表扫描,只需要对树进行搜索即可,所以查找速度快很多。
  • 因为 B+ Tree 的有序性,所以除了用于查找,还可以用于排序和分组。
  • 可以指定多个列作为索引列,多个索引列共同组成键。
  • 适用于全键值、键值范围和键前缀查找,其中键前缀查找只适用于最左前缀查找。如果不是按照索引列的顺序进行查找,则无法使用索引。

InnoDB 的 B+Tree 索引分为主索引和辅助索引。主索引的叶子节点 data 域记录着完整的数据记录,这种索引方式被称为聚簇索引。因为无法把数据行存放在两个不同的地方,所以一个表只能有一个聚簇索引。

辅助索引的叶子节点的 data 域记录着主键的值,因此在使用辅助索引进行查找时,需要先查找到主键值,然后再到主索引中进行查找,这个过程也被称作回表。

哈希索引

哈希索引能以 O(1) 时间进行查找,但是失去了有序性:

  • 无法用于排序与分组;
  • 只支持精确查找,无法用于部分查找和范围查找。

InnoDB 存储引擎有一个特殊的功能叫“自适应哈希索引”,当某个索引值被使用的非常频繁时,会在 B+Tree 索引之上再创建一个哈希索引,这样就让 B+Tree 索引具有哈希索引的一些优点,比如快速的哈希查找。

全文索引

MyISAM 存储引擎支持全文索引,用于查找文本中的关键词,而不是直接比较是否相等。

查找条件使用 MATCH AGAINST,而不是普通的 WHERE。

全文索引使用倒排索引实现,它记录着关键词到其所在文档的映射。

InnoDB 存储引擎在 MySQL 5.6.4 版本中也开始支持全文索引。

空间数据索引

MyISAM 存储引擎支持空间数据索引(R-Tree),可以用于地理数据存储。空间数据索引会从所有维度来索引数据,可以有效地使用任意维度来进行组合查询。

必须使用 GIS 相关的函数来维护数据。

索引优化

独立的列

在进行查询时,索引列不能是表达式的一部分,也不能是函数的参数,否则无法使用索引。

例如下面的查询不能使用 actor_id 列的索引:

SELECT actor_id FROM sakila.actor WHERE actor_id + 1 = 5;

多列索引

在需要使用多个列作为条件进行查询时,使用多列索引比使用多个单列索引性能更好。例如下面的语句中,最好把 actor_id 和 film_id 设置为多列索引。

SELECT film_id, actor_ id FROM sakila.film_actor
WHERE actor_id = 1 AND film_id = 1;

索引列的顺序

让选择性最强的索引列放在前面。

索引的选择性是指:不重复的索引值和记录总数的比值。最大值为 1,此时每个记录都有唯一的索引与其对应。选择性越高,每个记录的区分度越高,查询效率也越高。

例如下面显示的结果中 customer_id 的选择性比 staff_id 更高,因此最好把 customer_id 列放在多列索引的前面。

SELECT COUNT(DISTINCT staff_id)/COUNT(*) AS staff_id_selectivity,
COUNT(DISTINCT customer_id)/COUNT(*) AS customer_id_selectivity,
COUNT(*)
FROM payment;
   staff_id_selectivity: 0.0001
customer_id_selectivity: 0.0373
               COUNT(*): 16049

前缀索引

对于 BLOB、TEXT 和 VARCHAR 类型的列,必须使用前缀索引,只索引开始的部分字符。

前缀长度的选取需要根据索引选择性来确定。

覆盖索引

索引包含所有需要查询的字段的值。

具有以下优点:

  • 索引通常远小于数据行的大小,只读取索引能大大减少数据访问量。
  • 一些存储引擎(例如 MyISAM)在内存中只缓存索引,而数据依赖于操作系统来缓存。因此,只访问索引可以不使用系统调用(通常比较费时)。
  • 对于 InnoDB 引擎,若辅助索引能够覆盖查询,则无需访问主索引。

索引的优点

  • 大大减少了服务器需要扫描的数据行数。
  • 帮助服务器避免进行排序和分组,以及避免创建临时表(B+Tree 索引是有序的,可以用于 ORDER BY 和 GROUP BY 操作。临时表主要是在排序和分组过程中创建,不需要排序和分组,也就不需要创建临时表)。
  • 将随机 I/O 变为顺序 I/O(B+Tree 索引是有序的,会将相邻的数据都存储在一起)。

索引的使用条件

  • 对于非常小的表、大部分情况下简单的全表扫描比建立索引更高效;
  • 对于中到大型的表,索引就非常有效;
  • 但是对于特大型的表,建立和维护索引的代价将会随之增长。这种情况下,需要用到一种技术可以直接区分出需要查询的一组数据,而不是一条记录一条记录地匹配,例如可以使用分区技术。
为什么对于非常小的表,大部分情况下简单的全表扫描比建立索引更高效?

如果一个表比较小,那么显然直接遍历表比走索引要快(因为需要回表)。

注:首先,要注意这个答案隐含的条件是查询的数据不是索引的构成部分,否也不需要回表操作。其次,查询条件也不是主键,否则可以直接从聚簇索引中拿到数据。

查询性能优化

使用 explain 分析 select 查询语句

explain 用来分析 SELECT 查询语句,开发人员可以通过分析 Explain 结果来优化查询语句。

select_type

常用的有 SIMPLE 简单查询,UNION 联合查询,SUBQUERY 子查询等。

table

要查询的表

possible_keys

The possible indexes to choose

可选择的索引

key

The index actually chosen

实际使用的索引

rows

Estimate of rows to be examined

扫描的行数

type

索引查询类型,经常用到的索引查询类型:

**const:使用主键或者唯一索引进行查询的时候只有一行匹配
ref:使用非唯一索引
range:使用主键、单个字段的辅助索引、多个字段的辅助索引的最后一个字段进行范围查询
index:和all的区别是扫描的是索引树
all:扫描全表:**

system

触发条件:表只有一行,这是一个 const type 的特殊情况

const

触发条件:在使用主键或者唯一索引进行查询的时候只有一行匹配。

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name
  WHERE primary_key_part1=1 AND primary_key_part2=2;

eq_ref

触发条件:在进行联接查询的,使用主键或者唯一索引并且只匹配到一行记录的时候

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

ref

触发条件:使用非唯一索引

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

range

触发条件:只有在使用主键、单个字段的辅助索引、多个字段的辅助索引的最后一个字段进行范围查询才是 range

SELECT * FROM tbl_name
  WHERE key_column = 10;

SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name
  WHERE key_part1 = 10 AND key_part2 IN (10,20,30);

index

The index join type is the same as ALL, except that the index tree is scanned. This occurs two ways:

触发条件:

只扫描索引树

1)查询的字段是索引的一部分,覆盖索引。
2)使用主键进行排序

all

触发条件:全表扫描,不走索引

优化数据访问

减少请求的数据量

  • 只返回必要的列:最好不要使用 SELECT * 语句。
  • 只返回必要的行:使用 LIMIT 语句来限制返回的数据。
  • 缓存重复查询的数据:使用缓存可以避免在数据库中进行查询,特别在要查询的数据经常被重复查询时,缓存带来的查询性能提升将会是非常明显的。

减少服务器端扫描的行数

最有效的方式是使用索引来覆盖查询。

重构查询方式

切分大查询

一个大查询如果一次性执行的话,可能一次锁住很多数据、占满整个事务日志、耗尽系统资源、阻塞很多小的但重要的查询。

DELETE FROM messages WHERE create < DATE_SUB(NOW(), INTERVAL 3 MONTH);
rows_affected = 0
do {
    rows_affected = do_query(
    "DELETE FROM messages WHERE create  < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 10000")
} while rows_affected > 0

分解大连接查询

将一个大连接查询分解成对每一个表进行一次单表查询,然后在应用程序中进行关联,这样做的好处有:

  • 让缓存更高效。对于连接查询,如果其中一个表发生变化,那么整个查询缓存就无法使用。而分解后的多个查询,即使其中一个表发生变化,对其它表的查询缓存依然可以使用。
  • 分解成多个单表查询,这些单表查询的缓存结果更可能被其它查询使用到,从而减少冗余记录的查询。
  • 减少锁竞争;
  • 在应用层进行连接,可以更容易对数据库进行拆分,从而更容易做到高性能和可伸缩。
  • 查询本身效率也可能会有所提升。例如下面的例子中,使用 IN() 代替连接查询,可以让 MySQL 按照 ID 顺序进行查询,这可能比随机的连接要更高效。
SELECT * FROM tag
JOIN tag_post ON tag_post.tag_id=tag.id
JOIN post ON tag_post.post_id=post.id
WHERE tag.tag='mysql';
SELECT * FROM tag WHERE tag='mysql';
SELECT * FROM tag_post WHERE tag_id=1234;
SELECT * FROM post WHERE post.id IN (123,456,567,9098,8904);

事务

事务是指满足 ACID 特性的一组操作,可以通过 Commit 提交一个事务,也可以使用 Rollback 进行回滚。

ACID

事务最基本的莫过于 ACID 四个特性了,这四个特性分别是:

  • Atomicity:原子性
  • Consistency:一致性
  • Isolation:隔离性
  • Durability:持久性

原子性

事务被视为不可分割的最小单元,事务的所有操作要么全部成功,要么全部失败回滚。

一致性

数据库在事务执行前后都保持一致性状态,在一致性状态下,所有事务对一个数据的读取结果都是相同的。

隔离性

一个事务所做的修改在最终提交以前,对其他事务是不可见的。

持久性

一旦事务提交,则其所做的修改将会永远保存到数据库中。即使系统发生崩溃,事务执行的结果也不能丢。

ACID 之间的关系

事务的 ACID 特性概念很简单,但不好理解,主要是因为这几个特性不是一种平级关系:

  • 只有满足一致性,事务的结果才是正确的。
  • 在无并发的情况下,事务串行执行,隔离性一定能够满足。此时只要能满足原子性,就一定能满足一致性。在并发的情况下,多个事务并行执行,事务不仅要满足原子性,还需要满足隔离性,才能满足一致性。
  • 事务满足持久化是为了能应对数据库崩溃的情况。

隔离级别

未提交读(READ UNCOMMITTED)

事务中的修改,即使没有提交,对其他事务也是可见的。

提交读(READ COMMITTED)

一个事务只能读取已经提交的事务所做的修改。换句话说,一个事务所做的修改在提交之前对其他事务是不可见的。

可重复读(REPEATABLE READ)

保证在同一个事务中多次读取同样数据的结果是一样的。

可串行化(SERIALIZABLE)

强制事务串行执行。

需要加锁实现,而其它隔离级别通常不需要。

隔离级别脏读不可重复读幻影读
未提交读
提交读×
可重复读××
可串行化×××

锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的并发访问。

锁类型

共享锁(S Lock)

允许事务读一行数据

排他锁(X Lock)

允许事务删除或者更新一行数据

意向共享锁(IS Lock)

事务想要获得一张表中某几行的共享锁

意向排他锁

事务想要获得一张表中某几行的排他锁

MVCC

多版本并发控制(Multi-Version Concurrency Control, MVCC)是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式,用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行,无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁,单纯使用 MVCC 无法实现。

基础概念

版本号

  • 系统版本号:是一个递增的数字,每开始一个新的事务,系统版本号就会自动递增。
  • 事务版本号:事务开始时的系统版本号。

隐藏的列

MVCC 在每行记录后面都保存着两个隐藏的列,用来存储两个版本号:

  • 创建版本号:指示创建一个数据行的快照时的系统版本号;
  • 删除版本号:如果该快照的删除版本号大于当前事务版本号表示该快照有效,否则表示该快照已经被删除了。

Undo 日志

MVCC 使用到的快照存储在 Undo 日志中,该日志通过回滚指针把一个数据行(Record)的所有快照连接起来。

实现过程

以下实现过程针对可重复读隔离级别。

当开始一个事务时,该事务的版本号肯定大于当前所有数据行快照的创建版本号,理解这一点很关键。数据行快照的创建版本号是创建数据行快照时的系统版本号,系统版本号随着创建事务而递增,因此新创建一个事务时,这个事务的系统版本号比之前的系统版本号都大,也就是比所有数据行快照的创建版本号都大。

SELECT

多个事务必须读取到同一个数据行的快照,并且这个快照是距离现在最近的一个有效快照。但是也有例外,如果有一个事务正在修改该数据行,那么它可以读取事务本身所做的修改,而不用和其它事务的读取结果一致。

把没有对一个数据行做修改的事务称为 T,T 所要读取的数据行快照的创建版本号必须小于等于 T 的版本号,因为如果大于 T 的版本号,那么表示该数据行快照是其它事务的最新修改,因此不能去读取它。除此之外,T 所要读取的数据行快照的删除版本号必须是未定义或者大于 T 的版本号,因为如果小于等于 T 的版本号,那么表示该数据行快照是已经被删除的,不应该去读取它。

INSERT

将当前系统版本号作为数据行快照的创建版本号。

DELETE

将当前系统版本号作为数据行快照的删除版本号。

UPDATE

将当前系统版本号作为更新前的数据行快照的删除版本号,并将当前系统版本号作为更新后的数据行快照的创建版本号。可以理解为先执行 DELETE 后执行 INSERT。

快照读与当前读

在可重复读级别中,通过MVCC机制,虽然让数据变得可重复读,但我们读到的数据可能是历史数据,是不及时的数据,不是数据库当前的数据!这在一些对于数据的时效特别敏感的业务中,就很可能出问题。

对于这种读取历史数据的方式,我们叫它快照读 (snapshot read),而读取数据库当前版本数据的方式,叫当前读 (current read)。很显然,在MVCC中:

快照读

MVCC 的 SELECT 操作是快照中的数据,不需要进行加锁操作。

select * from table ….;

当前读

MVCC 其它会对数据库进行修改的操作(INSERT、UPDATE、DELETE)需要进行加锁操作,从而读取最新的数据。可以看到 MVCC 并不是完全不用加锁,而只是避免了 SELECT 的加锁操作。

INSERT;
UPDATE;
DELETE;

在进行 SELECT 操作时,可以强制指定进行加锁操作。以下第一个语句需要加 S 锁,第二个需要加 X 锁。

- select * from table where ? lock in share mode;
- select * from table where ? for update;

事务的隔离级别实际上都是定义的当前读的级别,MySQL为了减少锁处理(包括等待其它锁)的时间,提升并发能力,引入了快照读的概念,使得select不用加锁。而update、insert这些“当前读”的隔离性,就需要通过加锁来实现了。

锁算法

Record Lock

锁定一个记录上的索引,而不是记录本身。

如果表没有设置索引,InnoDB 会自动在主键上创建隐藏的聚簇索引,因此 Record Locks 依然可以使用。

Gap Lock

锁定索引之间的间隙,但是不包含索引本身。例如当一个事务执行以下语句,其它事务就不能在 t.c 中插入 15。

SELECT c FROM t WHERE c BETWEEN 10 and 20 FOR UPDATE;

Next-Key Lock

它是 Record Locks 和 Gap Locks 的结合,不仅锁定一个记录上的索引,也锁定索引之间的间隙。例如一个索引包含以下值:10, 11, 13, and 20,那么就需要锁定以下区间:

(-∞, 10]
(10, 11]
(11, 13]
(13, 20]
(20, +∞)
在 InnoDB 存储引擎中,SELECT 操作的不可重复读问题通过 MVCC 得到了解决,而 UPDATE、DELETE 的不可重复读问题通过 Record Lock 解决,INSERT 的不可重复读问题是通过 Next-Key Lock(Record Lock + Gap Lock)解决的。

锁问题

脏读

脏读指的是不同事务下,当前事务可以读取到另外事务未提交的数据。

例如:

T1 修改一个数据,T2 随后读取这个数据。如果 T1 撤销了这次修改,那么 T2 读取的数据是脏数据。

不可重复读

不可重复读指的是同一事务内多次读取同一数据集合,读取到的数据是不一样的情况。

例如:

T2 读取一个数据,T1 对该数据做了修改。如果 T2 再次读取这个数据,此时读取的结果和第一次读取的结果不同。

在 InnoDB 存储引擎中,SELECT 操作的不可重复读问题通过 MVCC 得到了解决,而 UPDATE、DELETE 的不可重复读问题是通过 Record Lock 解决的,INSERT 的不可重复读问题是通过 Next-Key Lock(Record Lock + Gap Lock)解决的。

Phantom Proble(幻影读)

The so-called phantom problem occurs within a transaction when the same query produces different sets of rows at different times. For example, if a SELECT is executed twice, but returns a row the second time that was not returned the first time, the row is a “phantom” row.

Phantom Proble 是指在同一事务下,连续执行两次同样的 sql 语句可能返回不同的结果,第二次的 sql 语句可能会返回之前不存在的行。

幻影读是一种特殊的不可重复读问题。

丢失更新

一个事务的更新操作会被另一个事务的更新操作所覆盖。

例如:

T1 和 T2 两个事务都对一个数据进行修改,T1 先修改,T2 随后修改,T2 的修改覆盖了 T1 的修改。

这类型问题可以通过给 SELECT 操作加上排他锁来解决,不过这可能会引入性能问题,具体使用要视业务场景而定。

分库分表数据切分

水平切分

水平切分又称为 Sharding,它是将同一个表中的记录拆分到多个结构相同的表中。

当一个表的数据不断增多时,Sharding 是必然的选择,它可以将数据分布到集群的不同节点上,从而缓存单个数据库的压力。

垂直切分

垂直切分是将一张表按列分成多个表,通常是按照列的关系密集程度进行切分,也可以利用垂直气氛将经常被使用的列喝不经常被使用的列切分到不同的表中。

在数据库的层面使用垂直切分将按数据库中表的密集程度部署到不通的库中,例如将原来电商数据部署库垂直切分称商品数据库、用户数据库等。

Sharding 策略

  • 哈希取模:hash(key)%N
  • 范围:可以是 ID 范围也可以是时间范围
  • 映射表:使用单独的一个数据库来存储映射关系

Sharding 存在的问题

事务问题

使用分布式事务来解决,比如 XA 接口

连接

可以将原来的连接分解成多个单表查询,然后在用户程序中进行连接。

唯一性

  • 使用全局唯一 ID (GUID)
  • 为每个分片指定一个 ID 范围
  • 分布式 ID 生成器(如 Twitter 的 Snowflake 算法)

复制

主从复制

主要涉及三个线程:binlog 线程、I/O 线程和 SQL 线程。

  • binlog 线程 :负责将主服务器上的数据更改写入二进制日志(Binary log)中。
  • I/O 线程 :负责从主服务器上读取- 二进制日志,并写入从服务器的中继日志(Relay log)。
  • SQL 线程 :负责读取中继日志,解析出主服务器已经执行的数据更改并在从服务器中重放(Replay)。

读写分离

主服务器处理写操作以及实时性要求比较高的读操作,而从服务器处理读操作。

读写分离能提高性能的原因在于:

  • 主从服务器负责各自的读和写,极大程度缓解了锁的争用;
  • 从服务器可以使用 MyISAM,提升查询性能以及节约系统开销;
  • 增加冗余,提高可用性。

读写分离常用代理方式来实现,代理服务器接收应用层传来的读写请求,然后决定转发到哪个服务器。

JSON

在实际业务中经常会使用到 JSON 数据类型,在查询过程中主要有两种使用需求:

  1. 在 where 条件中有通过 json 中的某个字段去过滤返回结果的需求
  2. 查询 json 字段中的部分字段作为返回结果(减少内存占用)

JSON_CONTAINS

JSON_CONTAINS(target, candidate[, path])

如果在 json 字段 target 指定的位置 path,找到了目标值 condidate,返回 1,否则返回 0

如果只是检查在指定的路径是否存在数据,使用JSON_CONTAINS_PATH()

mysql> SET @j = '{"a": 1, "b": 2, "c": {"d": 4}}';
mysql> SET @j2 = '1';
mysql> SELECT JSON_CONTAINS(@j, @j2, '$.a');
+-------------------------------+
| JSON_CONTAINS(@j, @j2, '$.a') |
+-------------------------------+
|                             1 |
+-------------------------------+
mysql> SELECT JSON_CONTAINS(@j, @j2, '$.b');
+-------------------------------+
| JSON_CONTAINS(@j, @j2, '$.b') |
+-------------------------------+
|                             0 |
+-------------------------------+

mysql> SET @j2 = '{"d": 4}';
mysql> SELECT JSON_CONTAINS(@j, @j2, '$.a');
+-------------------------------+
| JSON_CONTAINS(@j, @j2, '$.a') |
+-------------------------------+
|                             0 |
+-------------------------------+
mysql> SELECT JSON_CONTAINS(@j, @j2, '$.c');
+-------------------------------+
| JSON_CONTAINS(@j, @j2, '$.c') |
+-------------------------------+
|                             1 |
+-------------------------------+

JSON_CONTAINS_PATH

JSON_CONTAINS_PATH(json_doc, one_or_all, path[, path] ...)

如果在指定的路径存在数据返回 1,否则返回 0

mysql> SET @j = '{"a": 1, "b": 2, "c": {"d": 4}}';
mysql> SELECT JSON_CONTAINS_PATH(@j, 'one', '$.a', '$.e');
+---------------------------------------------+
| JSON_CONTAINS_PATH(@j, 'one', '$.a', '$.e') |
+---------------------------------------------+
|                                           1 |
+---------------------------------------------+
mysql> SELECT JSON_CONTAINS_PATH(@j, 'all', '$.a', '$.e');
+---------------------------------------------+
| JSON_CONTAINS_PATH(@j, 'all', '$.a', '$.e') |
+---------------------------------------------+
|                                           0 |
+---------------------------------------------+
mysql> SELECT JSON_CONTAINS_PATH(@j, 'one', '$.c.d');
+----------------------------------------+
| JSON_CONTAINS_PATH(@j, 'one', '$.c.d') |
+----------------------------------------+
|                                      1 |
+----------------------------------------+
mysql> SELECT JSON_CONTAINS_PATH(@j, 'one', '$.a.d');
+----------------------------------------+
| JSON_CONTAINS_PATH(@j, 'one', '$.a.d') |
+----------------------------------------+
|                                      0 |
+----------------------------------------+

实际使用:

        $conds = new Criteria();
        $conds->andWhere('dept_code', 'in', $deptCodes);
        if (!empty($aoiAreaId)) {
            $aoiAreaIdCond = new Criteria();
            $aoiAreaIdCond->orWhere("JSON_CONTAINS_PATH(new_aoi_area_ids,'one', '$.\"$aoiAreaId\"')", '=', 1);
            $aoiAreaIdCond->orWhere("JSON_CONTAINS_PATH(old_aoi_area_ids,'one', '$.\"$aoiAreaId\"')", '=', 1);
            $conds->andWhere($aoiAreaIdCond);
        }

column->path、column->>path

获取指定路径的值

-> vs ->>

Whereas the -> operator simply extracts a value, the ->> operator in addition unquotes the extracted result.

mysql> SELECT * FROM jemp WHERE g > 2;
+-------------------------------+------+
| c                             | g    |
+-------------------------------+------+
| {"id": "3", "name": "Barney"} |    3 |
| {"id": "4", "name": "Betty"}  |    4 |
+-------------------------------+------+
2 rows in set (0.01 sec)

mysql> SELECT c->'$.name' AS name
    ->     FROM jemp WHERE g > 2;
+----------+
| name     |
+----------+
| "Barney" |
| "Betty"  |
+----------+
2 rows in set (0.00 sec)

mysql> SELECT JSON_UNQUOTE(c->'$.name') AS name
    ->     FROM jemp WHERE g > 2;
+--------+
| name   |
+--------+
| Barney |
| Betty  |
+--------+
2 rows in set (0.00 sec)

mysql> SELECT c->>'$.name' AS name
    ->     FROM jemp WHERE g > 2;
+--------+
| name   |
+--------+
| Barney |
| Betty  |
+--------+
2 rows in set (0.00 sec)

实际使用:

$retTask = AoiAreaTaskOrm::findRows(['status', 'extra_info->>"$.new_aoi_area_infos" as new_aoi_area_infos', 'extra_info->>"$.old_aoi_area_infos" as old_aoi_area_infos'], $cond);

关系数据库设计理论

函数依赖

记 A->B 表示 A 函数决定 B,也可以说 B 函数依赖于 A。

如果 {A1,A2,... ,An} 是关系的一个或多个属性的集合,该集合函数决定了关系的其它所有属性并且是最小的,那么该集合就称为键码。

对于 A->B,如果能找到 A 的真子集 A',使得 A'-> B,那么 A->B 就是部分函数依赖,否则就是完全函数依赖。

对于 A->B,B->C,则 A->C 是一个传递函数依赖

异常

以下的学生课程关系的函数依赖为 {Sno, Cname} -> {Sname, Sdept, Mname, Grade},键码为 {Sno, Cname}。也就是说,确定学生和课程之后,就能确定其它信息。

SnoSnameSdeptMnameCnameGrade
1学生-1学院-1院长-1课程-190
2学生-2学院-2院长-2课程-280
2学生-2学院-2院长-2课程-1100
3学生-3学院-2院长-2课程-295

不符合范式的关系,会产生很多异常,主要有以下四种异常:

  • 冗余数据:例如 学生-2 出现了两次。
  • 修改异常:修改了一个记录中的信息,但是另一个记录中相同的信息却没有被修改。
  • 删除异常:删除一个信息,那么也会丢失其它信息。例如删除了 课程-1 需要删除第一行和第三行,那么 学生-1 的信息就会丢失。
  • 插入异常:例如想要插入一个学生的信息,如果这个学生还没选课,那么就无法插入。

范式

范式理论是为了解决以上提到四种异常。

高级别范式的依赖于低级别的范式,1NF 是最低级别的范式。

第一范式 (1NF)

属性不可分。

第二范式 (2NF)

每个非主属性完全函数依赖于键码。

可以通过分解来满足。

分解前

SnoSnameSdeptMnameCnameGrade
1学生-1学院-1院长-1课程-190
2学生-2学院-2院长-2课程-280
2学生-2学院-2院长-2课程-1100
3学生-3学院-2院长-2课程-295

以上学生课程关系中,{Sno, Cname} 为键码,有如下函数依赖:

  • Sno -> Sname, Sdept
  • Sdept -> Mname
  • Sno, Cname-> Grade

Grade 完全函数依赖于键码,它没有任何冗余数据,每个学生的每门课都有特定的成绩。

Sname, Sdept 和 Mname 都部分依赖于键码,当一个学生选修了多门课时,这些数据就会出现多次,造成大量冗余数据。

分解后

关系-1

SnoSnameSdeptMname
1学生-1学院-1院长-1
2学生-2学院-2院长-2
3学生-3学院-2院长-2

有以下函数依赖:

  • Sno -> Sname, Sdept
  • Sdept -> Mname

关系-2

SnoCnameGrade
1课程-190
2课程-280
2课程-1100
3课程-295

有以下函数依赖:

  • Sno, Cname -> Grade

第三范式 (3NF)

非主属性不传递函数依赖于键码。

上面的 关系-1 中存在以下传递函数依赖:

  • Sno -> Sdept -> Mname

可以进行以下分解:

关系-11

SnoSnameSdept
1学生-1学院-1
2学生-2学院-2
3学生-3学院-2

关系-12

SdeptMname
学院-1院长-1
学院-2院长-2

ER 图

Entity-Relationship,有三个组成部分:实体、属性、联系。

用来进行关系型数据库系统的概念设计。

实体的三种联系

包含一对一,一对多,多对多三种。

  • 如果 A 到 B 是一对多关系,那么画个带箭头的线段指向 B;
  • 如果是一对一,画两个带箭头的线段;
  • 如果是多对多,画两个不带箭头的线段。

下图的 Course 和 Student 是一对多的关系。

表示出现多次的关系

一个实体在联系出现几次,就要用几条线连接。

下图表示一个课程的先修关系,先修关系出现两个 Course 实体,第一个是先修课程,后一个是后修课程,因此需要用两条线来表示这种关系。

联系的多向性

虽然老师可以开设多门课,并且可以教授多名学生,但是对于特定的学生和课程,只有一个老师教授,这就构成了一个三元联系。

表示子类

用一个三角形和两条线来连接类和子类,与子类有关的属性和联系都连到子类上,而与父类和子类都有关的连到父类上。

参考资料

总结

这都是些基础知识,我没想到再次回顾大半我都已忘却了,也庆幸有这样的假期能够重新拾起来。

说实话做自媒体后我充电的时间少了很多,也少了很多时间研究技术栈深度,国庆假期我也思考反思了很久,后面准备继续压缩自己业余时间,比如看手机看B站的时间压缩一下,还是得按时充电,目前作息还算规律早睡早起都做到了,我们一起加油哟。

我是敖丙,你知道的越多,你不知道的越多,感谢各位人才的:点赞收藏评论,我们下期见!

查看原文

赞 48 收藏 35 评论 2

敖丙 发布了文章 · 10月12日

Dubbo常见面试题

前言

Dubbo 整体介绍的差不多了,今天就开始面试环节了,我会列举一些常见的 Dubbo 面试题,只会抓着重的,一些太简单的我就不提了。

不仅仅给你面试题的答案,也会剖析面试官问这个问题的原因,也就是他的内心活动。

想从你这里问出什么?想要什么答案?想挖什么坑给你跳?

开始表演

知道什么是 RPC 么?

一般面试官会以这样的问题来切入、热场,毕面试也是循序渐进的过程,所以你也不用太心急一开始就芭芭拉说一堆,要抓住关键点简单阐述先。

而且面试官能从这个问题鉴定出你平日的工作内容会不会连 RPC 都没接触过,会不会就只是一条龙的 Spring MVC ?

确实有很多同学没接触过 RPC ,也很正常比如一些外包或者一些小项目都接触不到的,不过平日接触不到和你不知道这个东西是两个概念。

能从侧面反映出这个人工作之余应该不怎么学习,连 RPC 都不知道,所以怎么都说不过去,基本上要凉凉,对你的初始印象就差了,除非你能从后面有亮眼的表现。

答:RPC 就是 Remote Procedure Call,远程过程调用,它相对应的是本地过程调用。

那为什么要有 RPC,HTTP 不好么?

这时候面试官就开始追问了。

这个问题其实很有意思,有些面试官可能自己不太清楚,然后以为自己很清楚,所以问出这个问题,还有一种是真的清楚,问这个问题是为了让你跳坑里。

因为 RPC 和 HTTP 就不是一个层级的东西,所以严格意义上这两个没有可比性,也不应该来作比较,而题目问的就是把这两个作为比较了。

HTTP 只是传输协议,协议只是规范了一定的交流格式,而且 RPC 是早于 HTTP 的,所以真要问也是问有 RPC 为什么还要 HTTP。

RPC 对比的是本地过程调用,是用来作为分布式系统之间的通信,它可以用 HTTP 来传输,也可以基于 TCP 自定义协议传输。

所以你要先提出这两个不是一个层级的东西,没有可比性,然后再表现一下,可以说 HTTP 协议比较冗余,所以 RPC 大多都是基于 TCP 自定义协议,定制化的才是最适合自己的。

当然也有基于 HTTP 协议的 RPC 框架,毕竟 HTTP 是公开的协议,比较通用,像 HTTP2 已经做了相应的压缩了,而且系统之间的调用都在内网,所以说影响也不会很大。

这波回答下来,面试官会觉得你有点东西,开始对你有点兴趣了,要开始深入你了。

说说你对 Dubbo 的了解?

面试官会先问个大点的问题,然后从你的回答中找到一些突破口来深入问,所以这个问题其实挺开放性的,你可以从历史的发展来答,也可以从整体架构来答。

如果从历史发展的角度来答,说明你平日里也是挺关注一些开源软件的,侧面也能体现你的对开源的拥抱。

如果从总体架构答,毋庸置疑肯定也是可以的,建议先浅显的说,等着追问。

历史发展,这个其实丙之前文章已经提到了:

Dubbo 是阿里巴巴开源的一个基于 Java 的 RPC 框架,中间沉寂了一段时间,但在 2017 年阿里巴巴又重启了对 Dubbo 维护。

并且在 2018 年和 当当的 Dubbox 进行了合并,进入 Apache 孵化器,在 2019 年毕业正式成为 Apache 顶级项目。

目前 Dubbo 社区主力维护的是 2.6.x 和 2.7.x 两大版本,2.6.x 版本主要是 bug 修复和少量功能增强为准,是稳定版本。

2.7.5 版本的发布被 Dubbo 认为是里程碑式的版本发布,支持 gRPC,并且性能提升了 30%(这里不了解gRPC 和为什么性能提升的话就别说了,别给自己挖坑)。

最新的 3.0 版本往云原生方向上探索着。

注意了,如果对历史各个版本不太熟,也不知道最新的版本要干啥就别往这方向答了,运气好点就是面试官自己也不太了解,他可能不会问,运气背点就追问了。

总体架构,上面也提到了先浅显的说,等追问,因为面试官如果懂,他肯定会问深入,如果不懂你芭芭拉一堆他无感的。

你就简单的提一下现在这几个角色。

节点角色说明
Consumer需要调用远程服务的服务消费方
Registry注册中心
Provider服务提供方
Container服务运行的容器
Monitor监控中心

比如, Dubbo 总体分了以上这么几个角色,分别的作用是xxxx。

这里停顿下看下面试官的反应,如果没搭话,就继续说大致的流程。

首先服务提供者 Provider 启动然后向注册中心注册自己所能提供的服务。

服务消费者 Consumer 启动向注册中心订阅自己所需的服务。然后注册中心将提供者元信息通知给 Consumer, 之后 Consumer 因为已经从注册中心获取提供者的地址,因此可以通过负载均衡选择一个 Provider 直接调用 。

之后服务提供方元数据变更的话注册中心会把变更推送给服务消费者。

服务提供者和消费者都会在内存中记录着调用的次数和时间,然后定时的发送统计数据到监控中心。

到这基本上就差不多了,如果之前看过丙的 Dubbo 系列文章的话,那就算看过源码了,肯定对一系列过程很清晰了,所以在适当的时机可以说自己看过 Dubbo 源码。

众所周知,看过源码肯定是加分项,所以这点是要提的。

面试官一听,好家伙看过源码是吧,来说说。

接下来就开始连击了。

看过源码,那说下服务暴露的流程?

服务的暴露起始于 Spring IOC 容器刷新完毕之后,会根据配置参数组装成 URL, 然后根据 URL 的参数来进行本地或者远程调用。

会通过 proxyFactory.getInvoker,利用 javassist 来进行动态代理,封装真的实现类,然后再通过 URL 参数选择对应的协议来进行 protocol.export,默认是 Dubbo 协议。

在第一次暴露的时候会调用 createServer 来创建 Server,默认是 NettyServer。

然后将 export 得到的 exporter 存入一个 Map 中,供之后的远程调用查找,然后会向注册中心注册提供者的信息。

基本上就是这么个流程,说了这些差不多了,太细的谁都记住不。

看过源码,那说下服务引入的流程?

服务的引入时机有两种,第一种是饿汉式,第二种是懒汉式。

饿汉式就是加载完毕就会引入,懒汉式是只有当这个服务被注入到其他类中时启动引入流程,默认是懒汉式。

会先根据配置参数组装成 URL ,一般而言我们都会配置的注册中心,所以会构建 RegistryDirectory
向注册中心注册消费者的信息,并且订阅提供者、配置、路由等节点。

得知提供者的信息之后会进入 Dubbo 协议的引入,会创建 Invoker ,期间会包含 NettyClient,来进行远程通信,最后通过 Cluster 来包装 Invoker,默认是 FailoverCluster,最终返回代理类。

说这么多差不多了,关键的点都提到了。

切忌不要太过细,不要把你知道的都说了,这样会抓不住重点,比如上面的流程你要插入,引入的三种方式:本地引入、直连远程引入、通过注册中心引入。

然后再分别说本地引入怎样的,芭芭拉的就会很乱,所以面试的时候是需要删减的,要直击重点。

其实真实说的应该比我上面说的还要精简点才行,我是怕大家不太清楚说的稍微详细了一些。

看过源码,那说下服务调用的流程?

调用某个接口的方法会调用之前生成的代理类,然后会从 cluster 中经过路由的过滤、负载均衡机制选择一个 invoker 发起远程调用,此时会记录此请求和请求的 ID 等待服务端的响应。

服务端接受请求之后会通过参数找到之前暴露存储的 map,得到相应的 exporter ,然后最终调用真正的实现类,再组装好结果返回,这个响应会带上之前请求的 ID。

消费者收到这个响应之后会通过 ID 去找之前记录的请求,然后找到请求之后将响应塞到对应的 Future 中,唤醒等待的线程,最后消费者得到响应,一个流程完毕。

关键的就是 cluster、路由、负载均衡,然后 Dubbo 默认是异步的,所以请求和响应是如何对应上的。

之后可能还会追问 Dubbo 异步转同步如何实现的之类的,在丙之前文章里面都说了,忘记的同学可以回去看看。

知道什么是 SPI 嘛?

这又是一个方向了,从上面的回答中,不论是从 Dubbo 协议,还是 cluster ,什么 export 方法等等无处不是 SPI 的影子,所以如果是问 Dubbo 方面的问题,问 SPI 是毋庸置疑的,因为源码里 SPI 无处不在,而且 SPI 也是 Dubbo 可扩展性的基石。

所以这个题目没什么套路,直接答就行。

SPI 是 Service Provider Interface,主要用于框架中,框架定义好接口,不同的使用者有不同的需求,因此需要有不同的实现,而 SPI 就通过定义一个特定的位置,Java SPI 约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件,然后文件里面记录的是此 jar 包提供的具体实现类的全限定名

所以就可以通过接口找到对应的文件,获取具体的实现类然后加载即可,做到了灵活的替换具体的实现类。

为什么 Dubbo 不用 JDK 的 SPI,而是要自己实现?

问这个问题就是看你有没有深入的了解,或者自己思考过,不是死板的看源码,或者看一些知识点。

很多点是要思考的,不是书上说什么就是什么,你要知道这样做的理由,有什么好处和坏处,这很容易看出一个人是死记硬背还是有自己的思考。

答:因为 Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化,假设一个实现类初始化过程比较消耗资源且耗时,但是你的代码里面又用不上它,这就产生了资源的浪费。

因此 Dubbo 就自己实现了一个 SPI,给每个实现类配了个名字,通过名字去文件里面找到对应的实现类全限定名然后加载实例化,按需加载。

这答出来就加分了,面试官心里在拍手了,不错不错有点东西。

Dubbo 为什么默认用 Javassist

上面你回答 Dubbo 用 Javassist 动态代理,所以很可能会问你为什么要用这个代理,可能还会引申出 JDK 的动态代理、ASM、CGLIB。

所以这也是个注意点,如果你不太清楚的话上面的回答就不要扯到动态代理了,如果清楚的话那肯定得提,来诱导面试官来问你动态代理方面的问题,这很关键。

面试官是需要诱导的,毕竟他也想知道你优秀的方面到底有多优秀,你也取长补短,双赢双赢。

来回答下为什么用 Javassist,很简单,就是快,且字节码生成方便

ASM 比 Javassist 更快,但是没有快一个数量级,而Javassist 只需用字符串拼接就可以生成字节码,而 ASM 需要手工生成,成本较高,比较麻烦。

如果让你设计一个 RPC 框架,如何设计?

面试官都很喜欢问这类问题,来考验候选人的设计能力,和平日有无全方面的了解过一个框架。

如果你平时没有思考,没有往这方面想过答出来的东西就会没有条理性,会显得杂乱无章,不过你也不用慌张,不用想的很全面,答的很细致,没有必要,面试官要的是那些关键的重点。

你可以从底层向上开始说起

首先需要实现高性能的网络传输,可以采用 Netty 来实现,不用自己重复造轮子,然后需要自定义协议,毕竟远程交互都需要遵循一定的协议,然后还需要定义好序列化协议,网络的传输毕竟都是二进制流传输的。

然后可以搞一套描述服务的语言,即 IDL(Interface description language),让所有的服务都用 IDL 定义,再由框架转换为特定编程语言的接口,这样就能跨语言了。

此时最近基本的功能已经有了,但是只是最基础的,工业级的话首先得易用,所以框架需要把上述的细节对使用者进行屏蔽,让他们感觉不到本地调用和远程调用的区别,所以需要代理实现。

然后还需要实现集群功能,因此的要服务发现、注册等功能,所以需要注册中心,当然细节还是需要屏蔽的。

最后还需要一个完善的监控机制,埋点上报调用情况等等,便于运维。

这样一个 RPC 框架的雏形就差不多了。

最后

Dubbo 系列就到此结束了,其实还是有很多细节的,如果要写肯定还是有很多可以写的。

不过整体脉络都理清楚了,之后的修行还是得靠大家自己多多努力。

面试题肯定不止这一些,面试题是问不完的,真实的面试肯定是抓住你回答的点来深挖,所以我也模拟不了,我只能告诉你大致关键点,和揣摩一下面试官的心理活动。

当面试官问你的时候你可以试着去揣摩,看看他到底想要问什么,这很关键

面试的时候不要慌,你和面试官是平等的,而且面试官不一定你厉害,还有面试有时候就是看运气了,面试失败了也不要气馁,换一家就好了,有时候就是气场不和,这很正常。

加油。

查看原文

赞 11 收藏 7 评论 0

敖丙 发布了文章 · 9月16日

Dubbo服务引入过程

上篇文章我们已经了解了 Dubbo 服务暴露全过程,这篇文章我就带着大家再来看看 Dubbo 服务引入全流程,这篇服务引入写完下一篇就要来个全链路打通了,看看大家看完会不会有种任督二脉都被打通的感觉。

在写文章的过程中丙还发现官网的一点小问题,下文中会提到。

话不多说,咱们直接进入正题。

服务引用大致流程

我们已经得知 Provider将自己的服务暴露出来,注册到注册中心,而 Consumer 无非就是通过一波操作从注册中心得知 Provider 的信息,然后自己封装一个调用类和 Provider 进行深入地交流。

而之前的文章我都已经提到在 Dubbo 中一个可执行体就是 Invoker,所有调用都要向 Invoker 靠拢,因此可以推断出应该要先生成一个 Invoker,然后又因为框架需要往不侵入业务代码的方向发展,那我们的 Consumer 需要无感知的调用远程接口,因此需要搞个代理类,包装一下屏蔽底层的细节。

整体大致流程如下:

服务引入的时机

服务的引入和服务的暴露一样,也是通过 spring 自定义标签机制解析生成对应的 Bean,Provider Service 对应解析的是 ServiceBean 而 Consumer Reference 对应的是 ReferenceBean

前面服务暴露的时机我们上篇文章分析过了,在 Spring 容器刷新完成之后开始暴露,而服务的引入时机有两种,第一种是饿汉式,第二种是懒汉式。

饿汉式是通过实现 Spring 的 InitializingBean 接口中的 afterPropertiesSet 方法,容器通过调用 ReferenceBean afterPropertiesSet 方法时引入服务。

懒汉式是只有当这个服务被注入到其他类中时启动引入流程,也就是说用到了才会开始服务引入。

默认情况下,Dubbo 使用懒汉式引入服务,如果需要使用饿汉式,可通过配置 <dubbo:reference> 的 init 属性开启。

我们可以看到 ReferenceBean 还实现了 FactoryBean 接口,这里有个关于 Spring 的面试点我带大家分析一波。

BeanFactory 、FactoryBean、ObjectFactory

就是这三个玩意,我单独拿出来说一下,从字面上来看其实可以得知 BeanFactoryObjectFactory 是个工厂而 FactoryBean 是个 Bean。

BeanFactory 其实就是 IOC 容器,有多种实现类我就不分析了,简单的说就是 Spring 里面的 Bean 都归它管,而 FactoryBean 也是 Bean 所以说也是归 BeanFactory 管理的。

FactoryBean 到底是个什么 Bean 呢?它其实就是把你真实想要的 Bean 封装了一层,在真正要获取这个 Bean 的时候容器会调用 FactoryBean#getObject() 方法,而在这个方法里面你可以进行一些复杂的组装操作。

这个方法就封装了真实想要的对象复杂的创建过程

到这里其实就很清楚了,就是在真实想要的 Bean 创建比较复杂的情况下,或者是一些第三方 Bean 难以修改的情形,使用 FactoryBean 封装了一层,屏蔽了底层创建的细节,便于 Bean 的使用。

而 ObjectFactory 这个是用于延迟查找的场景,它就是一个普通工厂,当得到 ObjectFactory 对象时,相当于 Bean 没有被创建,只有当 getObject() 方法时,才会触发 Bean 实例化等生命周期。

主要用于暂时性地获取某个 Bean Holder 对象,如果过早的加载,可能会引起一些意外的情况,比如当 Bean A 依赖 Bean B 时,如果过早地初始化 A,那么 B 里面的状态可能是中间状态,这时候使用 A 容易导致一些错误。

总结的说 BeanFactory 就是 IOC 容器,FactoryBean 是特殊的 Bean, 用来封装创建比较复杂的对象,而 ObjectFactory 主要用于延迟查找的场景,延迟实例化对象

服务引入的三种方式

服务的引入又分为了三种,第一种是本地引入、第二种是直接连接引入远程服务、第三种是通过注册中心引入远程服务。

本地引入不知道大家是否还有印象,之前服务暴露的流程每个服务都会通过搞一个本地暴露,走 injvm 协议(当然你要是 scope = remote 就没本地引用了),因为存在一个服务端既是 Provider 又是 Consumer 的情况,然后有可能自己会调用自己的服务,因此就弄了一个本地引入,这样就避免了远程网络调用的开销。

所以服务引入会先去本地缓存找找看有没有本地服务

直连远程引入服务,这个其实就是平日测试的情况下用用,不需要启动注册中心,由 Consumer 直接配置写死 Provider 的地址,然后直连即可。

注册中心引入远程服务,这个就是重点了,Consumer 通过注册中心得知 Provider 的相关信息,然后进行服务的引入,这里还包括多注册中心,同一个服务多个提供者的情况,如何抉择如何封装,如何进行负载均衡、容错并且让使用者无感知,这就是个技术活。

本文用的就是单注册中心引入远程服务,让我们来看看 Dubbo 是如何做的吧。

服务引入流程解析

默认是懒汉式的,所以服务引入的入口就是 ReferenceBean 的 getObject 方法。

可以看到很简单,就是调用 get 方法,如果当前还没有这个引用那么就执行 init 方法。

官网的一个小问题

这个问题就在 if (ref == null) 这一行,其实是一位老哥在调试的时候发现这个 ref 竟然不等于 null,因此就进不到 init 方法里面调试了,后来他发现是因为 IDEA 为了显示对象的信息,会通过 toString 方法获取对象对应的信息。

toString 调用的是 AbstractConfig#toString,而这个方法会通过反射调用了 ReferenceBean 的 getObject 方法,触发了引入服务动作,所以说到断点的时候 ref != null

可以看到是通过方法名来进行反射调用的,而 getObject 就是 get 开头的,因此会被调用。

所以这个哥们提了个 PR,但是一开始没有被接受,一位 Member 认为这不是 bug, idea 设置一下不让调用 toString 就好了。

不过另一位 Member 觉得这个 PR 挺好的,并且 Dubbo 项目二代掌门人北纬30也发话了,因此这个 PR 被受理了。

至此我们已经知道这个小问题了,然后官网上其实也写的很清楚。

但是小问题来了,之前我在文章提到我的源码版本是 2.6.5,是在 github 的 releases 里面下的,这个 tostring 问题其实我挺早之前就知道了,我想的是我 2.6.5 稳的一批,谁知道翻车了。

我调试的时候也没进到 init 方法因为 ref 也没等于 null,我就奇怪了,我里面去看了下 toString 方法,2.6.5版本竟然没有修改?没有将 getObject 做过滤,因此还是被调用了。

我又打开了2.7.5版本的代码,发现是修改过的判断。

我又去特意下了 2.6.6 版本的代码,发现也是修改过的,因此这个修改并不是随着 2.6.5 版本发布,而是 2.6.6,除非我下的是个假包,这就是我说的小问题了,不过影响不大。

其实提到这一段主要想说的是那个 PR,作为一个开源软件的输出者,很多细节也是很重要的,这个问题其实很影响源码的调试,因为对代码不熟,肯定会一脸懵逼,谁知道是不是哪个后台线程异步引入了呢。

提这个 PR 的老哥花了两个小时才搞清楚真正的原因,所以说虽然这不是个 bug 但是很影响那些想深入了解 Dubbo 内部结构的同学们,这种改配置去适应的方案是不可取了,还好最终的方案是改代码。

好了让我们回到今天的主题,接下来分析的就是那个不让我进去的 init 方法了。

源码分析

init 方法很长,不过大部分就是检查配置然后将配置构建成 map ,这一大段我就不分析了,我们直接看一下构建完的 map 长什么样。

然后就进入重点方法 createProxy,从名字可以得到就是要创建的一个代理,因为代码很长,我就一段一段的分析

如果是走本地的话,那么直接构建个走本地协议的 URL 然后进行服务的引入,即 refprotocol.refer,这个方法之后会做分析,本地的引入就不深入了,就是去之前服务暴露的 exporterMap 拿到服务。

如果不是本地,那肯定是远程了,接下来就是判断是点对点直连 provider 还是通过注册中心拿到 provider 信息再连接 provider 了,我们分析一下配置了 url 的情况,如果配置了 url 那么不是直连的地址,就是注册中心的地址。

然后就是没配置 url 的情况,到这里肯定走的就是注册中心引入远程服务了。

最终拼接出来的 URL 长这样。

可以看到这一部分其实就是根据各种参数来组装 URL ,因为我们的自适应扩展都需要根据 URL 的参数来进行的。

至此我先画个图,给大家先捋一下。

这其实就是整个流程了,简述一下就是先检查配置,通过配置构建一个 map ,然后利用 map 来构建 URL ,再通过 URL 上的协议利用自适应扩展机制调用对应的 protocol.refer 得到相应的 invoker 。

在有多个 URL 的时候,先遍历构建出 invoker 然后再由 StaticDirectory 封装一下,然后通过 cluster 进行合并,只暴露出一个 invoker 。

然后再构建代理,封装 invoker 返回服务引用,之后 Comsumer 调用的就是这个代理类。

相信通过图和上面总结性的简述已经知道大致的服务引入流程了,不过还是有很多细节,比如如何从注册中心得到 Provider 的地址,invoker 里面到底是怎么样的?别急,我们继续看。

从前面的截图我们可以看到此时的协议是 registry 因此走的是 RegistryProtocol#refer,我们来看一下这个方法。

主要就是获取注册中心实例,然后调用 doRefer 进行真正的 refer。

这个方法很关键,可以看到生成了 RegistryDirectory 这个 directory 塞了注册中心实例,它自身也实现了 NotifyListener 接口,因此注册中心的监听其实是靠这家伙来处理的

然后向注册中心注册自身的信息,并且向注册中心订阅了 providers 节点、 configurators 节点 和 routers 节点,订阅了之后 RegistryDirectory 会收到这几个节点下的信息,就会触发 DubboInvoker 的生成了,即用于远程调用的 Invoker

然后通过 cluster 再包装一下得到 Invoker,因此一个服务可能有多个提供者,最终在 ProviderConsumerRegTable 中记录这些信息,然后返回 Invoker。

所以我们知道 Conusmer 是在 RegistryProtocol#refer 中向注册中心注册自己的信息,并且订阅 Provider 和配置的一些相关信息,我们看看订阅返回的信息是怎样的。

拿到了 Provider 的信息之后就可以通过监听触发 DubboProtocol# refer 了(具体调用哪个 protocol 还是得看 URL的协议的,我们这里是 dubbo 协议),整个触发流程我就不一一跟一下了,看下调用栈就清楚了。

终于我们从注册中心拿到远程 Provider 的信息了,然后进行服务的引入。

这里的重点在 getClients,因为终究是要跟远程服务进行网络调用的,而 getClients 就是用于获取客户端实例,实例类型为 ExchangeClient,底层依赖 Netty 来进行网络通信,并且可以看到默认是共享连接。

getSharedClient 我就不分析了,就是通过远程地址找 client ,这个 client 还有引用计数的功能,如果该远程地址还没有 client 则调用 initClient,我们就来看一下 initClient 方法。

而这个 connect 最终返回 HeaderExchangeClient 里面封装的是 NettyClient

然后最终得到的 Invoker 就是这个样子,可以看到记录的很多信息,基本上该有的都有了,我这里走的是对应的服务只有一个 url 的情况,多个 url 无非也是利用 directorycluster 再封装一层。

最终将调用 return (T) proxyFactory.getProxy(invoker); 返回一个代理对象,这个就不做分析了。

到这里,整个流程就是分析完了,不知道大家清晰了没?我再补充前面的图,来一个完整的流程给大家再过一遍。

小结

相信分析下来整个流程不难的,总结地说无非就是通过配置组成 URL ,然后通过自适应得到对于的实现类进行服务引入,如果是注册中心那么会向注册中心注册自己的信息,然后订阅注册中心相关信息,得到远程 provider 的 ip 等信息,再通过 netty 客户端进行连接。

并且通过 directorycluster 进行底层多个服务提供者的屏蔽、容错和负载均衡等,这个之后文章会详细分析,最终得到封装好的 invoker 再通过动态代理封装得到代理类,让接口调用者无感知的调用方法。

最后

今天这篇文章看下来相信大家对服务的引入应该有了清晰的认识,其实里面还是很多细节我没有展开分析,比如一些过滤链的组装,这其实在服务暴露的文章里面已经说了,同样服务引用也有过滤链,不过篇幅有限就不展开了,抓住主线要紧。

至此我已经带大家先过了一遍 Dubbo 的整体概念和大致流程,介绍了 Dubbo SPI 机制,并且分析了服务的暴露流程服务引入流程,具体的细节还是得大家自己去摸索,大致的流程我都讲的差不多了。

dubbo系列也快接近尾声了,虽然我知道每次写硬核技术看的小伙伴就少了很多,但是还是想写完这个系列,感谢大家的支持。

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!


查看原文

赞 3 收藏 3 评论 0

敖丙 发布了文章 · 9月15日

Dubbo服务暴露过程

这周去苏州见大佬,没想到遇到一堆女粉丝,其中居然还有澡堂子堂妹,堂妹一遇到我就说敖丙哥哥我超级喜欢你写的dubbo系列,你能跟我好好讲一下他的服务暴露过程么?

我笑了笑:傻瓜,你想看怎么不早点说呢?

我今天来就带大家看看 Dubbo 服务暴露过程,这个过程在 Dubbo 中其实是很核心的过程之一,关乎到你的 Provider 如何能被 Consumer 得知并调用。

今天还是会进行源码解析,毕竟我们需要深入的去了解 Dubbo 是如何做的,只有深入它才能了解它。

不用担心源码问题,因为不仅仅有源码解析,敖丙也会通过画图和总结性的语言帮助大家理解,而且在面对面试官的时候,总结性的语言才是最重要的,因为不见得面试官也懂得或者记得具体的细节。

对了,源码是 2.6.5 版本。

URL

不过在进行服务暴露流程分析之前有必要先谈一谈 URL,有人说这 URL 和 Dubbo 啥关系?有关系,有很大的关系!

一般而言我们说的 URL 指的就是统一资源定位符,在网络上一般指代地址,本质上看其实就是一串包含特殊格式的字符串,标准格式如下:

protocol://username:password@host:port/path?key=value&key=value

Dubbo 就是采用 URL 的方式来作为约定的参数类型,被称为公共契约,就是我们都通过 URL 来交互,来交流。

你想一下如果没有一个约束,没有指定一个都公共的契约那么不同的接口就会以不同的参数来传递信息,一会儿用 Map、一会儿用特定分隔的字符串,这就是导致整体很乱,并且解析不能统一。

用了一个统一的契约之后,那么代码就更加的规范化、形成一种统一的格式,所有人对参数就一目了然,不用去揣测一些参数的格式等等。

而且用 URL 作为一个公共约束充分的利用了我们对已有概念的印象,通俗易懂并且容易扩展,我们知道 URL 要加参数只管往后面拼接就完事儿了。

因此 Dubbo 用 URL 作为配置总线,贯穿整个体系,源码中 URL 的身影无处不在。

URL 具体的参数如下:

  • protocol:指的是 dubbo 中的各种协议,如:dubbo thrift http
  • username/password:用户名/密码
  • host/port:主机/端口
  • path:接口的名称
  • parameters:参数键值对

配置解析

一般常用 XML 或者注解来进行 Dubbo 的配置,我稍微说一下 XML 的,这块其实是属于 Spring 的内容,我不做过多的分析,就稍微讲一下大概的原理。

Dubbo 利用了 Spring 配置文件扩展了自定义的解析,像 dubbo.xsd 就是用来约束 XML 配置时候的标签和对应的属性用的,然后 Spring 在解析到自定义的标签的时候会查找 spring.schemas 和 spring.handlers。

spring.schemas 就是指明了约束文件的路径,而 spring.handlers 指明了利用该 handler 来解析标签,你看好的框架都是会预留扩展点的,讲白了就是去固定路径的固定文件名去找你扩展的东西,这样才能让用户灵活的使用。

我们再来看一下 DubboNamespaceHandler 都干了啥。

讲白了就是将标签对应的解析类关联起来,这样在解析到标签的时候就知道委托给对应的解析类解析,本质就是为了生成 Spring 的 BeanDefinition,然后利用 Spring 最终创建对应的对象。

服务暴露全流程

我们在深入源码之前来看下总的流程,有个大致的印象看起来比较不容易晕

代码的流程来看大致可以分为三个步骤(本文默认都需要暴露服务到注册中心)。

第一步是检测配置,如果有些配置空的话会默认创建,并且组装成 URL 。

第二步是暴露服务,包括暴露到本地的服务和远程的服务。

第三步是注册服务至注册中心。

对象构建转换的角度看可以分为两个步骤。

第一步是将服务实现类转成 Invoker。

第二部是将 Invoker 通过具体的协议转换成 Exporter。

服务暴露源码分析

接下来我们进入源码分析阶段,从上面配置解析的截图标红了的地方可以看到 service 标签其实就是对应 ServiceBean,我们看下它的定义。

这里又涉及到 Spring 相关内容了,可以看到它实现了 ApplicationListener<ContextRefreshedEvent>,这样就会在 Spring IOC 容器刷新完成后调用 onApplicationEvent 方法,而这个方法里面做的就是服务暴露,这就是服务暴露的启动点。

可以看到,如果不是延迟暴露、并且还没暴露过、并且支持暴露的话就执行 export 方法,而 export 最终会调用父类的 export 方法,我们来看看。

主要就是检查了一下配置,确认需要暴露的话就暴露服务, doExport 这个方法很长,不过都是一些检测配置的过程,虽说不可或缺不过不是我们关注的重点,我们重点关注里面的 doExportUrls 方法。

可以看到 Dubbo 支持多注册中心,并且支持多个协议,一个服务如果有多个协议那么就都需要暴露,比如同时支持 dubbo 协议和 hessian 协议,那么需要将这个服务用两种协议分别向多个注册中心(如果有多个的话)暴露注册。

loadRegistries 方法我就不做分析了,就是根据配置组装成注册中心相关的 URL ,我就给大家看下拼接成的 URL的样子。

registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.0.2&pid=7960&qos.port=22222&registry=zookeeper&timestamp=1598624821286

我们接下来关注的重点在 doExportUrlsFor1Protocol 方法中,这个方法挺长的,我会截取大致的部分来展示核心的步骤。

此时构建出来的 URL 长这样,可以看到走得是 dubbo 协议。

然后就是要根据 URL 来进行服务暴露了,我们再来看下代码,这段代码我就直接截图了,因为需要断点的解释。

本地暴露

我们再来看一下 exportLocal 方法,这个方法是本地暴露,走的是 injvm 协议,可以看到它搞了个新的 URL 修改了协议。

我们来看一下这个 URL,可以看到协议已经变成了 injvm。

这里的 export 其实就涉及到上一篇文章讲的自适应扩展了。

 Exporter<?> exporter = protocol.export(
                    proxyFactory.getInvoker(ref, (Class) interfaceClass, local));

Protocol 的 export 方法是标注了 @ Adaptive 注解的,因此会生成代理类,然后代理类会根据 Invoker 里面的 URL 参数得知具体的协议,然后通过 Dubbo SPI 机制选择对应的实现类进行 export,而这个方法就会调用 InjvmProtocol#export 方法。

我们再来看看转换得到的 export 到底长什么样子。

从图中可以看到实际上就是具体实现类层层封装, invoker 其实是由 Javassist 创建的,具体创建过程 proxyFactory.getInvoker 就不做分析了,对 Javassist 有兴趣的同学自行去了解,之后可能会写一篇,至于 dubbo 为什么用 javassist 而不用 jdk 动态代理是因为 javassist 快

为什么要封装成 invoker

至于为什么要封装成 invoker 其实就是想屏蔽调用的细节,统一暴露出一个可执行体,这样调用者简单的使用它,向它发起 invoke 调用,它有可能是一个本地的实现,也可能是一个远程的实现,也可能一个集群实现。

为什么要搞个本地暴露呢

因为可能存在同一个 JVM 内部引用自身服务的情况,因此暴露的本地服务在内部调用的时候可以直接消费同一个 JVM 的服务避免了网络间的通信

可以有些同学已经有点晕,没事我这里立马搞个图带大家过一遍。

对 exportLocal 再来一波时序图分析。

远程暴露

至此本地暴露已经好了,接下来就是远程暴露了,即下面这一部分代码

也和本地暴露一样,需要封装成 Invoker ,不过这里相对而言比较复杂一些,我们先来看下 registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()) 将 URL 拼接成什么样子。

registry://127.0.0.1:2181/com.alibaba.dubbo.registry.RegistryService?application=demo-provider&dubbo=2.0.2&export=dubbo://192.168.1.17:20880/com.alibaba.dubbo.demo.DemoService....

因为很长,我就不截全了,可以看到走 registry 协议,然后参数里又有 export=dubbo://,这个走 dubbo 协议,所以我们可以得知会先通过 registry 协议找到 RegistryProtocol 进行 export,并且在此方法里面还会根据 export 字段得到值然后执行 DubboProtocol 的 export 方法。

大家要挺住,就快要完成整个流程的解析了!

现在我们把目光聚焦到 RegistryProtocol#export 方法上,我们先过一遍整体的流程,然后再进入 doLocalExport 的解析。

可以看到这一步主要是将上面的 export=dubbo://... 先转换成 exporter ,然后获取注册中心的相关配置,如果需要注册则向注册中心注册,并且在 ProviderConsumerRegTable 这个表格中记录服务提供者,其实就是往一个 ConcurrentHashMap 中将塞入 invoker,key 就是服务接口全限定名,value 是一个 set,set 里面会存包装过的 invoker 。

我们再把目光聚焦到 doLocalExport 方法内部。

这个方法没什么难度,主要就是根据URL上 Dubbo 协议暴露出 exporter,接下来就看下 DubboProtocol#export 方法。

可以看到这里的关键其实就是打开 Server ,RPC 肯定需要远程调用,这里我们用的是 NettyServer 来监听服务。

再下面我就不跟了,我总结一下 Dubbo 协议的 export 主要就是根据 URL 构建出 key(例如有分组、接口名端口等等),然后 key 和 invoker 关联,关联之后存储到 DubboProtocol 的 exporterMap 中,然后如果是服务初次暴露则会创建监听服务器,默认是 NettyServer,并且会初始化各种 Handler 比如心跳啊、编解码等等。

看起来好像流程结束了?并没有, Filter 到现在还没出现呢?有隐藏的措施,上一篇 Dubbo SPI 看的仔细的各位就知道在哪里触发的。

其实上面的 protocol 是个代理类,在内部会通过 SPI 机制找到具体的实现类。

这张图是上一篇文章的,可以看到 export 具体的实现。

复习下上一篇的要点,通过 Dubbo SPI 扫包会把 wrapper 结尾的类缓存起来,然后当加载具体实现类的时候会包装实现类,来实现 Dubbo 的 AOP,我们看到 DubboProtocol 有什么包装类。

可以看到有两个,分别是 ProtocolFilterWrapper 和 ProtocolListenerWrapper

对于所有的 Protocol 实现类来说就是这么个调用链。

而在 ProtocolFilterWrapper 的 export 里面就会把 invoker 组装上各种 Filter。

看看有 8 个在。

我们再来看下 zookeeper 里面现在是怎么样的,关注 dubbo 目录。

两个 service 占用了两个目录,分别有 configurators 和 providers 文件夹,文件夹里面记录的就是 URL 的那一串,值是服务提供者 ip。

至此服务流程暴露差不多完结了,可以看到还是有点内容在里面的,并且还需要掌握 Dubbo SPI,不然有些点例如自适应什么的还是很难理解的。最后我再来一张完整的流程图带大家再过一遍,具体还是有很多细节,不过不是主干我就不做分析了,不然文章就有点散。

然后再引用一下官网的时序图。

总结

还是建议大家自己打断点过一遍,这样能够更加的清晰,到时候面试官问起来一点都不虚,不过只要你认真看了这篇文章也差不多了,总的流程能说出来能证明你看过源码,一些细节记不住的,你想想看你自己写的代码过一两个月你记得住不?更别说别人写的了。

其实我可以不源码分析,我可以直接口述 + 画图,观赏性更佳,但是为什么我还是贴代码呢?

想带着大家从源码级别来过一遍流程,这样能让大家更有底气,毕竟你看图理解了是一回事,真正的看到源码,就会很直观的知道一些点,例如,缓存原来就是放一个 map 中,这过滤链原来是这样拼接的等等等等。

总的而言服务暴露的过程起始于 Spring IOC 容器刷新完成之时,具体的流程就是根据配置得到 URL,再利用 Dubbo SPI 机制根据 URL 的参数选择对应的实现类,实现扩展。

通过 javassist 动态封装 ref (你写的服务实现类),统一暴露出 Invoker 使得调用方便,屏蔽底层实现细节,然后封装成 exporter 存储起来,等待消费者的调用,并且会将 URL 注册到注册中心,使得消费者可以获取服务提供者的信息。

今天这个就差不多了,Dubbo 系列估计还有几篇,到时候再来个面试汇总,等着吧!

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 2 收藏 2 评论 0

敖丙 发布了文章 · 9月14日

Dubbo的SPI机制

前言

上一篇 Dubbo 文章敖丙已经带了大家过了一遍整体的架构,也提到了 Dubbo 的成功离不开它采用微内核设计+SPI扩展,使得有特殊需求的接入方可以自定义扩展,做定制的二次开发。

良好的扩展性对于一个框架而言尤其重要,框架顾名思义就是搭好核心架子,给予用户简单便捷的使用,同时也需要满足他们定制化的需求

Dubbo 就依靠 SPI 机制实现了插件化功能,几乎将所有的功能组件做成基于 SPI 实现,并且默认提供了很多可以直接使用的扩展点,实现了面向功能进行拆分的对扩展开放的架构

什么是 SPI

首先我们得先知道什么叫 SPI。

SPI (Service Provider Interface),主要是用来在框架中使用的,最常见和莫过于我们在访问数据库时候用到的java.sql.Driver接口了。

你想一下首先市面上的数据库五花八门,不同的数据库底层协议的大不相同,所以首先需要定制一个接口,来约束一下这些数据库,使得 Java 语言的使用者在调用数据库的时候可以方便、统一的面向接口编程。

数据库厂商们需要根据接口来开发他们对应的实现,那么问题来了,真正使用的时候到底用哪个实现呢?从哪里找到实现类呢?

这时候 Java SPI 机制就派上用场了,不知道到底用哪个实现类和找不到实现类,我们告诉它不就完事了呗。

大家都约定好将实现类的配置写在一个地方,然后到时候都去哪个地方查一下不就知道了吗?

Java SPI 就是这样做的,约定在 Classpath 下的 META-INF/services/ 目录里创建一个以服务接口命名的文件,然后文件里面记录的是此 jar 包提供的具体实现类的全限定名

这样当我们引用了某个 jar 包的时候就可以去找这个 jar 包的 META-INF/services/ 目录,再根据接口名找到文件,然后读取文件里面的内容去进行实现类的加载与实例化。

比如我们看下 MySQL 是怎么做的。

再来看一下文件里面的内容。

MySQL 就是这样做的,为了让大家更加深刻的理解我再简单的写一个示例。

Java SPI 示例

然后我在 META-INF/services/ 目录下建了个以接口全限定名命名的文件,内容如下

com.demo.spi.NuanNanAobing
com.demo.spi.ShuaiAobing

运行之后的结果如下

Java SPI 源码分析

之前的文章我也提到了 Dubbo 并没有用 Java 实现的 SPI,而是自定义 SPI,那肯定是 Java SPI 有什么不方便的地方或者劣势。

因此丙带着大家先深入了解一下 Java SPI,这样才能知道哪里不好,进而再和 Dubbo SPI 进行对比的时候会更加的清晰其优势。

大家看到源码不要怕,丙已经给大家做了注释,并且逻辑也不难的,想要变强源码不可或缺。为了让大家更好的理解,丙在源码分析完了之后还会画个图,帮大家再理一下思路。

从上面我的示例中可以看到ServiceLoader.load()其实就是 Java SPI 入口,我们来看看到底做了什么操作。

我用一句话概括一下,简单的说就是先找当前线程绑定的 ClassLoader,如果没有就用 SystemClassLoader,然后清除一下缓存,再创建一个 LazyIterator。

那现在重点就是 LazyIterator了,从上面代码可以看到我们调用了 hasNext() 来做实例循环,通过 next() 得到一个实例。而 LazyIterator 其实就是 Iterator 的实现类。我们来看看它到底干了啥。

不管进入 if 分支还是 else 分支,重点都在我框出来的代码,接下来就进入重要时刻了!

可以看到这个方法其实就是在约定好的地方找到接口对应的文件,然后加载文件并且解析文件里面的内容。

我们再来看一下 nextService()。

所以就是通过文件里填写的全限定名加载类,并且创建其实例放入缓存之后返回实例。

整体的 Java SPI 的源码解析已经完毕,是不是很简单?就是约定一个目录,根据接口名去那个目录找到文件,文件解析得到实现类的全限定名,然后循环加载实现类和创建其实例。

我再用一张图来带大家过一遍。

想一下 Java SPI 哪里不好

相信大家一眼就能看出来,Java SPI 在查找扩展实现类的时候遍历 SPI 的配置文件并且将实现类全部实例化,假设一个实现类初始化过程比较消耗资源且耗时,但是你的代码里面又用不上它,这就产生了资源的浪费。

所以说 Java SPI 无法按需加载实现类。

Dubbo SPI

因此 Dubbo 就自己实现了一个 SPI,让我们想一下按需加载的话首先你得给个名字,通过名字去文件里面找到对应的实现类全限定名然后加载实例化即可。

Dubbo 就是这样设计的,配置文件里面存放的是键值对,我截一个 Cluster 的配置。

并且 Dubbo SPI 除了可以按需加载实现类之外,增加了 IOC 和 AOP 的特性,还有个自适应扩展机制。

我们先来看一下 Dubbo 对配置文件目录的约定,不同于 Java SPI ,Dubbo 分为了三类目录。

  • META-INF/services/ 目录:该目录下的 SPI 配置文件是为了用来兼容 Java SPI 。
  • META-INF/dubbo/ 目录:该目录存放用户自定义的 SPI 配置文件。
  • META-INF/dubbo/internal/ 目录:该目录存放 Dubbo 内部使用的 SPI 配置文件。

Dubbo SPI 简单实例

用法很是简单,我就拿官网上的例子来展示一下。

首先在 META-INF/dubbo 目录下按接口全限定名建立一个文件,内容如下:

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

然后在接口上标注@SPI 注解,以表明它要用SPI机制,类似下面这个图(我就是拿 Cluster 的图举个例子,和这个示例代码定义的接口不一样)。

接着通过下面的示例代码即可加载指定的实现类。

再来看一下运行的结果。

Dubbo 源码分析

此次分析的源码版本是 2.6.5

相信通过上面的描述大家已经对 Dubbo SPI 已经有了一定的认识,接下来我们来看看它的实现。

从上面的示例代码我们知道 ExtensionLoader 好像就是重点,它是类似 Java SPI 中 ServiceLoader 的存在。

我们可以看到大致流程就是先通过接口类找到一个 ExtensionLoader ,然后再通过 ExtensionLoader.getExtension(name) 得到指定名字的实现类实例。

我们就先看下 getExtensionLoader() 做了什么。

很简单,做了一些判断然后从缓存里面找是否已经存在这个类型的 ExtensionLoader ,如果没有就新建一个塞入缓存。最后返回接口类对应的 ExtensionLoader 。

我们再来看一下 getExtension() 方法,从现象我们可以知道这个方法就是从类对应的 ExtensionLoader 中通过名字找到实例化完的实现类。

可以看到重点就是 createExtension(),我们再来看下这个方法干了啥。

整体逻辑很清晰,先找实现类,判断缓存是否有实例,没有就反射建个实例,然后执行 set 方法依赖注入。如果有找到包装类的话,再包一层。

到这步为止我先画个图,大家理一理,还是很简单的。

那么问题来了 getExtensionClasses() 是怎么找的呢?injectExtension() 如何注入的呢(其实我已经说了set方法注入)?为什么需要包装类呢?

getExtensionClasses

这个方法进去也是先去缓存中找,如果缓存是空的,那么调用 loadExtensionClasses,我们就来看下这个方法。

loadDirectory里面就是根据类名和指定的目录,找到文件先获取所有的资源,然后一个一个去加载类,然后再通过loadClass去做一下缓存操作。

可以看到,loadClass 之前已经加载了类,loadClass 只是根据类上面的情况做不同的缓存。分别有 AdaptiveWrapperClass 和普通类这三种,普通类又将Activate记录了一下。至此对于普通的类来说整个 SPI 过程完结了。

接下来我们分别看不是普通类的几种东西是干啥用的。

Adaptive 注解 - 自适应扩展

在进入这个注解分析之前,我们需要知道 Dubbo 的自适应扩展机制。

我们先来看一个场景,首先我们根据配置来进行 SPI 扩展的加载,但是我不想在启动的时候让扩展被加载,我想根据请求时候的参数来动态选择对应的扩展。

怎么做呢?

Dubbo 通过一个代理机制实现了自适应扩展,简单的说就是为你想扩展的接口生成一个代理类,可以通过JDK 或者 javassist 编译你生成的代理类代码,然后通过反射创建实例。

这个实例里面的实现会根据本来方法的请求参数得知需要的扩展类,然后通过 ExtensionLoader.getExtensionLoader(type.class).getExtension(从参数得来的name),来获取真正的实例来调用。

我从官网搞了个例子,大家来看下。

现在大家应该对自适应扩展有了一定的认识了,我们再来看下源码,到底怎么做的。

这个注解就是自适应扩展相关的注解,可以修饰类和方法上,在修饰类的时候不会生成代理类,因为这个类就是代理类,修饰在方法上的时候会生成代理类。

Adaptive 注解在类上

比如这个 ExtensionFactory 有三个实现类,其中一个实现类就被标注了 Adaptive 注解。

在 ExtensionLoader 构造的时候就会去通过getAdaptiveExtension 获取指定的扩展类的 ExtensionFactory。

我们再来看下 AdaptiveExtensionFactory 的实现。

可以看到先缓存了所有实现类,然后在获取的时候通过遍历找到对应的 Extension。

我们再来深入分析一波 getAdaptiveExtension 里面到底干了什么。

到这里其实已经和上文分析的 getExtensionClasses中loadClass 对 Adaptive 特殊缓存相呼应上了。

Adaptive 注解在方法上

注解在方法上则需要动态拼接代码,然后动态生成类,我们以 Protocol 为例子来看一下。

Protocol 没有实现类注释了 Adaptive ,但是接口上有两个方法注解了 Adaptive ,有两个方法没有。

因此它走的逻辑应该应该是 createAdaptiveExtensionClass

具体在里面如何生成代码的我就不再深入了,有兴趣的自己去看吧,我就把成品解析一下,就差不多了。

我美化一下给大家看看。

可以看到会生成包,也会生成 import 语句,类名就是接口加个$Adaptive,并且实现这接口,没有标记 Adaptive 注解的方法调用的话直接抛错。

我们再来看一下标注了注解的方法,我就拿 export 举例。

就像我前面说的那样,根据请求的参数,即 URL 得到具体要调用的实现类名,然后再调用 getExtension 获取。

整个自适应扩展流程如下。

WrapperClass - AOP

包装类是因为一个扩展接口可能有多个扩展实现类,而这些扩展实现类会有一个相同的或者公共的逻辑,如果每个实现类都写一遍代码就重复了,并且比较不好维护。

因此就搞了个包装类,Dubbo 里帮你自动包装,只需要某个扩展类的构造函数只有一个参数,并且是扩展接口类型,就会被判定为包装类,然后记录下来,用来包装别的实现类。

简单又巧妙,这就是 AOP 了。

injectExtension - IOC

直接看代码,很简单,就是查找 set 方法,根据参数找到依赖对象则注入。

这就是 IOC。

Activate 注解

这个注解我就简单的说下,拿 Filter 举例,Filter 有很多实现类,在某些场景下需要其中的几个实现类,而某些场景下需要另外几个,而 Activate 注解就是标记这个用的。

它有三个属性,group 表示修饰在哪个端,是 provider 还是 consumer,value 表示在 URL参数中出现才会被激活,order 表示实现类的顺序。

总结

先放个上述过程完整的图。

然后我们再来总结一下,今天丙先带大家了解了下什么是 SPI,写了个简单示例,并且进行了 Java SPI 源码分析。

得知了 Java SPI 会一次加载和实例化所有的实现类。

而 Dubbo SPI 则自己实现了 SPI,可以通过名字实例化指定的实现类,并且实现了 IOC 、AOP 与 自适应扩展 SPI 。

整体而言不是很难,也不会很绕,大家看了文章之后如果自己再过一遍收获会更大。

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 6 收藏 5 评论 0

敖丙 发布了文章 · 9月7日

MySQL索引凭什么能让查询效率提高这么多?

背景

我相信大家在数据库优化的时候都会说到索引,我也不例外,大家也基本上能对数据结构的优化回答个一二三,以及页缓存之类的都能扯上几句,但是有一次阿里P9的一个面试问我:你能从计算机层面开始说一下一个索引数据加载的流程么?(就是想让我聊IO)

我当场就去世了....因为计算机网络和操作系统的基础知识真的是我的盲区,不过后面我恶补了,废话不多说,我们就从计算机加载数据聊起,讲一下换个角度聊索引。

正文

MySQL的索引本质上是一种数据结构

让我们先来了解一下计算机的数据加载。

磁盘IO和预读:

先说一下磁盘IO,磁盘读取数据靠的是机械运动,每一次读取数据需要寻道、寻点、拷贝到内存三步操作。

寻道时间是磁臂移动到指定磁道所需要的时间,一般在5ms以下;

寻点是从磁道中找到数据存在的那个点,平均时间是半圈时间,如果是一个7200转/min的磁盘,寻点时间平均是600000/7200/2=4.17ms;

拷贝到内存的时间很快,和前面两个时间比起来可以忽略不计,所以一次IO的时间平均是在9ms左右。听起来很快,但数据库百万级别的数据过一遍就达到了9000s,显然就是灾难级别的了。

考虑到磁盘IO是非常高昂的操作,计算机操作系统做了预读的优化,当一次IO时,不光把当前磁盘地址的数据,而是把相邻的数据也都读取到内存缓冲区内,因为当计算机访问一个地址的数据的时候,与其相邻的数据也会很快被访问到。

每一次IO读取的数据我们称之为一页(page),具体一页有多大数据跟操作系统有关,一般为4k或8k,也就是我们读取一页内的数据时候,实际上才发生了一次IO。

(突然想到个我刚毕业被问过的问题,在64位的操作系统中,Java中的int类型占几个字节?最大是多少?为什么?)

那我们想要优化数据库查询,就要尽量减少磁盘的IO操作,所以就出现了索引。

索引是什么?

MySQL官方对索引的定义为:索引(Index)是帮助MySQL高效获取数据的数据结构。

MySQL中常用的索引在物理上分两类,B-树索引和哈希索引。

本次主要讲BTree索引。

BTree索引

BTree又叫多路平衡查找树,一颗m叉的BTree特性如下:

  • 树中每个节点最多包含m个孩子。
  • 除根节点与叶子节点外,每个节点至少有[ceil(m/2)]个孩子(ceil()为向上取整)。
  • 若根节点不是叶子节点,则至少有两个孩子。
  • 所有的叶子节点都在同一层。
  • 每个非叶子节点由n个key与n+1个指针组成,其中[ceil(m/2)-1] <= n <= m-1 。

这是一个3叉(只是举例,真实会有很多叉)的BTree结构图,每一个方框块我们称之为一个磁盘块或者叫做一个block块,这是操作系统一次IO往内存中读的内容,一个块对应四个扇区,紫色代表的是磁盘块中的数据key,黄色代表的是数据data,蓝色代表的是指针p,指向下一个磁盘块的位置。

来模拟下查找key为29的data的过程:

1、根据根结点指针读取文件目录的根磁盘块1。【磁盘IO操作1次

2、磁盘块1存储17,35和三个指针数据。我们发现17<29<35,因此我们找到指针p2。

3、根据p2指针,我们定位并读取磁盘块3。【磁盘IO操作2次

4、磁盘块3存储26,30和三个指针数据。我们发现26<29<30,因此我们找到指针p2。

5、根据p2指针,我们定位并读取磁盘块8。【磁盘IO操作3次

6、磁盘块8中存储28,29。我们找到29,获取29所对应的数据data。

由此可见,BTree索引使每次磁盘I/O取到内存的数据都发挥了作用,从而提高了查询效率。

但是有没有什么可优化的地方呢?

我们从图上可以看到,每个节点中不仅包含数据的key值,还有data值。而每一个页的存储空间是有限的,如果data数据较大时将会导致每个节点(即一个页)能存储的key的数量很小,当存储的数据量很大时同样会导致B-Tree的深度较大,增大查询时的磁盘I/O次数,进而影响查询效率。

B+Tree索引

B+Tree是在B-Tree基础上的一种优化,使其更适合实现外存储索引结构。在B+Tree中,所有数据记录节点都是按照键值大小顺序存放在同一层的叶子节点上,而非叶子节点上只存储key值信息,这样可以大大加大每个节点存储的key值数量,降低B+Tree的高度。

B+Tree相对于B-Tree有几点不同:

非叶子节点只存储键值信息, 数据记录都存放在叶子节点中, 将上一节中的B-Tree优化,由于B+Tree的非叶子节点只存储键值信息,所以B+Tree的高度可以被压缩到特别的低。

具体的数据如下:

InnoDB存储引擎中页的大小为16KB,一般表的主键类型为INT(占用4个字节)或BIGINT(占用8个字节),指针类型也一般为4或8个字节,也就是说一个页(B+Tree中的一个节点)中大概存储16KB/(8B+8B)=1K个键值(因为是估值,为方便计算,这里的K取值为〖10〗^3)。

也就是说一个深度为3的B+Tree索引可以维护10^3 10^3 10^3 = 10亿 条记录。(这种计算方式存在误差,而且没有计算叶子节点,如果计算叶子节点其实是深度为4了)

我们只需要进行三次的IO操作就可以从10亿条数据中找到我们想要的数据,比起最开始的百万数据9000秒不知道好了多少个华莱士了。

而且在B+Tree上通常有两个头指针,一个指向根节点,另一个指向关键字最小的叶子节点,而且所有叶子节点(即数据节点)之间是一种链式环结构。所以我们除了可以对B+Tree进行主键的范围查找和分页查找,还可以从根节点开始,进行随机查找。

数据库中的B+Tree索引可以分为聚集索引(clustered index)和辅助索引(secondary index)。

上面的B+Tree示例图在数据库中的实现即为聚集索引,聚集索引的B+Tree中的叶子节点存放的是整张表的行记录数据,辅助索引与聚集索引的区别在于辅助索引的叶子节点并不包含行记录的全部数据,而是存储相应行数据的聚集索引键,即主键。

当通过辅助索引来查询数据时,InnoDB存储引擎会遍历辅助索引找到主键,然后再通过主键在聚集索引中找到完整的行记录数据。

不过,虽然索引可以加快查询速度,提高 MySQL 的处理性能,但是过多地使用索引也会造成以下弊端

  • 创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加。
  • 除了数据表占数据空间之外,每一个索引还要占一定的物理空间。如果要建立聚簇索引,那么需要的空间就会更大。
  • 当对表中的数据进行增加、删除和修改的时候,索引也要动态地维护,这样就降低了数据的维护速度。
注意:索引可以在一些情况下加速查询,但是在某些情况下,会降低效率。

索引只是提高效率的一个因素,因此在建立索引的时候应该遵循以下原则:

  • 在经常需要搜索的列上建立索引,可以加快搜索的速度。
  • 在作为主键的列上创建索引,强制该列的唯一性,并组织表中数据的排列结构。
  • 在经常使用表连接的列上创建索引,这些列主要是一些外键,可以加快表连接的速度。
  • 在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,所以其指定的范围是连续的。
  • 在经常需要排序的列上创建索引,因为索引已经排序,所以查询时可以利用索引的排序,加快排序查询。
  • 在经常使用 WHERE 子句的列上创建索引,加快条件的判断速度。

现在大家知道索引为啥能这么快了吧,其实就是一句话,通过索引的结构最大化的减少数据库的IO次数,毕竟,一次IO的时间真的是太久了。。。

总结

就面试而言很多知识其实我们可以很容易就掌握了,但是要以学习为目的,你会发现很多东西我们得深入到计算机基础上才能发现其中奥秘,很多人问我怎么记住这么多东西,其实学习本身就是一个很无奈的东西,既然我们不能不学那为啥不好好学?去学会享受呢?最近我也在恶补基础,后面我会开始更新计算机基础和网络相关的知识的。

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 67 收藏 45 评论 7

敖丙 发布了文章 · 9月2日

Java/后端学习路线

前言

自学/学习路线这样的一期我想写很久了,因为一直想写的全一点硬核一点所以拖到了现在,我相信这一期对不管是还在学校还是已经工作的同学都有所帮助,不管是前端还是后端我都墙裂建议大家看完,因为这样会让你对你所工作的互联网领域相关技术栈有个初步的了解。

你们也知道敖丙我是个创作鬼才,常规的切入点也不是我的风格,我毕业后主要接触的都是电商领域,所以这一期我把目前所了解的技术栈加上之前电商系统的经验臆想了一个完整的电商系统,大家会看到很多熟悉的技术栈我相信也会看到自己未接触过的技术栈,我也会对每个技术栈的主要技术点提一下,至于细节就只能大家在我历史和未来的文章去看了。

这期可谓是呕心沥血之作,不要白嫖喲。

正文

我先介绍一下前端

前端

我读者群体是以后端为主的,如果有大学还没开始学习的小伙伴,这个时候我想已经是满屏幕的问号了,为啥我们后端程序员还要去学习前端呢?我只能告诉你,傻瓜,肤浅。

如果是已经大学毕业的程序员我相信每一个后端程序员都会简单的前端,甚至很多后端对目前前端最新技术也都是了解的,我们可不能闭门造车,谁告诉你后端就不学点前端了?而且你了解前端在之后工作联调过程中或许会有更好的思路对你的工作是有所帮助的。

我们上网最先接触到的肯定不是后端的一系列东西,而是移动端和前端网页,各种花里胡哨的样式不是我们要去了解的,但是网页的基本语言以及布局从0到1这个过程是我们应该去了解的,大家看到的花里胡哨的网页布局、链接、文字、图片、事件等,都是一个个的标签、class样式以及js事件而已。

技术背后的思想其实是互通的,所以作为后端以前端作为我们程序员学习的切入点是完全OK的(只是针对还未入门萌新猿),我相信在各位的大学前端基础课程也都是有安排的,而且不管是上学还是以后毕业我相信各位以后一定会接触些许前端的。

在大学一般都是用项目去锻炼技术的,那在项目里面很可能就是你一个人从前端到后端都是自己写的,我在大学就是这样的,现在工作了我们很多内容系统简单的前端也都是我们自己去开发的,因为为了简单的页面和逻辑去浪费前端的资源是没有很大必要的。

在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础和我觉得比较必须的。

HTMLCSSJSAjax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。

在这一层不光有这些还有Http协议和Servlet,requestresponsecookiesession这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。

扩展:前端技术我觉得VUE、React大家都可以尝试去用用,他们目前支持很多即插即用的插件会帮助你更便捷的开发出漂亮的网页。

Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。

前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始继续往下讲了。

网关层:

互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。

微服务分布式负载均衡云原生等我们经常提到的这些名词都是这些技术在场景背后支撑。

单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢?

负载均衡,LVS

我们机器都是IP访问的,但是我们上网都是访问域名就好了,那怎么通过我们申请的域名去请求到服务器呢?

DNS

大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验?

CDN

我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等?

zk

这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。

Nginx

这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。

我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。

这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开这一层的Zookeeper,接下来就是整个学习体系最复杂的部分了,服务端。

服务层:

这一层有点东西了,算是整个框架的核心,如果你跟敖丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。

我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。

为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,HTTPS,TCP协议,什么三次握手,四次挥手,中间人攻击等。

还有进程、线程、协程,内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而敖丙还做得不够,所以最近也是在恶补操作系统和网路相关的知识)。

了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,嵌入式实习结束后我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。

JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架设计模式(包括创建型、结构型、行为型),多线程和并发I/O流,Stream,网络编程你都需要了解。

代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。

写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。

代码写的时候你会接触代码的仓库管理工具mavenGradle,提交代码的时候会去学习项目版本管理工具Git

代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,通过跳板机访问服务器查看进程,查看文件,各种Vim操作指令等等。

当你自己研发系统发布时你发现很多命令其实可以写成一个脚本一键执行就好了,那Shell会让你事半功倍的。

系统层面的优化很多时候会很有限,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。

这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud等。

了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty

代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。

他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。

业务场景使用的多的时候你会想去了解RocketMQ,他也自带了分布式事务的解决方案,但是他并不适合超大数据量的场景,这个时候Kafka就会进入你的视线中。

我上面提到过zk,像DubboKafka等中间件都是用它做注册中心的(后续kafka会把zk去掉)很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。

服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。

此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。

Spring Cloud 中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。

你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化、云原生,你可能就会去了解像Docker,Kubernetes(K8s)等技术,你会发现他们给企业级应用提供了怎样的便捷。

微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。

这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。

这里呢还是想说我经常提到的那句话,你知道的越多,你不知道的越多,所有领域都是这样,一旦你深入了解了这个技术细节,衍生出来的新知识点和他的弊端会让你发现自己的无知,但学到自己不会的不断去进步会让你在学习的道路上走更远的。

好啦我们继续沿着图往下看,那再往下是啥呢?

数据层:

数据库可能是整个系统中最值钱的部分了,今年呢也发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,但是这个笑话背后我们应该得到的思考就是,数据是整个企业最重要最核心的东西,我现在在公司的大数据团队对此深有体会。

如果大家对大数据感兴趣我想我后面也可以找机会单独出一期大数据技术栈相关的专题。

数据库基本的事务隔离级别索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。

不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDLSharding-JDBCDRDS这些插件都会接触到。

你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是memcache也有各自的应用场景。

Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。

单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制......

老板让你最最小的代价去设计每日签到和UV、PV统计你就会接触到:位图和HyperLogLog,高速的过滤你就会考虑到:布隆过滤器 (Bloom Filter) ,附近的人就会使用到:GeoHash 他的大容量存储有问题,你可能需要去了解Pika....

其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。

实时/离线数仓/大数据

等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。

你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。

然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase

写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。

离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。

数据接触完了,计算引擎Spark你是不是也不能放过......

算法/机器学习/人工智能:

数据是整个电商系统乃至于我们整个互联网最值钱的部分不是随便说说的,但是如何发挥他们的价值,数据放在数据库是无法发挥他应有的价值的,算法在最近10年越来越受到大家的重视,机器学习、深度学习、人工智能、自动驾驶等领域也频频爆出天价offer的新闻,所以算法我觉得也有机会也是可以了解一下的。

不知道大家用搜索引擎或者购物网站使用过以图搜图功能没,这就是算法的图像搜索功能,我们在搜索栏输入对应关键词之后算法同学会通过自然语言处理,然后再落到推荐系统给出最好的搜索结果,以及大家看到的热搜,默认搜索的推荐都是通过算法算出针对你个人最优的推荐,你最最感兴趣的推荐。

就比如我最近在B站看了《龙王赘婿》相关的视频,我的默认搜索推荐就出现了《画网赘婿》的默认搜索推荐,这就是根据近期热点和你个人喜好算出来的,大家可以进去刷新试试。

国内人口基数这么大,那相对来说垃圾内容应该更多才对,但是大家几乎可以一直浏览到绿色健康的网络环境,这得益于风控,算法同学也会用风控去对涉黄,涉政等内容做一个甄别。

你要知道你的每一个行为在进入app开始就会被分析,最后给你打上一个个的标签,算法算出你最喜欢的内容投喂给你,你没发现抖音你越看内容越和你的胃口么?淘宝你越逛推荐的商品你越想买么?

这都得益于大数据和算法的结合,不断完善不同的训练模型,投喂给用户他最喜欢的内容,很多训练模型甚至以小时维度的更新频率在更新。

用户数据对内对外还有差别,因为很多平台是不会给你完整的数据的,但是算法同学会尽可能的捕捉用户的每一个潜在特性,然后去给你投喂最适合你的广告。

看到这里大家可能会担心自己的数据安全了,其实每个公司都会有自己最基本的职业操守,正常公司都是不会去出卖自己用户的任何数据的,但是市面上也存在销售用户数据的黑色产业。

生在这个大数据的年代是一件好事,技术是两面性也是我一直强调的,这样的技术会让你的所有信息透明,这个时候我们就要尽可能的注重保护我们自己的数据隐私安全,不要贪图小便宜去到处填写自己的真实信息,手机号,身份证号码等,你永远都不知道你数据的价值,以及他们可能把你的数据用在什么地方。

算法这里我提到过搜索引擎,我打算单独讲一下,因为在技术侧还算有可圈可点之处。

搜索引擎:

传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。

那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。

这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。

学习路线

以上就是整个系统所有的技术栈了,这个时候大家再看一下我开头的电商项目图大家是不是会觉得更有感觉了?是不是发现好像是那么回事,也大概知道了很多技术栈在一个系统里面的地位了?

技术路线路线图呢就用我之前的图其实就够了,不一定要严格按照这个去学习,只是给大家一个参考。

资料/学习网站

JavaFamily:由一个在互联网苟且偷生的男人维护的GitHub

B站 网址:www.bilibili.com

中国大学MOOC 网址:www.icourse163.org

IMOOC 网址:www.imooc.com

极客时间 网址:https://time.geekbang.org

极客学院 网址:www.jikexueyuan.com

网易云课堂 网址:https://study.163.com

百度/谷歌 网址:www.baidu.comwww.google.com

知乎 网址:www.zhihu.com

GitHub 网址:https://github.com

我要自学网 网址:www.51zxw.net

w3school、菜鸟教程 网址:www.w3school.com.cnwww.runoob.com

豆瓣、微信读书、当当 网址:www.douban.comhttps://weread.qq.comhttp://book.dangdang.com

CSDN 网址www.csdn.net

掘金 网址 https://juejin.im

博客园 网址:www.cnblogs.com

思否(segmentfault) 网址:https://segmentfault.com

stackoverflow 网址:https://stackoverflow.com

开源中国 网址:www.oschina.net

V2ex 网址:www.v2ex.com

infoQ 网址:www.infoq.cn

有道词典 网址:www.youdao.com

印象笔记 网址:www.yinxiang.com

有道云、石墨文档 网址:https://note.youdao.comhttps://shimo.im

ProcessOn 、xmind 网址:www.processon.comwww.xmind.cn

鸠摩搜索 网址:www.jiumodiary.com

脚本之家 网址:www.jb51.net/books

牛客网 校招 网址:www.nowcoder.com

LeetCode、lintcode 网址:https://leetcode-cn.comwww.lintcode.com

数据结构模拟 网址:www.cs.usfca.edu

BOSS、拉钩 网址:www.zhipin.comwww.lagou.com

絮叨

如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。

如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。

丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。

总结

我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。

你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。

技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。

所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。

但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去,不经一番寒彻骨,怎得梅花扑鼻香?

说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。

我是敖丙,一个在互联网苟且偷生的工具人。

创作不易,本期硬核,不想被白嫖,各位的 「三连」 就是丙丙创作的最大动力,我们下次见!

查看原文

赞 66 收藏 43 评论 3

敖丙 发布了文章 · 8月19日

浅入浅出Dubbo

前言

接下来一段时间敖丙将带大家开启紧张刺激的 Dubbo 之旅!是的要开始写 Dubbo 系列的文章了,之前我已经写过一篇架构演进的文章,也说明了微服务的普及化以及重要性,服务化场景下随之而来的就是服务之间的通信问题,那服务间的通信脑海中想到的就是 RPC,说到 RPC 就离不开咱们的 Dubbo。

这篇文章敖丙先带着大家来总览全局,一般而言熟悉一个框架你要先知道这玩意是做什么的,能解决什么痛点,核心的模块是什么,大致运转流程是怎样的。

你要一来就扎入细节之中无法自拔,一波 DFS 直接被劝退的可能性高达99.99%,所以本暖男敖丙将带大家先过一遍 Dubbo 的简介、总体分层、核心组件以及大致调用流程

不仅如此我还会带着大家过一遍如果要让你设计一个 RPC 框架你看看都需要什么功能?这波操作之后你会发现嘿嘿 Dubbo 怎么设计的和我想的一样呢?真是英雄所见略同啊!

而且我还会写一个简单版 RPC 框架实现,让大家明白 RPC 到底是如何工作的。

如果看了这篇文章你要还是不知道 Dubbo 是啥,我可以要劝退了。

我们先来谈一谈什么叫 RPC ,我发现有很多同学不太了解这个概念,还有人把 RPC 和 HTTP 来进行对比。所以咱们先来说说什么是 RPC。

什么是 RPC

RPC,Remote Procedure Call 即远程过程调用,远程过程调用其实对标的是本地过程调用,本地过程调用你熟悉吧?

想想那青葱岁月,你在大学赶着期末大作业,正在攻克图书管理系统,你奋笔疾书疯狂地敲击键盘,实现了图书借阅、图书归还等等模块,你实现的一个个方法之间的调用就叫本地过程调用。

你要是和我说你实现图书馆里系统已经用了服务化,搞了远程调用了,我只能和你说你有点东西。

简单的说本机上内部的方法调用都可以称为本地过程调用,而远程过程调用实际上就指的是你本地调用了远程机子上的某个方法,这就是远程过程调用。

所以说 RPC 对标的是本地过程调用,至于 RPC 要如何调用远程的方法可以走 HTTP、也可以是基于 TCP 自定义协议。

所以说你讨论 RPC 和 HTTP 就不是一个层级的东西。

RPC 框架就是要实现像那小助手一样的东西,目的就是让我们使用远程调用像本地调用一样简单方便,并且解决一些远程调用会发生的一些问题,使用户用的无感知、舒心、放心、顺心,它好我也好,快乐没烦恼。

如何设计一个 RPC 框架

在明确了什么是 RPC,以及 RPC 框架的目的之后,咱们想想如果让你做一款 RPC 框架你该如何设计?

服务消费者

我们先从消费者方(也就是调用方)来看需要些什么,首先消费者面向接口编程,所以需要得知有哪些接口可以调用,可以通过公用 jar 包的方式来维护接口。

现在知道有哪些接口可以调用了,但是只有接口啊,具体的实现怎么来?这事必须框架给处理了!所以还需要来个代理类,让消费者只管调,啥事都别管了,我代理帮你搞定

对了,还需要告诉代理,你调用的是哪个方法,并且参数的值是什么。

虽说代理帮你搞定但是代理也需要知道它到底要调哪个机子上的远程方法,所以需要有个注册中心,这样调用方从注册中心可以知晓可以调用哪些服务提供方,一般而言提供方不止一个,毕竟只有一个挂了那不就没了。

所以提供方一般都是集群部署,那调用方需要通过负载均衡来选择一个调用,可以通过某些策略例如同机房优先调用啊啥的。

当然还需要有容错机制,毕竟这是远程调用,网络是不可靠的,所以可能需要重试什么的。

还要和服务提供方约定一个协议,例如我们就用 HTTP 来通信就好啦,也就是大家要讲一样的话,不然可能听不懂了。

当然序列化必不可少,毕竟我们本地的结构是“立体”的,需要序列化之后才能传输,因此还需要约定序列化格式

并且这过程中间可能还需要掺入一些 Filter,来作一波统一的处理,例如调用计数啊等等。

这些都是框架需要做的,让消费者像在调用本地方法一样,无感知。

服务提供者

服务提供者肯定要实现对应的接口这是毋庸置疑的。

然后需要把自己的接口暴露出去,向注册中心注册自己,暴露自己所能提供的服务。

然后有消费者请求过来需要处理,提供者需要用和消费者协商好的协议来处理这个请求,然后做反序列化

序列化完的请求应该扔到线程池里面做处理,某个线程接受到这个请求之后找到对应的实现调用,然后再将结果原路返回

注册中心

上面其实我们都提到了注册中心,这东西就相当于一个平台,大家在上面暴露自己的服务,也在上面得知自己能调用哪些服务。

当然还能做配置中心,将配置集中化处理,动态变更通知订阅者。

监控运维

面对众多的服务,精细化的监控和方便的运维必不可少。

这点很多开发者在开发的时候察觉不到,到你真正上线开始运行维护的时候,如果没有良好的监控措施,快速的运维手段,到时候就是睁眼瞎!手足无措,等着挨批把!

那种痛苦不要问我为什么知道,我就是知道!

小结一下

让我们小结一下,大致上一个 RPC 框架需要做的就是约定要通信协议,序列化的格式、一些容错机制、负载均衡策略、监控运维和一个注册中心!

简单实现一个 RPC 框架

没错就是简单的实现,上面我们在思考如何设计一个 RPC 框架的时候想了很多,那算是生产环境使用级别的功能需求了,我们这是 Demo,目的是突出 RPC框架重点功能 - 实现远程调用

所以啥七七八八的都没,并且我用伪代码来展示,其实也就是删除了一些保护性和约束性的代码,因为看起来太多了不太直观,需要一堆 try-catch 啥的,因此我删减了一些,直击重点。

Let's Do It!

首先我们定义一个接口和一个简单实现。

`public interface AobingService {  
    String hello(String name);  

public class AobingServiceImpl implements AobingService {  
    public String hello(String name) {  
        return "Yo man Hello,I am" + name;  
    }  
}`

然后我们再来实现服务提供者暴露服务的功能。

`public class AobingRpcFramework { 
     public static void export(Object service, int port) throws Exception { 
          ServerSocket server = new ServerSocket(port);
          while(true) {
              Socket socket = server.accept();
              new Thread(new Runnable() {
                  //反序列化
                  ObjectInputStream input = new ObjectInputStream(socket.getInputStream()); 
                  String methodName = input.read(); //读取方法名
                  Class<?>[] parameterTypes = (Class<?>[]) input.readObject(); //参数类型
                  Object[] arguments = (Object[]) input.readObject(); //参数
                  Method method = service.getClass().getMethod(methodName, parameterTypes);  //找到方法
                  Object result = method.invoke(service, arguments); //调用方法
                  // 返回结果
                  ObjectOutputStream output = new ObjectOutputStream(socket.getOutputStream());
                  output.writeObject(result);
              }).start();
          }
     }
    public static <T> T refer (Class<T> interfaceClass, String host, int port) throws Exception {
       return  (T) Proxy.newProxyInstance(interfaceClass.getClassLoader(), new Class<?>[] {interfaceClass}, 
            new InvocationHandler() {  
                public Object invoke(Object proxy, Method method, Object[] arguments) throws Throwable {  
                    Socket socket = new Socket(host, port);  //指定 provider 的 ip 和端口
                    ObjectOutputStream output = new ObjectOutputStream(socket.getOutputStream()); 
                    output.write(method.getName());  //传方法名
                    output.writeObject(method.getParameterTypes());  //传参数类型
                    output.writeObject(arguments);  //传参数值
                    ObjectInputStream input = new ObjectInputStream(socket.getInputStream());  
                    Object result = input.readObject();  //读取结果
                    return result;  
               }
        });  
    }  
}
`

好了,这个 RPC 框架就这样好了,是不是很简单?就是调用者传递了方法名、参数类型和参数值,提供者接收到这样参数之后调用对于的方法返回结果就好了!这就是远程过程调用。

我们来看看如何使用

`//服务提供者只需要暴露出接口
       AobingService service = new AobingServiceImpl ();  
       AobingRpcFramework.export(service, 2333);  

       //服务调用者只需要设置依赖
       AobingService service = AobingRpcFramework.refer(AobingService.class, "127.0.0.1", 2333);  
       service.hello();`

看起来好像好不错哟,不过这很是简陋,用作 demo 有助理解还是极好的!

接下来就来看看 Dubbo 吧!上正菜!

Dubbo 简介

Dubbo 是阿里巴巴 2011年开源的一个基于 Java 的 RPC 框架,中间沉寂了一段时间,不过其他一些企业还在用 Dubbo 并自己做了扩展,比如当当网的 Dubbox,还有网易考拉的 Dubbok。

但是在 2017 年阿里巴巴又重启了对 Dubbo 维护。在 2017 年荣获了开源中国 2017 最受欢迎的中国开源软件 Top 3。

在 2018 年和 Dubbox 进行了合并,并且进入 Apache 孵化器,在 2019 年毕业正式成为 Apache 顶级项目。

目前 Dubbo 社区主力维护的是 2.6.x 和 2.7.x 两大版本,2.6.x 版本主要是 bug 修复和少量功能增强为准,是稳定版本。

而 2.7.x 是主要开发版本,更新和新增新的 feature 和优化,并且 2.7.5 版本的发布被 Dubbo 认为是里程碑式的版本发布,之后我们再做分析。

它实现了面向接口的代理 RPC 调用,并且可以配合 ZooKeeper 等组件实现服务注册和发现功能,并且拥有负载均衡、容错机制等。

Dubbo 总体架构

我们先来看下官网的一张图。

本丙再暖心的给上图内每个节点的角色说明一下。

节点

角色说明

Consumer

需要调用远程服务的服务消费方

Registry

注册中心

Provider

服务提供方

Container

服务运行的容器

Monitor

监控中心

我再来大致说一下整体的流程,首先服务提供者 Provider 启动然后向注册中心注册自己所能提供的服务。

服务消费者 Consumer 启动向注册中心订阅自己所需的服务。然后注册中心将提供者元信息通知给 Consumer, 之后 Consumer 因为已经从注册中心获取提供者的地址,因此可以通过负载均衡选择一个 Provider 直接调用

之后服务提供方元数据变更的话注册中心会把变更推送给服务消费者

服务提供者和消费者都会在内存中记录着调用的次数和时间,然后定时的发送统计数据到监控中心

一些注意点

首先注册中心和监控中心是可选的,你可以不要监控,也不要注册中心,直接在配置文件里面写然后提供方和消费方直连。

然后注册中心、提供方和消费方之间都是长连接,和监控方不是长连接,并且消费方是直接调用提供方,不经过注册中心

就算注册中心和监控中心宕机了也不会影响到已经正常运行的提供者和消费者,因为消费者有本地缓存提供者的信息。

Dubbo 分层架构

总的而言 Dubbo 分为三层,如果每一层再细分下去,一共有十层。别怕也就十层,本丙带大家过一遍,大家先有个大致的印象,之后的文章丙会带着大家再深入。

大的三层分别为 Business(业务层)、RPC 层、Remoting,并且还分为 API 层和 SPI 层。

分为大三层其实就是和我们知道的网络分层一样的意思,只有层次分明,职责边界清晰才能更好的扩展

而分 API 层和 SPI 层这是 Dubbo 成功的一点,采用微内核设计+SPI扩展,使得有特殊需求的接入方可以自定义扩展,做定制的二次开发。

接下来咱们再来看看每一层都是干嘛的。

  • Service,业务层,就是咱们开发的业务逻辑层。
  • Config,配置层,主要围绕 ServiceConfig 和 ReferenceConfig,初始化配置信息。
  • Proxy,代理层,服务提供者还是消费者都会生成一个代理类,使得服务接口透明化,代理层做远程调用和返回结果。
  • Register,注册层,封装了服务注册和发现。
  • Cluster,路由和集群容错层,负责选取具体调用的节点,处理特殊的调用要求和负责远程调用失败的容错措施。
  • Monitor,监控层,负责监控统计调用时间和次数。
  • Portocol,远程调用层,主要是封装 RPC 调用,主要负责管理 Invoker,Invoker代表一个抽象封装了的执行体,之后再做详解。
  • Exchange,信息交换层,用来封装请求响应模型,同步转异步。
  • Transport,网络传输层,抽象了网络传输的统一接口,这样用户想用 Netty 就用 Netty,想用 Mina 就用 Mina。
  • Serialize,序列化层,将数据序列化成二进制流,当然也做反序列化。

SPI

我再稍微提一下 SPI(Service Provider Interface),是 JDK 内置的一个服务发现机制,它使得接口和具体实现完全解耦。我们只声明接口,具体的实现类在配置中选择。

具体的就是你定义了一个接口,然后在META-INF/services目录下放置一个与接口同名的文本文件,文件的内容为接口的实现类,多个实现类用换行符分隔。

这样就通过配置来决定具体用哪个实现!

而 Dubbo SPI 还做了一些改进,篇幅有限留在之后再谈。

Dubbo 调用过程

上面我已经介绍了每个层到底是干嘛的,我们现在再来串起来走一遍调用的过程,加深你对 Dubbo 的理解,让知识点串起来,由点及面来一波连连看。

我们先从服务提供者开始,看看它是如何工作的。

服务暴露过程

首先 Provider 启动,通过 Proxy 组件根据具体的协议 Protocol 将需要暴露出去的接口封装成 Invoker,Invoker 是 Dubbo 一个很核心的组件,代表一个可执行体。

然后再通过 Exporter 包装一下,这是为了在注册中心暴露自己套的一层,然后将 Exporter 通过 Registry 注册到注册中心。 这就是整体服务暴露过程。

消费过程

接着我们来看消费者调用流程(把服务者暴露的过程也在图里展示出来了,这个图其实算一个挺完整的流程图了)。

首先消费者启动会向注册中心拉取服务提供者的元信息,然后调用流程也是从 Proxy 开始,毕竟都需要代理才能无感知。

Proxy 持有一个 Invoker 对象,调用 invoke 之后需要通过 Cluster 先从 Directory 获取所有可调用的远程服务的 Invoker 列表,如果配置了某些路由规则,比如某个接口只能调用某个节点的那就再过滤一遍 Invoker 列表。

剩下的 Invoker 再通过 LoadBalance 做负载均衡选取一个。然后再经过 Filter 做一些统计什么的,再通过 Client 做数据传输,比如用 Netty 来传输。

传输需要经过 Codec 接口做协议构造,再序列化。最终发往对应的服务提供者。

服务提供者接收到之后也会进行 Codec 协议处理,然后反序列化后将请求扔到线程池处理。某个线程会根据请求找到对应的 Exporter ,而找到 Exporter 其实就是找到了 Invoker,但是还会有一层层 Filter,经过一层层过滤链之后最终调用实现类然后原路返回结果。

完成整个调用过程!

总结

这次敖丙带着大家先了解了下什么是 RPC,然后规划了一波 RPC 框架需要哪些组件,然后再用代码实现了一个简单的 RPC 框架。

然后带着大家了解了下 Dubbo 的发展历史、总体架构、分层设计架构以及每个组件是干嘛的,再带着大伙走了一遍整体调用过程。

我真的是太暖了啊!

dubbo近期我会安排几个章节继续展开,最后会出一个面试版本的dubbo,我们拭目以待吧。

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 20 收藏 9 评论 0

敖丙 发布了文章 · 8月17日

阿里的秒杀系统是怎么设计的?

背景

我之前写过一个秒杀系统的文章不过有些许瑕疵,所以我准备在之前的基础上进行二次创作,不过让我决心二创秒杀系统的原因是我最近面试了很多读者,动不动就是秒杀系统把我整蒙蔽了,我懵的主要是秒杀系统的细节大家都不知道,甚至不知道电商公司一个秒杀系统的组成部分。

我之前在某电商公司就是做电商活动的,所以这样的场景和很多解决方案我是比较清楚的,那我就从我自身去带着大家看看一个秒杀的设计细节以及中间各种解决方案的利弊,以下就是我设计的秒杀系统,几乎涵盖了市面上所有秒杀的实现细节:

正文

首先设计一个系统之前,我们需要先确认我们的业务场景是怎么样子的,我就带着大家一起假设一个场景好吧。

我们现场要卖1000件下面这个婴儿纸尿裤,然后我们根据以往这样秒杀活动的数据经验来看,目测来抢这100件纸尿裤的人足足有10万人。(南极人打钱!)

你一听,完了呀,这我们的服务器哪里顶得住啊!说真的直接打DB肯定挂,但是别急嘛,有暖男敖丙在,任何系统我们开始设计之前我们都应该去思考会出现哪些问题?这里我罗列了几个非常经典的问题:

问题

高并发:

是的高并发这个是我们想都不用想的一个点,一瞬间这么多人进来这不是高并发什么时候是呢?

是吧,秒杀的特点就是这样时间极短瞬间用户量大

正常的店铺营销都是用极低的价格配合上短信、APP的精准推送,吸引特别多的用户来参与这场秒杀,爽了商家苦了开发呀

秒杀大家都知道如果真的营销到位,价格诱人,几十万的流量我觉得完全不是问题,那单机的Redis我感觉3-4W的QPS还是能顶得住的,但是再高了就没办法了,那这个数据随便搞个热销商品的秒杀可能都不止了。

大量的请求进来,我们需要考虑的点就很多了,缓存雪崩缓存击穿缓存穿透这些我之前提到的点都是有可能发生的,出现问题打挂DB那就很难受了,活动失败用户体验差,活动人气没了,最后背锅的还是开发

超卖:

但凡是个秒杀,都怕超卖,我这里举例的只是尿不湿,要是换成100个MacBook Pro,商家的预算经费卖100个可以赚点还可以造势,结果你写错程序多卖出去200个,你不发货用户投诉你,平台封你店,你发货就血亏,你怎么办? (没事看了敖丙的文章直接不怕)

那最后只能杀个开发祭天解气了,秒杀的价格本来就低了,基本上都是不怎么赚钱的,超卖了就恐怖了呀,所以超卖也是很关键的一个点。

恶意请求:

你这么低的价格,假如我抢到了,我转手卖掉我不是血赚?就算我不卖我也不亏啊,那用户知道,你知道,别的别有用心的人(黑客、黄牛...)肯定也知道的。

那简单啊,我知道你什么时候抢,我搞个几十台机器搞点脚本,我也模拟出来十几万个人左右的请求,那我是不是意味着我基本上有80%的成功率了。

真实情况可能远远不止,因为机器请求的速度比人的手速往往快太多了,在贵州的敖丙我每年回家抢高铁票都是秒光的,我也不知道有没有黄牛的功劳,我要Diss你,黄牛。杰伦演唱会门票抢不到,我也Diss你。

Tip:科普下,小道消息了解到的,黄牛的抢票系统,比国内很多小公司的系统还吊很多,架构设计都是顶级的,我用顶配的服务加上顶配的架构设计,你还想看演唱会?还想回家?

不过不用黄牛我回家都难,我们云贵川跟我一样要回家过年的仔太多了555!

链接暴露:

前面几个问题大家可能都很好理解,一看到这个有的小伙伴可能会比较疑惑,啥是链接暴露呀?

相信是个开发同学都对这个画面一点都不陌生吧,懂点行的仔都可以打开谷歌的开发者模式,然后看看你的网页代码,有的就有URL,但是我写VUE的时候是事件触发然后去调用文件里面的接口看源码看不到,但是我可以点击一下查看你的请求地址啊,不过你好像可以对按钮在秒杀前置灰。

不管怎么样子都有危险,撇开外面的所有的东西你都挡住了,你卖这个东西实在便宜得过分,有诱惑力,你能保证开发不动心?开发知道地址,在秒杀的时候自己提前请求。。。(开发:怎么TM又是我)

数据库:

每秒上万甚至十几万的QPS(每秒请求数)直接打到数据库,基本上都要把库打挂掉,而且你服务不单单是做秒杀的还涉及其他的业务,你没做降级、限流、熔断啥的,别的一起挂,小公司的话可能全站崩溃404

反正不管你秒杀怎么挂,你别把别的搞挂了对吧,搞挂了就不是杀一个程序员能搞定的。

程序员:我TM好难啊!

问题都列出来了,那怎么设计,怎么解决这些问题就是接下去要考虑的了,我们对症下药。

我会从我设计的秒杀系统从上到下去给大家介绍我们正常电商秒杀系统在每一层做了些什么,每一层存在的问题,难点等。

我们从前端开始:

前端

秒杀系统普遍都是商城网页、H5、APP、小程序这几项。

在前端这一层其实我们可以做的事情有很多,如果用node去做,甚至能直接处理掉整个秒杀,但是node其实应该属于后端,所以我不讨论node Service了。

资源静态化:

秒杀一般都是特定的商品还有页面模板,现在一般都是前后端分离的,页面一般都是不会经过后端的,但是前端也要自己的服务器啊,那就把能提前放入cdn服务器的东西都放进去,反正把所有能提升效率的步骤都做一下,减少真正秒杀时候服务器的压力。

秒杀链接加盐:

我们上面说了链接要是提前暴露出去可能有人直接访问url就提前秒杀了,那又有小伙伴要说了我做个时间的校验就好了呀,那我告诉你,知道链接的地址比起页面人工点击的还是有很大优势

我知道url了,那我通过程序不断获取最新的北京时间,可以达到毫秒级别的,我就在00毫秒的时候请求,我敢说绝对比你人工点的成功率大太多了,而且我可以一毫秒发送N次请求,搞不好你卖100个产品我全拿了。

那这种情况怎么避免?

简单,把URL动态化,就连写代码的人都不知道,你就通过MD5之类的摘要算法加密随机的字符串去做url,然后通过前端代码获取url后台校验才能通过。

这个只能防止一部分没耐心继续破解下去的黑客,有耐心的人研究出来还是能破解,在电商场景存在很多这样的羊毛党,那怎么做呢?

后面我会说。

限流:

限流这里我觉得应该分为前端限流后端限流

物理控制:

大家有没有发现没到秒杀前,一般按钮都是置灰的,只有时间到了,才能点击。

这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器,然后还没到秒杀的时候基本上服务器就挂了。

这个时候就需要前端的配合,定时去请求你的后端服务器,获取最新的北京时间,到时间点再给按钮可用状态。

按钮可以点击之后也得给他置灰几秒,不然他一样在开始之后一直点的。

你敢说你们秒杀的时候不是这样的?

前端限流:这个很简单,一般秒杀不会让你一直点的,一般都是点击一下或者两下然后几秒之后才可以继续点击,这也是保护服务器的一种手段。

后端限流:秒杀的时候肯定是涉及到后续的订单生成和支付等操作,但是都只是成功的幸运儿才会走到那一步,那一旦100个产品卖光了,return了一个false,前端直接秒杀结束,然后你后端也关闭后续无效请求的介入了。

Tip:真正的限流还会有限流组件的加入例如:阿里的Sentinel、Hystrix等。我这里就不展开了,就说一下物理的限流。

我们卖1000件商品,请求有10W,我们不需要把十万都放进来,你可以放1W请求进来,然后再进行操作,因为秒杀对于用户本身就是黑盒的,所以你怎么做的他们是没感知的,至于为啥放1W进来,而不是刚好1000,是因为会丢掉一些薅羊毛的用户,至于怎么判断,后面的风控阶段我会说。

Nginx:

Nginx大家想必都不陌生了吧,这玩意是高性能的web服务器,并发也随便顶几万不是梦,但是我们的Tomcat只能顶几百的并发呀,那简单呀负载均衡嘛,一台服务几百,那就多搞点,在秒杀的时候多租点流量机

Tip:据我所知国内某大厂就是在去年春节活动期间租光了亚洲所有的服务器,小公司也很喜欢在双十一期间买流量机来顶住压力。

这样一对比是不是觉得你的集群能顶很多了。

恶意请求拦截也需要用到它,一般单个用户请求次数太夸张,不像人为的请求在网关那一层就得拦截掉了,不然请求多了他抢不抢得到是一回事,服务器压力上去了,可能占用网络带宽或者把服务器打崩、缓存击穿等等。

风控

我可以明确的告诉大家,前面的所有措施还是拦不住很多羊毛党,因为他们是专业的团队,他们可以注册很多账号来薅你的羊毛,而且不用机器请求,就用群控,操作几乎跟真实用户一模一样。

那怎么办,是不是无解了?

这个时候就需要风控同学的介入了,在请求到达后端之前,风控可以根据账号行为分析出这个账号机器人的概率大不大,我现在负责公司的某些特殊系统,每个用户的行为都是会送到我们大数据团队进行分析处理,给你打上对应标签的。

那黑客其实也有办法:养号

他们去黑市买真实用户有过很多记录的账号,买到了还不闲着,帮他们去购物啥的,让系统无法识别他们是黑号还是真实用户的号。

怎么办?

通杀!是的没有办法,只能通杀了,通杀的意思就是,我们通过风管分析出来这个用户是真实用户的概率没有其他用户概率大,那就认为他是机器了,丢弃他的请求。

之前的限流我们放进来10000个请求,但是我们真正的库存只有1000个,那我们就算出最有可能是真实用户的1000人进行秒杀,丢弃其他请求,因为秒杀本来就是黑盒操作的,用户层面是无感知的,这样设计能让真实的用户买到东西,还可以减少自己被薅羊毛的概率。

风控可以说是流量进入的最后一道门槛了,所以很多公司的风控是很强的,蚂蚁金服的风控大家如果了解过就知道了,你的资金在支付宝被盗了,他们是能做到全款补偿是有原因的。

后端

服务单一职责:

设计个能抗住高并发的系统,我觉得还是得单一职责

什么意思呢,大家都知道现在设计都是微服务的设计思想,然后再用分布式的部署方式

也就是我们下单是有个订单服务,用户登录管理等有个用户服务等等,那为啥我们不给秒杀也开个服务,我们把秒杀的代码业务逻辑放一起。

单一职责的好处就是就算秒杀没抗住,秒杀库崩了,服务挂了,也不会影响到其他的服务。(高可用)

Redis集群:

之前不是说单机的Redis顶不住嘛,那简单多找几个兄弟啊,秒杀本来就是读多写少,那你们是不是瞬间想起来我之前跟你们提到过的,Redis集群主从同步读写分离,我们还搞点哨兵,开启持久化直接无敌高可用!

库存预热:

秒杀的本质,就是对库存的抢夺,每个秒杀的用户来你都去数据库查询库存校验库存,然后扣减库存,撇开性能因数,你不觉得这样好繁琐,对业务开发人员都不友好,而且数据库顶不住啊。

开发:你tm总算为我着想一次了。

那怎么办?

我们都知道数据库顶不住但是他的兄弟非关系型的数据库Redis能顶啊!

那不简单了,我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去,让整个流程都在Redis里面去做,然后等秒杀介绍了,再异步的去修改库存就好了。

但是用了Redis就有一个问题了,我们上面说了我们采用主从,就是我们会去读取库存然后再判断然后有库存才去减库存,正常情况没问题,但是高并发的情况问题就很大了。

**多品几遍!!!**就比如现在库存只剩下1个了,我们高并发嘛,4个服务器一起查询了发现都是还有1个,那大家都觉得是自己抢到了,就都去扣库存,那结果就变成了-3,是的只有一个是真的抢到了,别的都是超卖的。咋办?

事务:

Redis本身是支持事务的,而且他有很多原子命令的,大家也可以用LUA,还可以用他的管道,乐观锁他也知支持。

限流&降级&熔断&隔离:

这个为啥要做呢,不怕一万就怕万一,万一你真的顶不住了,限流,顶不住就挡一部分出去但是不能说不行,降级,降级了还是被打挂了,熔断,至少不要影响别的系统,隔离,你本身就独立的,但是你会调用其他的系统嘛,你快不行了你别拖累兄弟们啊。

消息队列(削峰填谷):

一说到这个名词,很多小伙伴就知道了,对的MQ,你买东西少了你直接100个请求改库我觉得没问题,但是万一秒杀一万个,10万个呢?服务器挂了,程序员又要背锅的

秒杀就是这种瞬间流量很高,但是平时又没有流量的场景,那消息队列完全契合这样的场景了呀,削峰填谷。

Tip:可能小伙伴说我们业务达不到这个量级,没必要。但是我想说我们写代码,就不应该写出有逻辑漏洞的代码,至少以后公司体量上去了,别人一看居然不用改代码,一看代码作者是敖丙?有点东西!

你可以把它放消息队列,然后一点点消费去改库存就好了嘛,不过单个商品其实一次修改就够了,我这里说的是某个点多个商品一起秒杀的场景,像极了双十一零点。

数据库

数据库用MySQL只要连接池设置合理一般问题是不大的,不过一般大公司不缺钱而且秒杀这样的活动十分频繁,我之前所在的公司就是这样秒杀特卖这样的场景一直都是不间断的。

单独给秒杀建立一个数据库,为秒杀服务,表的设计也是竟可能的简单点,现在的互联网架构部署都是分库的。

至于表就看大家怎么设计了,该设置索引的地方还是要设置索引的,建完后记得用explain看看SQL的执行计划。(不了解的小伙伴也没事,MySQL章节去康康)

分布式事务

这为啥我不放在后端而放到最后来讲呢?

因为上面的任何一步都是可能出错的,而且我们是在不同的服务里面出错的,那就涉及分布式事务了,但是分布式事务大家想的是一定要成功什么的那就不对了,还是那句话,几个请求丢了就丢了,要保证时效和服务的可用可靠。

所以TCC最终一致性其实不是很适合,TCC开发成本很大,所有接口都要写三次,因为涉及TCC的三个阶段。

最终一致性基本上都是靠轮训的操作去保证一个操作一定成功,那时效性就大打折扣了。

大家觉得不那么可靠的**两段式(2PC)三段式(3PC)**就派上用场了,他们不一定能保证数据最终一致,但是效率上还算ok。

总结

到这里我想我已经基本上把该考虑的点还有对应的解决方案也都说了一下,不知道还有没有没考虑到的,但是就算没考虑到我想我这个设计,应该也能撑住一个完整的秒杀流程。

最后大家再看看这个秒杀系统或许会有新的感悟,是不是一个系统真的没有大家想的那么简单,而且我还是有漏掉的细节,这是一定的。

秒杀这章我脑细胞死了很多,考虑了很多个点,最后还是出来了,忍不住给自己点赞

总结

我们玩归玩,闹归闹,别拿面试开玩笑。

秒杀不一定是每个同学都会问到的,至少肯定没Redis基础那样常问,但是一旦问到,大家一定要回答到点上。

至少你得说出可能出现的情况需要注意的情况,以及对于的解决思路和方案,因为这才是一个coder的基本素养,这些你不考虑你也很难去进步。

最后就是需要对整个链路比较熟悉,注意是一个完整的链路,前端怎么设计的呀,网关的作用呀,怎么解决Redis的并发竞争啊,数据的同步方式呀,MQ的作用啊等等,相信你会有不错的收获。

不知道这是一次成功还是失败的二创,我里面所有提到的技术细节我都写了对应的文章,大家可以关注我去历史文章看看,天色已晚,我溜了。

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 109 收藏 79 评论 2

敖丙 发布了文章 · 8月6日

秒杀系统设计

背景

我之前写过一个秒杀系统的文章不过有些许瑕疵,所以我准备在之前的基础上进行二次创作,不过让我决心二创秒杀系统的原因是我最近面试了很多读者,动不动就是秒杀系统把我整蒙蔽了,我懵的主要是秒杀系统的细节大家都不知道,甚至不知道电商公司一个秒杀系统的组成部分。

我之前在某电商公司就是做电商活动的,所以这样的场景和很多解决方案我是比较清楚的,那我就从我自身去带着大家看看一个秒杀的设计细节以及中间各种解决方案的利弊,以下就是我设计的秒杀系统,几乎涵盖了市面上所有秒杀的实现细节:

正文

首先设计一个系统之前,我们需要先确认我们的业务场景是怎么样子的,我就带着大家一起假设一个场景好吧。

我们现场要卖1000件下面这个婴儿纸尿裤,然后我们根据以往这样秒杀活动的数据经验来看,目测来抢这100件纸尿裤的人足足有10万人。(南极人打钱!)

你一听,完了呀,这我们的服务器哪里顶得住啊!说真的直接打DB肯定挂,但是别急嘛,有暖男敖丙在,任何系统我们开始设计之前我们都应该去思考会出现哪些问题?这里我罗列了几个非常经典的问题:

问题

高并发:

是的高并发这个是我们想都不用想的一个点,一瞬间这么多人进来这不是高并发什么时候是呢?

是吧,秒杀的特点就是这样时间极短瞬间用户量大

正常的店铺营销都是用极低的价格配合上短信、APP的精准推送,吸引特别多的用户来参与这场秒杀,爽了商家苦了开发呀

秒杀大家都知道如果真的营销到位,价格诱人,几十万的流量我觉得完全不是问题,那单机的Redis我感觉3-4W的QPS还是能顶得住的,但是再高了就没办法了,那这个数据随便搞个热销商品的秒杀可能都不止了。

大量的请求进来,我们需要考虑的点就很多了,缓存雪崩缓存击穿缓存穿透这些我之前提到的点都是有可能发生的,出现问题打挂DB那就很难受了,活动失败用户体验差,活动人气没了,最后背锅的还是开发

超卖:

但凡是个秒杀,都怕超卖,我这里举例的只是尿不湿,要是换成100个MacBook Pro,商家的预算经费卖100个可以赚点还可以造势,结果你写错程序多卖出去200个,你不发货用户投诉你,平台封你店,你发货就血亏,你怎么办? (没事看了敖丙的文章直接不怕)

那最后只能杀个开发祭天解气了,秒杀的价格本来就低了,基本上都是不怎么赚钱的,超卖了就恐怖了呀,所以超卖也是很关键的一个点。

恶意请求:

你这么低的价格,假如我抢到了,我转手卖掉我不是血赚?就算我不卖我也不亏啊,那用户知道,你知道,别的别有用心的人(黑客、黄牛...)肯定也知道的。

那简单啊,我知道你什么时候抢,我搞个几十台机器搞点脚本,我也模拟出来十几万个人左右的请求,那我是不是意味着我基本上有80%的成功率了。

真实情况可能远远不止,因为机器请求的速度比人的手速往往快太多了,在贵州的敖丙我每年回家抢高铁票都是秒光的,我也不知道有没有黄牛的功劳,我要Diss你,黄牛。杰伦演唱会门票抢不到,我也Diss你。

Tip:科普下,小道消息了解到的,黄牛的抢票系统,比国内很多小公司的系统还吊很多,架构设计都是顶级的,我用顶配的服务加上顶配的架构设计,你还想看演唱会?还想回家?

不过不用黄牛我回家都难,我们云贵川跟我一样要回家过年的仔太多了555!

链接暴露:

前面几个问题大家可能都很好理解,一看到这个有的小伙伴可能会比较疑惑,啥是链接暴露呀?

相信是个开发同学都对这个画面一点都不陌生吧,懂点行的仔都可以打开谷歌的开发者模式,然后看看你的网页代码,有的就有URL,但是我写VUE的时候是事件触发然后去调用文件里面的接口看源码看不到,但是我可以点击一下查看你的请求地址啊,不过你好像可以对按钮在秒杀前置灰。

不管怎么样子都有危险,撇开外面的所有的东西你都挡住了,你卖这个东西实在便宜得过分,有诱惑力,你能保证开发不动心?开发知道地址,在秒杀的时候自己提前请求。。。(开发:怎么TM又是我)

数据库:

每秒上万甚至十几万的QPS(每秒请求数)直接打到数据库,基本上都要把库打挂掉,而且你服务不单单是做秒杀的还涉及其他的业务,你没做降级、限流、熔断啥的,别的一起挂,小公司的话可能全站崩溃404

反正不管你秒杀怎么挂,你别把别的搞挂了对吧,搞挂了就不是杀一个程序员能搞定的。

程序员:我TM好难啊!

问题都列出来了,那怎么设计,怎么解决这些问题就是接下去要考虑的了,我们对症下药。

我会从我设计的秒杀系统从上到下去给大家介绍我们正常电商秒杀系统在每一层做了些什么,每一层存在的问题,难点等。

我们从前端开始:

前端

秒杀系统普遍都是商城网页、H5、APP、小程序这几项。

在前端这一层其实我们可以做的事情有很多,如果用node去做,甚至能直接处理掉整个秒杀,但是node其实应该属于后端,所以我不讨论node Service了。

资源静态化:

秒杀一般都是特定的商品还有页面模板,现在一般都是前后端分离的,页面一般都是不会经过后端的,但是前端也要自己的服务器啊,那就把能提前放入cdn服务器的东西都放进去,反正把所有能提升效率的步骤都做一下,减少真正秒杀时候服务器的压力。

秒杀链接加盐:

我们上面说了链接要是提前暴露出去可能有人直接访问url就提前秒杀了,那又有小伙伴要说了我做个时间的校验就好了呀,那我告诉你,知道链接的地址比起页面人工点击的还是有很大优势

我知道url了,那我通过程序不断获取最新的北京时间,可以达到毫秒级别的,我就在00毫秒的时候请求,我敢说绝对比你人工点的成功率大太多了,而且我可以一毫秒发送N次请求,搞不好你卖100个产品我全拿了。

那这种情况怎么避免?

简单,把URL动态化,就连写代码的人都不知道,你就通过MD5之类的摘要算法加密随机的字符串去做url,然后通过前端代码获取url后台校验才能通过。

这个只能防止一部分没耐心继续破解下去的黑客,有耐心的人研究出来还是能破解,在电商场景存在很多这样的羊毛党,那怎么做呢?

后面我会说。

限流:

限流这里我觉得应该分为前端限流后端限流

物理控制:

大家有没有发现没到秒杀前,一般按钮都是置灰的,只有时间到了,才能点击。

这是因为怕大家在时间快到的最后几秒秒疯狂请求服务器,然后还没到秒杀的时候基本上服务器就挂了。

这个时候就需要前端的配合,定时去请求你的后端服务器,获取最新的北京时间,到时间点再给按钮可用状态。

按钮可以点击之后也得给他置灰几秒,不然他一样在开始之后一直点的。

你敢说你们秒杀的时候不是这样的?

前端限流:这个很简单,一般秒杀不会让你一直点的,一般都是点击一下或者两下然后几秒之后才可以继续点击,这也是保护服务器的一种手段。

后端限流:秒杀的时候肯定是涉及到后续的订单生成和支付等操作,但是都只是成功的幸运儿才会走到那一步,那一旦100个产品卖光了,return了一个false,前端直接秒杀结束,然后你后端也关闭后续无效请求的介入了。

Tip:真正的限流还会有限流组件的加入例如:阿里的Sentinel、Hystrix等。我这里就不展开了,就说一下物理的限流。

我们卖1000件商品,请求有10W,我们不需要把十万都放进来,你可以放1W请求进来,然后再进行操作,因为秒杀对于用户本身就是黑盒的,所以你怎么做的他们是没感知的,至于为啥放1W进来,而不是刚好1000,是因为会丢掉一些薅羊毛的用户,至于怎么判断,后面的风控阶段我会说。

Nginx:

Nginx大家想必都不陌生了吧,这玩意是高性能的web服务器,并发也随便顶几万不是梦,但是我们的Tomcat只能顶几百的并发呀,那简单呀负载均衡嘛,一台服务几百,那就多搞点,在秒杀的时候多租点流量机

Tip:据我所知国内某大厂就是在去年春节活动期间租光了亚洲所有的服务器,小公司也很喜欢在双十一期间买流量机来顶住压力。

这样一对比是不是觉得你的集群能顶很多了。

恶意请求拦截也需要用到它,一般单个用户请求次数太夸张,不像人为的请求在网关那一层就得拦截掉了,不然请求多了他抢不抢得到是一回事,服务器压力上去了,可能占用网络带宽或者把服务器打崩、缓存击穿等等。

风控

我可以明确的告诉大家,前面的所有措施还是拦不住很多羊毛党,因为他们是专业的团队,他们可以注册很多账号来薅你的羊毛,而且不用机器请求,就用群控,操作几乎跟真实用户一模一样。

那怎么办,是不是无解了?

这个时候就需要风控同学的介入了,在请求到达后端之前,风控可以根据账号行为分析出这个账号机器人的概率大不大,我现在负责公司的某些特殊系统,每个用户的行为都是会送到我们大数据团队进行分析处理,给你打上对应标签的。

那黑客其实也有办法:养号

他们去黑市买真实用户有过很多记录的账号,买到了还不闲着,帮他们去购物啥的,让系统无法识别他们是黑号还是真实用户的号。

怎么办?

通杀!是的没有办法,只能通杀了,通杀的意思就是,我们通过风管分析出来这个用户是真实用户的概率没有其他用户概率大,那就认为他是机器了,丢弃他的请求。

之前的限流我们放进来10000个请求,但是我们真正的库存只有1000个,那我们就算出最有可能是真实用户的1000人进行秒杀,丢弃其他请求,因为秒杀本来就是黑盒操作的,用户层面是无感知的,这样设计能让真实的用户买到东西,还可以减少自己被薅羊毛的概率。

风控可以说是流量进入的最后一道门槛了,所以很多公司的风控是很强的,蚂蚁金服的风控大家如果了解过就知道了,你的资金在支付宝被盗了,他们是能做到全款补偿是有原因的。

后端

服务单一职责:

设计个能抗住高并发的系统,我觉得还是得单一职责

什么意思呢,大家都知道现在设计都是微服务的设计思想,然后再用分布式的部署方式

也就是我们下单是有个订单服务,用户登录管理等有个用户服务等等,那为啥我们不给秒杀也开个服务,我们把秒杀的代码业务逻辑放一起。

单一职责的好处就是就算秒杀没抗住,秒杀库崩了,服务挂了,也不会影响到其他的服务。(高可用)

Redis集群:

之前不是说单机的Redis顶不住嘛,那简单多找几个兄弟啊,秒杀本来就是读多写少,那你们是不是瞬间想起来我之前跟你们提到过的,Redis集群主从同步读写分离,我们还搞点哨兵,开启持久化直接无敌高可用!

库存预热:

秒杀的本质,就是对库存的抢夺,每个秒杀的用户来你都去数据库查询库存校验库存,然后扣减库存,撇开性能因数,你不觉得这样好繁琐,对业务开发人员都不友好,而且数据库顶不住啊。

开发:你tm总算为我着想一次了。

那怎么办?

我们都知道数据库顶不住但是他的兄弟非关系型的数据库Redis能顶啊!

那不简单了,我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去,让整个流程都在Redis里面去做,然后等秒杀介绍了,再异步的去修改库存就好了。

但是用了Redis就有一个问题了,我们上面说了我们采用主从,就是我们会去读取库存然后再判断然后有库存才去减库存,正常情况没问题,但是高并发的情况问题就很大了。

**多品几遍!!!**就比如现在库存只剩下1个了,我们高并发嘛,4个服务器一起查询了发现都是还有1个,那大家都觉得是自己抢到了,就都去扣库存,那结果就变成了-3,是的只有一个是真的抢到了,别的都是超卖的。咋办?

事务:

Redis本身是支持事务的,而且他有很多原子命令的,大家也可以用LUA,还可以用他的管道,乐观锁他也知支持。

限流&降级&熔断&隔离:

这个为啥要做呢,不怕一万就怕万一,万一你真的顶不住了,限流,顶不住就挡一部分出去但是不能说不行,降级,降级了还是被打挂了,熔断,至少不要影响别的系统,隔离,你本身就独立的,但是你会调用其他的系统嘛,你快不行了你别拖累兄弟们啊。

消息队列(削峰填谷):

一说到这个名词,很多小伙伴就知道了,对的MQ,你买东西少了你直接100个请求改库我觉得没问题,但是万一秒杀一万个,10万个呢?服务器挂了,程序员又要背锅的

秒杀就是这种瞬间流量很高,但是平时又没有流量的场景,那消息队列完全契合这样的场景了呀,削峰填谷。

Tip:可能小伙伴说我们业务达不到这个量级,没必要。但是我想说我们写代码,就不应该写出有逻辑漏洞的代码,至少以后公司体量上去了,别人一看居然不用改代码,一看代码作者是敖丙?有点东西!

你可以把它放消息队列,然后一点点消费去改库存就好了嘛,不过单个商品其实一次修改就够了,我这里说的是某个点多个商品一起秒杀的场景,像极了双十一零点。

数据库

数据库用MySQL只要连接池设置合理一般问题是不大的,不过一般大公司不缺钱而且秒杀这样的活动十分频繁,我之前所在的公司就是这样秒杀特卖这样的场景一直都是不间断的。

单独给秒杀建立一个数据库,为秒杀服务,表的设计也是竟可能的简单点,现在的互联网架构部署都是分库的。

至于表就看大家怎么设计了,该设置索引的地方还是要设置索引的,建完后记得用explain看看SQL的执行计划。(不了解的小伙伴也没事,MySQL章节去康康)

分布式事务

这为啥我不放在后端而放到最后来讲呢?

因为上面的任何一步都是可能出错的,而且我们是在不同的服务里面出错的,那就涉及分布式事务了,但是分布式事务大家想的是一定要成功什么的那就不对了,还是那句话,几个请求丢了就丢了,要保证时效和服务的可用可靠。

所以TCC最终一致性其实不是很适合,TCC开发成本很大,所有接口都要写三次,因为涉及TCC的三个阶段。

最终一致性基本上都是靠轮训的操作去保证一个操作一定成功,那时效性就大打折扣了。

大家觉得不那么可靠的**两段式(2PC)三段式(3PC)**就派上用场了,他们不一定能保证数据最终一致,但是效率上还算ok。

总结

到这里我想我已经基本上把该考虑的点还有对应的解决方案也都说了一下,不知道还有没有没考虑到的,但是就算没考虑到我想我这个设计,应该也能撑住一个完整的秒杀流程。

最后大家再看看这个秒杀系统或许会有新的感悟,是不是一个系统真的没有大家想的那么简单,而且我还是有漏掉的细节,这是一定的。

秒杀这章我脑细胞死了很多,考虑了很多个点,最后还是出来了,忍不住给自己点赞

总结

我们玩归玩,闹归闹,别拿面试开玩笑。

秒杀不一定是每个同学都会问到的,至少肯定没Redis基础那样常问,但是一旦问到,大家一定要回答到点上。

至少你得说出可能出现的情况需要注意的情况,以及对于的解决思路和方案,因为这才是一个coder的基本素养,这些你不考虑你也很难去进步。

最后就是需要对整个链路比较熟悉,注意是一个完整的链路,前端怎么设计的呀,网关的作用呀,怎么解决Redis的并发竞争啊,数据的同步方式呀,MQ的作用啊等等,相信你会有不错的收获。

不知道这是一次成功还是失败的二创,我里面所有提到的技术细节我都写了对应的文章,大家可以关注我去历史文章看看,天色已晚,我溜了。

查看原文

赞 98 收藏 57 评论 9

敖丙 发布了文章 · 7月27日

Java面试必问:ThreadLocal终极篇 淦!

开场白

张三最近天气很热心情不是很好,所以他决定出去面试跟面试官聊聊天排解一下,结果刚投递简历就有人约了面试。

我丢,什么情况怎么刚投递出去就有人约我面试了?诶。。。真烦啊,哥已经不在江湖这么久了,江湖还是有哥的传说,我还是这么抢手的么?太烦恼了,帅无罪。

暗自窃喜的张三来到了某东现场面试的办公室,我丢,这面试官?不是吧,这满是划痕的Mac,这发量,难道就是传说中的架构师?

张三的心态一下子就崩了,出来第一场面试就遇到一个顶级面试官,这谁顶得住啊。

你好,我是你的面试官Tony,看我的发型应该你能猜到我的身份了,我也话不说,我们直接开始好不好?看你简历写了多线程,来你跟我聊一下ThreadLocal吧,我很久没写代码不太熟悉了,你帮我回忆一下。

我丢?这TM是人话?这是什么逻辑啊,说是问多线程然后一上来就来个这么冷门的ThreadLocal?心态崩了呀,再说你TM自己忘了不知道下去看看书么,来我这里找答案是什么鬼啊...

尽管十分不情愿,但是张三还是高速运转他的小脑袋,回忆起了ThreadLocal的种种细节...

面试官说实话我在实际开发过程中用到ThreadLocal的地方不是很多,我在写这个文章的时候还刻意去把我电脑上几十个项目打开之后去全局搜索ThreadLocal发现除了系统源码的使用,很少在项目中用到,不过也还是有的。

ThreadLocal的作用主要是做数据隔离,填充的数据只属于当前线程,变量的数据对别的线程而言是相对隔离的,在多线程环境下,如何防止自己的变量被其它线程篡改。

你能跟我说说它隔离有什么用,会用在什么场景么?

这,我都说了我很少用了,还问我,难受了呀,哦哦哦,有了想起来了,事务隔离级别。

面试官你好,其实我第一时间想到的就是Spring实现事务隔离级别的源码,这还是当时我大学被女朋友甩了,一个人在图书馆哭泣的时候无意间发现的。

Spring采用Threadlocal的方式,来保证单个线程中的数据库操作使用的是同一个数据库连接,同时,采用这种方式可以使业务层使用事务时不需要感知并管理connection对象,通过传播级别,巧妙地管理多个事务配置之间的切换,挂起和恢复。

Spring框架里面就是用的ThreadLocal来实现这种隔离,主要是在TransactionSynchronizationManager这个类里面,代码如下所示:

private static final Log logger = LogFactory.getLog(TransactionSynchronizationManager.class);

    private static final ThreadLocal<Map<Object, Object>> resources =
            new NamedThreadLocal<>("Transactional resources");

    private static final ThreadLocal<Set<TransactionSynchronization>> synchronizations =
            new NamedThreadLocal<>("Transaction synchronizations");

    private static final ThreadLocal<String> currentTransactionName =
            new NamedThreadLocal<>("Current transaction name");

  ……

Spring的事务主要是ThreadLocal和AOP去做实现的,我这里提一下,大家知道每个线程自己的链接是靠ThreadLocal保存的就好了,继续的细节我会在Spring章节细说的,暖么?

除了源码里面使用到ThreadLocal的场景,你自己有使用他的场景么?一般你会怎么用呢?

来了来了,加分项来了,这个我还真遇到过,装B的机会终于来了。

有的有的面试官,这个我会!!!

之前我们上线后发现部分用户的日期居然不对了,排查下来是SimpleDataFormat的锅,当时我们使用SimpleDataFormat的parse()方法,内部有一个Calendar对象,调用SimpleDataFormat的parse()方法会先调用Calendar.clear(),然后调用Calendar.add(),如果一个线程先调用了add()然后另一个线程又调用了clear(),这时候parse()方法解析的时间就不对了。

其实要解决这个问题很简单,让每个线程都new 一个自己的 SimpleDataFormat就好了,但是1000个线程难道new1000个SimpleDataFormat

所以当时我们使用了线程池加上ThreadLocal包装SimpleDataFormat,再调用initialValue让每个线程有一个SimpleDataFormat的副本,从而解决了线程安全的问题,也提高了性能。

那……

还有还有,我还有,您别着急问下一个,让我再加点分,拖延一下面试时间。

我在项目中存在一个线程经常遇到横跨若干方法调用,需要传递的对象,也就是上下文(Context),它是一种状态,经常就是是用户身份、任务信息等,就会存在过渡传参的问题。

使用到类似责任链模式,给每个方法增加一个context参数非常麻烦,而且有些时候,如果调用链有无法修改源码的第三方库,对象参数就传不进去了,所以我使用到了ThreadLocal去做了一下改造,这样只需要在调用前在ThreadLocal中设置参数,其他地方get一下就好了。

before
  
void work(User user) {
    getInfo(user);
    checkInfo(user);
    setSomeThing(user);
    log(user);
}

then
  
void work(User user) {
try{
      threadLocalUser.set(user);
      // 他们内部  User u = threadLocalUser.get(); 就好了
    getInfo();
    checkInfo();
    setSomeThing();
    log();
    } finally {
     threadLocalUser.remove();
    }
}

我看了一下很多场景的cookie,session等数据隔离都是通过ThreadLocal去做实现的。

对了我面试官允许我再秀一下知识广度,在Android中,Looper类就是利用了ThreadLocal的特性,保证每个线程只存在一个Looper对象。

static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}

面试官:我丢,这货怎么知道这么多场景?还把Android都扯了出来,不是吧阿sir,下面我要考考他原理了。

嗯嗯,你回答得很好,那你能跟我说说他底层实现的原理么?

好的面试官,我先说一下他的使用:

ThreadLocal<String> localName = new ThreadLocal();
localName.set("张三");
String name = localName.get();
localName.remove();

其实使用真的很简单,线程进来之后初始化一个可以泛型的ThreadLocal对象,之后这个线程只要在remove之前去get,都能拿到之前set的值,注意这里我说的是remove之前。

他是能做到线程间数据隔离的,所以别的线程使用get()方法是没办法拿到其他线程的值的,但是有办法可以做到,我后面会说。

我们先看看他set的源码:

public void set(T value) {
    Thread t = Thread.currentThread();// 获取当前线程
    ThreadLocalMap map = getMap(t);// 获取ThreadLocalMap对象
    if (map != null) // 校验对象是否为空
        map.set(this, value); // 不为空set
    else
        createMap(t, value); // 为空创建一个map对象
}

大家可以发现set的源码很简单,主要就是ThreadLocalMap我们需要关注一下,而ThreadLocalMap呢是当前线程Thread一个叫threadLocals的变量中获取的。

ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }
public class Thread implements Runnable {
      ……

    /* ThreadLocal values pertaining to this thread. This map is maintained
     * by the ThreadLocal class. */
    ThreadLocal.ThreadLocalMap threadLocals = null;

    /*
     * InheritableThreadLocal values pertaining to this thread. This map is
     * maintained by the InheritableThreadLocal class.
     */
    ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;
  
     ……

这里我们基本上可以找到ThreadLocal数据隔离的真相了,每个线程Thread都维护了自己的threadLocals变量,所以在每个线程创建ThreadLocal的时候,实际上数据是存在自己线程Thread的threadLocals变量里面的,别人没办法拿到,从而实现了隔离。

ThreadLocalMap底层结构是怎么样子的呢?

面试官这个问题问得好啊,内心暗骂,让我歇一会不行么?

张三笑着回答道,既然有个Map那他的数据结构其实是很像HashMap的,但是看源码可以发现,它并未实现Map接口,而且他的Entry是继承WeakReference(弱引用)的,也没有看到HashMap中的next,所以不存在链表了。

static class ThreadLocalMap {

        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
        ……
    }    

结构大概长这样:

稍等,我有两个疑问你可以解答一下么?

好呀,面试官你说。

为什么需要数组呢?没有了链表怎么解决Hash冲突呢?

用数组是因为,我们开发过程中可以一个线程可以有多个TreadLocal来存放不同类型的对象的,但是他们都将放到你当前线程的ThreadLocalMap里,所以肯定要数组来存。

至于Hash冲突,我们先看一下源码:

private void set(ThreadLocal<?> key, Object value) {
           Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);
            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal<?> k = e.get();

                if (k == key) {
                    e.value = value;
                    return;
                }
                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }
            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

我从源码里面看到ThreadLocalMap在存储的时候会给每一个ThreadLocal对象一个threadLocalHashCode,在插入过程中,根据ThreadLocal对象的hash值,定位到table中的位置i,int i = key.threadLocalHashCode & (len-1)

然后会判断一下:如果当前位置是空的,就初始化一个Entry对象放在位置i上;

if (k == null) {
    replaceStaleEntry(key, value, i);
    return;
}

如果位置i不为空,如果这个Entry对象的key正好是即将设置的key,那么就刷新Entry中的value;

if (k == key) {
    e.value = value;
    return;
}

如果位置i的不为空,而且key不等于entry,那就找下一个空位置,直到为空为止。

这样的话,在get的时候,也会根据ThreadLocal对象的hash值,定位到table中的位置,然后判断该位置Entry对象中的key是否和get的key一致,如果不一致,就判断下一个位置,set和get如果冲突严重的话,效率还是很低的。

以下是get的源码,是不是就感觉很好懂了:

 private Entry getEntry(ThreadLocal<?> key) {
            int i = key.threadLocalHashCode & (table.length - 1);
            Entry e = table[i];
            if (e != null && e.get() == key)
                return e;
            else
                return getEntryAfterMiss(key, i, e);
        }

 private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
            Entry[] tab = table;
            int len = tab.length;
// get的时候一样是根据ThreadLocal获取到table的i值,然后查找数据拿到后会对比key是否相等  if (e != null && e.get() == key)。
            while (e != null) {
                ThreadLocal<?> k = e.get();
              // 相等就直接返回,不相等就继续查找,找到相等位置。
                if (k == key)
                    return e;
                if (k == null)
                    expungeStaleEntry(i);
                else
                    i = nextIndex(i, len);
                e = tab[i];
            }
            return null;
        }

能跟我说一下对象存放在哪里么?

在Java中,栈内存归属于单个线程,每个线程都会有一个栈内存,其存储的变量只能在其所属线程中可见,即栈内存可以理解成线程的私有内存,而堆内存中的对象对所有线程可见,堆内存中的对象可以被所有线程访问。

那么是不是说ThreadLocal的实例以及其值存放在栈上呢?

其实不是的,因为ThreadLocal实例实际上也是被其创建的类持有(更顶端应该是被线程持有),而ThreadLocal的值其实也是被线程实例持有,它们都是位于堆上,只是通过一些技巧将可见性修改成了线程可见。

如果我想共享线程的ThreadLocal数据怎么办?

使用InheritableThreadLocal可以实现多个线程访问ThreadLocal的值,我们在主线程中创建一个InheritableThreadLocal的实例,然后在子线程中得到这个InheritableThreadLocal实例设置的值。

private void test() {    
final ThreadLocal threadLocal = new InheritableThreadLocal();       
threadLocal.set("帅得一匹");    
Thread t = new Thread() {        
    @Override        
    public void run() {            
      super.run();            
      Log.i( "张三帅么 =" + threadLocal.get());        
    }    
  };          
  t.start(); 
} 

在子线程中我是能够正常输出那一行日志的,这也是我之前面试视频提到过的父子线程数据传递的问题。

怎么传递的呀?

传递的逻辑很简单,我在开头Thread代码提到threadLocals的时候,你们再往下看看我刻意放了另外一个变量:

Thread源码中,我们看看Thread.init初始化创建的时候做了什么:

public class Thread implements Runnable {
  ……
   if (inheritThreadLocals && parent.inheritableThreadLocals != null)
      this.inheritableThreadLocals=ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);
  ……
}

我就截取了部分代码,如果线程的inheritThreadLocals变量不为空,比如我们上面的例子,而且父线程的inheritThreadLocals也存在,那么我就把父线程的inheritThreadLocals给当前线程的inheritThreadLocals

是不是很有意思?

小伙子你懂的确实很多,那你算是一个深度的ThreadLocal用户了,你发现ThreadLocal的问题了么?

你是说内存泄露么?

我丢,这小子为啥知道我要问什么?嗯嗯对的,你说一下。

这个问题确实会存在的,我跟大家说一下为什么,还记得我上面的代码么?

ThreadLocal在保存的时候会把自己当做Key存在ThreadLocalMap中,正常情况应该是key和value都应该被外界强引用才对,但是现在key被设计成WeakReference弱引用了。

我先给大家介绍一下弱引用:

只具有弱引用的对象拥有更短暂的生命周期,在垃圾回收器线程扫描它所管辖的内存区域的过程中,一旦发现了只具有弱引用的对象,不管当前内存空间足够与否,都会回收它的内存。

不过,由于垃圾回收器是一个优先级很低的线程,因此不一定会很快发现那些只具有弱引用的对象。

这就导致了一个问题,ThreadLocal在没有外部强引用时,发生GC时会被回收,如果创建ThreadLocal的线程一直持续运行,那么这个Entry对象中的value就有可能一直得不到回收,发生内存泄露。

就比如线程池里面的线程,线程都是复用的,那么之前的线程实例处理完之后,出于复用的目的线程依然存活,所以,ThreadLocal设定的value值被持有,导致内存泄露。

按照道理一个线程使用完,ThreadLocalMap是应该要被清空的,但是现在线程被复用了。

那怎么解决?

在代码的最后使用remove就好了,我们只要记得在使用的最后用remove把值清空就好了。

ThreadLocal<String> localName = new ThreadLocal();
try {
    localName.set("张三");
    ……
} finally {
    localName.remove();
}

remove的源码很简单,找到对应的值全部置空,这样在垃圾回收器回收的时候,会自动把他们回收掉。

那为什么ThreadLocalMap的key要设计成弱引用?

key不设置成弱引用的话就会造成和entry中value一样内存泄漏的场景。

补充一点:ThreadLocal的不足,我觉得可以通过看看netty的fastThreadLocal来弥补,大家有兴趣可以康康。

好了,你不仅把我问的都回答了,我不知道的你甚至都说了,ThreadLocal你过关了,不过JUC的面试才刚刚开始,希望你以后越战越勇,最后拿个好offer哟。

什么鬼,突然这么煽情,不是很为难我的么?难道是为了锻炼我?难为大师这样为我着想,我还一直心里暗骂他,不说了回去好好学了。

总结

其实ThreadLocal用法很简单,里面的方法就那几个,算上注释源码都没多少行,我用了十多分钟就过了一遍了,但是在我深挖每一个方法背后逻辑的时候,也让我不得不感慨Josh Bloch 和 Doug Lea的厉害之处。

在细节设计的处理其实往往就是我们和大神的区别,我认为很多不合理的点,在Google和自己不断深入了解之后才发现这才是合理,真的不服不行。

ThreadLocal是多线程里面比较冷门的一个类,使用频率比不上别的方法和类,但是通过我这篇文章,不知道你是否有新的认知呢?

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 31 收藏 19 评论 5

敖丙 发布了文章 · 7月22日

我入职腾讯啦

蚂蚁金服上市的消息我想已经席卷了大家的朋友圈了,我也第一时间慰问了我所有蚂蚁的朋友,有期权的小伙伴都在估算自己变现后数字了,确实有很多老阿里人有财富自由的机会了,也有P7以下没期权苦恼的小伙伴。

我身边其实有很多偏高层的朋友,但是他们最多也就是年薪百万,还没到财富自由的地步,那我去哪里找财富自由的大佬呢?

我第一时间想到的就是广东这个魔幻的城市,我身边的,三歪、鸡蛋都是广东人,还有帅地等我认识的很多财富自由的自媒体大佬都在广东,他们都有一种特殊的商业气息。

认识帅地也很久了,在他没入职腾讯前就认识了,就是跟认识的时候两个人也可以聊很久,聊很多有意思的事情,特别是写文章相关的,我、三歪、帅地、JavaGuide都是同龄人,所以我们的共同话题还算多,我和他打算叫广州几个大佬聚一下从他们汲取一点经验,所以这个周末我就出发去找他了。

这个需要提一下的就是去机场一件很魔幻的事情,我居然遇到了高中的同学,我带着口罩她还是认出了我,两个人互相寒暄,仿佛又回到了曾经那个懵懂的高中时代,回到了高中那种前后桌说悄悄话的时刻,一路上她载着我笑着聊过去,为了多聊会还多带着我兜了一圈,可惜美好的时光总是短暂的,我还是忍住眼角的泪水跟她说了声再见。

更魔幻的是,上了飞机后,因为我坐在空姐那种凳子的旁边,一路上就跟空乘小姐姐和小哥哥聊了一路,她们知道我是程序员的时候很惊讶,说:程序员原来不都是穿格子衬衣秃头的呀,我通过跟她们的聊天也知道了,原来他们也不是一天都在天上飞的,飞个来回就回去休息了。

职业的偏见就因为一次美好的偶遇被化解了,回去他们肯定会告诉别人程序员不秃头不穿格子衬衣,我也会告诉大家,他们也不是整天都在飞,休息时间也还是挺多的。

在愉快的交谈中时间又过得很快,尽管十分不舍,但是还是得说再见,我也只能通过一张照片去记录下这段短暂的时光,她说:下次去深圳还坐这一班吧,我说:好。

一落地就被帅地带去吃潮汕火锅了,还挺好吃的哈哈,两个人像网友见面一样,无话不聊,从大学到毕业后的种种,从自媒体到他腾讯的趣事,我和他其实很像,我们都像是被命运眷顾的人,他在csdn有两篇顶流的博文,我也在有些博客有还算不错的数据,都是靠某些机遇才走到现在的,他作为程序员的顶流博主也是我一直学习的榜样。

我两都是96年,两个人也都是来自很远的农村,他父母跟我爸妈一样在种地,他也出钱修了家里的房子,命运如此相似的两个逗比就这样在深圳相遇了。

吃完我们去酒店,他选的酒店就在他公司附近,窗外能看到腾讯的大楼,放了东西就出发去广州了,因为几个财富自由的大佬才是我们此行的目的。

不知道大家都认出来其他三个财富自由的大佬没,我看我周末推文还是有很多眼见的朋友全部认出来的,从左到右分别是:良许、敖丙、帅地、吴师兄、uzi(发哥,讲真的发哥是不是很像UZI,我看照片的时候我都惊呆了,真的超级像有木有)。

和大佬们相处的时间聊了很多,其实做自媒体能做到自由职业是需要很多努力和机遇的,在他们身上我也发现了大家各自的闪光点,有很用心对待每一个内容的良许,有很会利用资源的发哥,程序员里面微博粉丝最多的可能就是他,95年已经是几百号员工的老板了,还有很有想法的吴师兄,跟他聊天发现很多观点总是不谋而合。

大家都是流量时代的宠儿,也在这个时代因为热爱做着自己喜欢的事情,他们无论是学历还是阅历都很优秀,哈工大的研究生不想写代码,因为喜欢摄影和视频选择了自由职业全职拍视频你敢信?希望大家都越来越好,带着敖丙也财富自由一把哟哈哈。

我和帅地是聚餐里面刚入社会的仔,我们更多的是倾听大家给我们带来的经验分享,大家也很聊得来,可能因为做着一样的事情,有一样的交友圈,有特别多的共同话题,最难能可贵的是大家也毫无保留的分享自己总结了很久的经验踩过的坑,大家在聊的时候我和帅地的笔记本一直在记录,手现在还很酸。

又到了离别的时刻了,很难想象这样的一群人跟视频和文章里面一样的平易近人,那样年轻,那样的有趣,那样热血。

饭后我和帅地又乘车回深圳了,一天的舟车劳顿,在列车上帅地睡着了,看着他的脸庞,我也开始了自己的思考,我们应该怎么做,才能有属于我们的未来,才能在这个时代不被人潮淹没,不随波逐流。

第二天,我去了腾讯,因为腾讯邀请我做入职体验,内部的照片我就不分享了,总之腾讯的工作环境还是很nice的,师兄们也很热心,如果有一天我考虑去深圳我想腾讯应该是最好的选择(至少是个双休嘛哈哈)。

逛完腾讯就是跟学姐汇合了,学姐大我两届,和学姐认识也还算魔幻,大一我参加了学校的学生会,她是学生会副主席,帮了我和很多忙,说实话大学时候我觉得很多社团的东西根本一点用都没,但是那些没用的东西背后,可能也有你看不见的有用。

学姐现在也是公司HR Leader了,她说见过很多人,她说:大学经历过社团锻炼和没经历过的人还是有一些区别的,同等条件的同学参加过社团的表达会好很多,组织过活动的同学,策划和组织能力也会强很多,我一想确实,很多我们觉得没意义的东西,或许无形中改变了我们。

不过我得吐槽一下行程安排,一直都在吃吃、喝喝、玩玩,不带一秒停歇的,就连我去坐车上飞机的时间,她和另外一个妹妹都算好了(其实内心窃喜)

第一次玩射箭,我表现得不太行,也就5、6个超级正中的十环吧哈哈,其实还挺难的,手抖一下就偏很远了,所以拿起来到射出去基本上要在3秒内。

走之前我们去酒吧小酌了一杯,聊起了过往,几年不见大家都被社会磨去了学校的棱角,在职场的我们就像是一个个被抛了光的鹅卵石,不过让我佩服的是学姐的毅力,学姐每天11点准时睡觉,6点起床,工作再忙也坚持去练舞,也让我看到了那个大学时候学姐学习时的坚持。

大家会发现我一次旅行不看什么景点,就匆匆结束了,是不是想问我累么?值得么?

我觉得值得,其实旅行的意义更多的是那些人,那些故事,不是嘛?景点就在那我有时间随时就可以去看,但是很多人就不知道要什么时候再见了。

时光不问赶路人,离别只是为了下次更好的相逢,愿大家永远前程似锦,永远热泪盈眶。

絮叨

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!


文章持续更新,可以微信搜索「 三太子敖丙 」第一时间阅读,回复【资料】有我准备的一线大厂面试资料和简历模板,本文 GitHubhttps://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。
查看原文

赞 6 收藏 0 评论 2

敖丙 发布了文章 · 7月10日

DRS是啥你都不知道?不是吧,不是吧

前言

最近写了很多数据库相关的文章,大家基本上对数据库也有了很多的了解,数据库本身有所了解了,我们是不是应该回归业务本身呢?

大家去了解过自己企业数据库的部署方式么?是怎么部署的,又是部署在哪里的?部署过程中可能会出现的问题有哪些?

是主从?还是双主?有没有分库?大的表做了分表没?等等...部署方式大概率也都是分库的,表数量级超千万基本上都开始分表了,考虑周全的企业,肯定也有数据库的冷备,热备,灾备,以及异地容灾等等。

我还记得我大学做项目,学校就是买了很多物理机,我们的项目和数据库都是部署在自己内部的服务器上的,那家伙一到夏天风我嗡嗡嗡的吹,烦死了,机房还很热。

但是我敢打赌,大家现在所在的企业,大概率都是使用了各种云服务厂商的服务部署方式,那就引入了今天的第一个思考。

为什么数据库要上云呢?

我们公司的大多数服务以及数据库都是在对应的云服务厂商的,那问题就来了,为啥都要上云呢?

在思考这个问题的时候,我第一时间想到了反证法,不上云的坏处是啥?

  1. 成本

相较于传统服务器需要购买、租用的方式,云服务器采用即用即收费的方式,减少购买成本,灵活扩展的容量可以按自己需求来定,不用前期估量需要用多少。

我之前所在的电商活动团队,每次到了大促我们就去租赁云服务厂商的流量机,等活动结束就还回去,真的就是成本最大化了,而且还是根据你的使用流量计费。

如果大家还是使用自己购买的服务器,那这个时候难道去临时采购么?虽然我知道百度就是在某年春节活动的时候采购了N多物理机,但是性质不一样,他们是能最大化利用这些服务器的,他们甚至可以开发云服务自己做云服务厂商,实际上他们确实也这么做了。

  1. 性能

云服务器实现了硬件上的隔离以及宽带上的独享,不受到地域、流量等的限制,可以持续的进行业务交流,不会因中断影响效果。

如果大家还是使用物理机,那去运营商迁专线的带宽成本,还有物理机性能的问题也不一定能更上。

由于现在成本问题,你们公司买了很多低配的服务器,但是突然你们业务体量几何增长,怎么办?继续买高配的?显然不是很合适。这谁顶得住啊?

  1. 管理

云服务器可以实现远程同步管理,共享,各种业务的备份。传统服务器需要在某一网络区域内,有可能受到网络影响导致资料缺失。

上面我提到的冷备,热备,灾备其实我们购买的服务器都能做的,但是放着一个不知道什么时候才能用到的服务器在那,真的很浪费。

而且也有他做不到的,比如灾备,如果你公司在震区,要是还用物理服务器,基本上等于自杀,发送自然灾害的时候全球的用户都无法访问你,交给服务厂商就不一样了,他们选址很有讲究的,并且在各个地方都建立自己的数据中心,保证了高可用。

  1. 安全

为了保证云平台的可靠性,云服务平台公司肯定会投入大量的功夫,有一套可靠的安全保障系统,平台使用者不必担心平台稳定性、安全性问题。

物理机一旦高权限的所有者使坏,基本上都是不可恢复的灾难,虽然云服务也一样,但是合理使用,和适当的权限收敛,完全可以做到更高级别的安全的。

微盟事件大家也知道,如果提前做好各种全量,增量备份其实就没什么大问题的,再者就是权限收敛问题,我司在对应的数据库服务器上是禁用了rm -rf 、fdisk以及drop这样的极端操作的。

所有数据库的查询更是自己的组件查询,连update都无法操作(只能靠代码)。

如果还是使用物理机,就需要自己去维护,升级打补丁,很难保证不被黑客入侵,之前我就遇到过服务器补丁打迟了,导致被黑客攻击,劫持拿去挖矿了,而云服务厂商的安全系统都是实时更新的。

小结:没有特殊情况,能用云产品就直接用云产品,因为云产品提供的不仅仅是产品能力,最关键的是关键时刻的容灾、应急和服务能力,这些能力,并不是所有公司都能完整建设一套,甚至是很多公司想都想不到的。

到目前为止,虽然各大云厂商包括他们的产品,都还有这样那样的问题,但是从体系上,云仍然是最完善,最规范的,直接一点讲,比99%的公司做的都要好。

上云需要考虑的问题

这里很有意思,我在写这个文章的时候,我司正在做部分业务上云,以及云迁移这样的业务,这让我联想到了很多有意思的事情。

我们现在是从某云迁移到华为云,我想大家也会与这样的场景,但是这样迁移会带来一些什么样的问题呢?不知道大家思考过没?

其实从本地到云,或者从云到云,要思考的点估计是差多的,那我先抛出一些问题,看下这些问题华为云服务厂商是怎么解决的。

  1. 迁移失败:数据迁移失败怎么办
  2. 数据丢失:怎么判断迁移后数据是否完整
  3. 业务中断:迁移到一半遇到不可抗力怎么办
  4. 数据、传输加密:数据传输过程中怎么加密,防止被不法之徒中途获取数据
  5. 热切换:怎么做到不停服切换,以及数据源切换过程中的数据一致性

这些问题是我们不得不考虑的,大家是不是以为迁移多简单,那我想问一下,假如是订单库呢?大一点的电商每一秒,甚至是每一毫秒都是有订单的,哪怕是凌晨,别问我为什么知道咳咳。

那你肯定不能停服去迁移数据库,你需要一边迁移一边接受新的数据,这个时候就需要一些技巧了,不知道redis字典的rehash大家知道么?

rehash

在需要扩容的时候,redis会新建一个hash字典,这个时候老的停止接收数据,新数据放到新的字典,同时慢慢把老数据拿过来,其实这个思想,在数据库迁移也是可以用的,但是数据库的操作,往往都是基于数据的,并不是都是增量。

那简单,做点取巧的操作也可以,那云厂商的已经把我上面提到的所有问题都肯定考虑过了,我接触的是华为云,华为云使用了DRS(Data Replication Service 数据复制服务)做数据库迁移的事情,他怎么做的呢?

DRS:数据复制服务(Data Replication Service,简称为 DRS)是一种易用、稳定、高效,用于数据库在线迁移和数据库实时同步的云服务。 DRS 围绕云数据库,降低了数据库之间数据流通的复杂性,有效地帮助您减少数据传输的成本。

大家可能会好奇,为啥不自己去实现数据迁移,要用别人的组件呢?其实车轮子这个,如果你没更好的思路你还是用别人写好的就好了,你能比得过专业团队的研发结果嘛?

不过技术背后的实现,解决的问题还是需要我们去关心的,不然DRS什么都帮我们做了,我们动动鼠标就解决了,你怎么得到收获呢?这才是今天探讨的重点。

我说一下用车轮的好处吧:降低成本,降低技术门槛、降低风险

  • 人力成本时间成本,都是很昂贵的,如果一个现成的东西都帮我们做了,我们还去开发干嘛?再者,我相信大部分公司还是没专门的DBA的,但是车轮子在了,我们开发也能去做迁移这样的事情了,不是嘛?我们传统技术迁库耗时耗力不说了,失败率是真的高,还有数据对比等等,很头疼,我之前东家数据库迁移都是半夜,搞一晚上,天亮都不一定搞好了,要是没好,用户上线了,还的暂停。

不过即使是使用了工具,一个数据库完整的迁移流程却还是应该很严谨的,大家可能会疑惑再严谨能有多严谨?给你看个图你就知道了:

华为云的DRS的在线迁移怎么做的呢?

可以看到,迁移图中是使用到了VPN,这个的作用主要就是保住一个高速稳定的传输,以及传输数据的加密,万一你同步的过程被其他对手公司抓到,那?在文章后面,你可以看到华为云DRS是怎么做的网络安全,我做了一次完整的迁移实战,并且做了总结。

迁移实战

他迁移很简单,都有教程,我用过一遍,大致步骤如下:

迁移作为一个特殊时期,业务配合、人为配合是最关键的,部分操作一定要规避,比如说常见的:

  • 不能将源数据库日志强制清理掉
  • 不能将用于连接源数据库的用户密码修改掉、或者删除掉
  • 不能将表长时间锁定,导致外部都无法查询该表

他在迁移之前可以做一个迁移预检查,从官方文档来看,都是对过往迁移案例总结出来的检查步骤,可以让迁移成功有更好的保障,这点挺好可以在迁移前夕找出问题所在,我也失败过,是因为环境问题,都给了很明确的指示。

大家不知道思考过没,就是数据迁移了,但是如果数据库的设置没迁移那也是很麻烦的,如果一个迁移工具能够做到把DBA设置的好的User权限迁移了,以及我们设置的各种触发器,数据库字符集设置都迁移了,那才是我理想的一个迁移工具,是的华为云DRS做了,这就是比较优秀的点了,真的省了很多功夫。

特别是对于数据库各种设置并没那么了解的开发来说,这功能确实是很福利了,而且还有性能参数,类似各种buffer大小,cache大小等等他都能迁移,甚至可以做到流控,还可以随时改变流控就更优秀了:

迁移模式多样化,这是我准备开始迁移的第一感受,我上面提到过,如果不能增量迁移将毫无意义,DRS还是想到了,这让我觉得好像有点暖,说着说着我的眼角又湿润了...

因为大部分的场景我们都是线上业务的不停服迁移,在迁移过程中,还是不断的有增量数据在涌入的,敖丙之前所经历过的数据库迁移基本上也都是全量+增量的迁移模式,全量的场景只存在内部系统,或者离线数据等。

其实这里的技术核心就在于怎么去保证增量的数据也能保证不丢失正确的迁移,我猜是通过binlog同步的,我看了下他的文档,日志,果然被我猜对了。

DRS是通过全量迁移过程完成历史数据迁移至目标数据库后,增量迁移阶段通过捕抓日志,应用日志等技术,将源端和目标端数据库保持数据一致,这里的保持一致后面也会提到,他提供了完整的数据对比功能。

迁移过程很简单,进度完全可以看到,数据的延迟也可以很直观的看到:

迁移结束之后,DRS提供了数据对比,其实数据对比以前我做迁移的时候,我们都是通过对比数据库行数去做的,因为没这样的迁移工具,我发现了很暖心的一点就是内容对比,这一点让我很惊喜,因为行数的对比还是不够严谨,修改的日志如果缺失行数的对比也是没用的。

img

img

img

img

等待对比完成,点击“查看对比报表”,可以了解对比详情,详情页面如图所示:

上面提到的网络安全问题,我也在DRS找到了答案,他们会使用特定的加密协议进行数据传输,还可以用特定的VPN挂载网络传输:

DRS还做了迁移监控,可以看到实时进度,让整个迁移进度比较可视化,中间的异常也一目了然,说实话工具真的就是香,以前想都不敢想,我们熬夜就生怕一个环节出错,而且经常还是后知后觉的,可视化的流程会你对迁移有一种掌控感。

迁移完成:

从我开始迁移到结束,整个流程其实不到2小时,这个放在以前是不敢想的,这波体验我是很满意的,让我一个开发就做到了以前DBA才能做的事情,说着说了旁边的DBA的眼角也湿润了....

小结

整个体验我觉得是很不错的,我总结几个我觉得DRS独特的设计和使用场景:

  1. 迁移限速,根据限定时间段设置迁移速度上限

应用场景:

  • 有些流量型app,比如游戏厂商等客户, 迁移时源数据库的公网、VPN不能打满(打满将影响其对外业务,或者影响共用VPN 带宽)
  • 有些业务负载较重,或着客户无法接受 业务时间应用程序因为迁移带来额外负载
  1. 用户迁移(权限、密码、 definer),完整继承源权限体系

应用场景:

  • 市面上的迁移产品均不支持用户的迁移, 也就是说如果用户没有注意,或者不懂用户迁移,那么迁移后业务必然报错, DRS提供了全套的用户权限继承设计, 可以将权限、密码、definer保留迁移至目标数据库,确保迁移后权限安全、业务稳定,可以让不熟悉数据库的客户迁移时,仍然可以完成一场精细的、高质量的数据库迁移。
  1. 参数对比,迁移后业务稳定

应用场景:

  • 市面上的迁移产品均不支持参数的迁移,而数据库参数不一样,这将直接导致业务程序 运行报错(举个简单例子session数迁移后变小了),DRS选定了业务和性能强相关关键的参数,避免了这些参数后续因为没有继承源环境设置,而导致业务报错或性能下降, 可以让不熟悉数据库的客户迁移时,仍然可以完成一场精细的、高质量的数据库迁移。
  1. 数据校对平台,割接好帮手

应用场景:

  • 市面上的迁移产品均不支持数据的对比,校对工作留给用户测,DRS提供了丰富的对比功能:
  • 对象对比
  • 数据级对比
  • 对比可定时,可取消

    利用对比定时任务,可以选择凌晨等业务低峰期 进行数据一致性对比,第二天可以查看数据对比结果,对于迁移情况做到完全掌握。 可以让不熟悉数据库的客户迁移时,仍然可以完成一场精细的、高质量的数据库迁移。

  1. 触发器、事件的迁移

应用场景:

  • 市面上的迁移产品均不支持触发器、事件的迁移,精通迁移的用户关注这些细节,因 为触发器和事件也是数据库的一部分,触发器和事件存在关键的业务逻辑,这些对象 不支持迁移,业务必然报错,甚至造成不可挽回的损失。
  • 可以让不熟悉数据库的客户迁移时,仍然可以完成一场精细的、高质量的数据库迁移。

注:【部分图片来源网络 侵删】

总结

其实给大家介绍这样DRS的一个背景和技术,主要是希望跟大家跟我一起做一次完整数据迁移,一起去探讨技术背后的场景,以及场景背后我们应该有技术思考。

不过这次体验真的,让我不得不感慨技术的便捷性,以前数据库迁移都是团队开发以及测试一个团队熬夜守着数据库迁移,最后验证测试才能走的,所有人拖着疲惫的身躯看着升起的太阳,眼角都湿了...

现在我自己看看教程动动手指就完成了一场大规模的数据库迁移演练,在享受技术给我带来方便的同时,也让我对技术背后的具体实现和人生的意义陷入了深深的思考。

或许这就是技术的价值吧,或许这就是这么多工程师日日夜夜辛苦的意义吧,或许...

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

查看原文

赞 28 收藏 7 评论 8

敖丙 发布了文章 · 7月7日

【逼你学习】让自制力提升300%的时间管理方法、学习方法分享

过几天就要高考了,在这里预祝各位考生考个好成绩,我等着大家跟我分享金榜题名的喜悦。

目标

在明确学习方法之前,不如我们先明白一下我们学习的目的,再去讨论我们怎么去学习。

我不知道大家心里有没有一个目标,高中你的目标应该是考个好大学,大学你的目标可能就是一场不分手的恋爱,或者满腹经纶的才学,毕业后你的目标可能就是房子、车子、或者是活的不那么狼狈……我不知道大家的目标是啥,可以留言告诉我。

如果你没有目标我觉得你应该给自己树立一个目标,因为一旦你失去目标,你也会失去动力的。

我写文章以来有很多读者都问我,注意力不够专注,总是学着学着就走神,玩手机,看剧,问我怎么办,因为个人时间的原因虽然看到了,我都选择没回复,还有另外一个原因就是,我想大家都是知道答案的,这有啥办法你自己都管不住自己,难道我说几句话你就能管得住了?

如果你有很坚定的目标,但是你还没完成,我想你应该是睡觉都睡不着才对,而不是在那刷手机虚度光阴,一遍遍的安慰自己玩一会没事的。

至于我自己的目标其实很简单,看看我大二之前住的家就知道了,这还是过年老爸除草之后的样子,不然满是杂草。

经常有人说向往农村的环境、空气,向往那样的田园生活,说实话我们那风景确实很好,但是如果让你住这样一个阴暗的房子,让你跟猪一起上厕所你可能待不了多久。

我们那就是这样,你不努力走出这里,一辈子等待你的就是面朝黄土背朝天。

有很长一段时间我们家里的目标就是修新家,后来老爸努力出钱修了房子,我出钱装修和置办了家电,这就是一家人定了目标努力的结果,苦尽甘来总是春,姹紫嫣红别样情。

所以定个目标吧,然后去做就好了,我觉得你每次贪玩的时候,想想那个目标你就会很有负罪感的,我以前很喜欢玩游戏,现在每次玩负罪感都很强,所以现在我基本上都戒了,就算不学习出去走走,和朋友出去吃吃饭走走也是极好的。

其实到最后你会发现游戏都是虚的,进你脑子,进你口袋的东西才是实打实的,虚拟世界都是0和1,真不值得你付出这么多。

时间规划

想要摆脱拖延症,还是得给自己一个时间规划,不然每次你都会想,我就看几分钟,我就玩最后一局,这样的几分钟会漫漫吞噬你的碎片时间。

时间规划不需要特别细致,精确到天,或者周就够了,就比如我自己某段时间的规划,大家可以看到也不是很精确,我之前看到过学霸精确到分钟的时间表,我不建议大家这样做,因为这样你会有太大的约束,况且你一个点没做到,后面的都拖延了,最后就想算了都延了这么多了,破罐子破摔。

不过当每天事情多的时候,大家还是可以列一个每日的任务清单,完成了打钩,我会列一段时间的任务清单。

这样做主要是为了自己有个时间观念,争取今日事今日毕,不是很多小伙伴要自学很多技术嘛,那就给自己定个时间,

定完时间后,你还应该有一个学习的知识点清单,就类似书本的目录,比如第一周要掌握哪些知识,第二周要掌握哪些知识,给自己定个目标。

在学习之前列出知识点清单还有个好处就是可以帮助你对这个知识点有一个大致的印象,你要学什么你总得知道吧。

列出知识点后,你可以边学边补充,不管你是看书还是看视频,最后都会形成一个知识体系的,我做了很多面试视频,大家不是好奇那些高手怎么回答得逻辑这么清晰,表达这么流畅,就是因为他们有自己的知识体系他在脑子已经梳理清楚了,最后组织一下语言表达就好了。

列知识点的工具我就比较推荐脑图了,我个人是使用的processOn和Xmind,就比如我自己做的概要设计模板,我就把时间规划和知识点放到了一块。

脑图是我工作以来,一直都很依赖的工作和学习的方式,工作中大家也会发现身边的同事、朋友,基本上也都会或多或少的做一些脑图,去辅助自己设计系统,或者去了解学习一些知识点什么的,目的就是有逻辑的总结。

大家看到我的每一期文章我都会去列一个大概的知识脑图,最后在每个点后面去追加知识细节,你回看的时候会发现,真的异常清晰,

看书

我记得我写过一个书单集合的文章,里面有很多我和身边朋友看过的书籍,我还有我身边的朋友都不止一次安利,看书这件事情,熟读唐诗三百首,不会做诗也会吟。

用宝珠打扮自己,不如用知识充实自己,读书的好处懂的人自然懂,作者都是把自己几年甚至几十年的总结,都在写在了书里,大家看完肯定能学到很多东西的。

看书的时候你的心会没那么浮躁,大家看到厚的书总是觉得自己看不完,其实看一本书你规定自己每天看十页,一本300页的书,一个月也就看完了,很快的,根本不浪费大家多少时间。

看书前我推荐大家多去豆瓣看看书评,不过需要辨别一些刷书评的书,评分基本上是比较客观的。

博客

看书难免会比较枯燥,特别是技术相关的书籍,很多作者还贴了大量的配置代码,我以前以为就我看那部分看不懂,我都不好意思说出去硬着头皮看,结果一问周围的大佬也是会头疼那部分都是会选择跳过的,我???

但是就有那么一群博主,把自己学到的东西,用通俗易懂的语言表达了出来,中间还会穿插各种梗和表情包,看起来比小说还津津有味,比如那个什么叫三太子敖丙的,就很值得推荐。

我认识很多博主,他们都在互联网一线公司工作:阿里,腾讯,多多,字节等等,他们的理解和观点,以及一些工作中的收获,我觉得还是很值得去学习的,总是能get到知识盲区。

博客的平台主要有:CSDN、知乎、掘金、博客园、思否、开源中国

视频

看到这里会有很多小伙伴说:丙丙,人家就是看不进去文字嘛,怎么办?

乖,那看视频呗,看视频好的一点就是,有老师操作,有PPT可以图文并茂的看,同样有很多互联网一线公司的博主也将知识拍成视频,视频的风格也很多样化。

B站就是很好的学习网站,我个人学习视频剪辑,学习很多技术栈都是在里面看的,里面有很多厉害的UP主,而且用户群体都是高尖人才,像我的老师就有小仙若、欣小萌、咬人喵等等,跟着他们学到了不少东西。

小破站!这是我第一个力荐的网站,我个人学习视频剪辑,学习很多技术栈都是在里面看的,里面有很多厉害的UP也有很多学习的UP主,而且用户群体都是人才,像我的老师就有小仙若、欣小萌、咬人喵等等,跟着他们学到了不少东西。

笔记

俗话说得好,好记性不如烂笔头,大家不管是看视频,还是自己看书,我觉得,做个笔记太有必要了,你可能会说我是天才来的,过目不忘,我不信!

千万不要太相信自己的记忆力。

很多时候甚至我们转眼就会忘记很多事情,那还指望脑袋能记多少?

所以我办公桌触手可及的地方就有笔记本,有时候打打草稿,或者写写想法,大家用手机和电脑多,那就用在线笔记软件,印象笔记、有道云笔记等都是不错的选择。

个人用的印象笔记,从大学到现在用了很多年了,还是很不错的,也承载了我的很多记忆,基本上有我学硬件,到学软件这一路的笔记了,也有一些婆娑的话语,我是话痨来的嘛。

我主要就是记录知识点,和偶尔的一些面经收获啥的:

实践

纸上得来终觉浅,绝知此事要躬行。

真的,大家一定要去实践,我个人没啥工作经验,但是我也出来打工3年了,可以完全负责任的告诉你,任何行业,不管是我们写代码,还是别的行业,绝对是大量的实践去积累经验的,我没看到任何一个人就靠理论知识就可以做到技术专家的。

看和做真的不一样,书到用时方恨少,事非经过不知难。我以前做硬件,看视频的时候,觉得我自己一次就行,结果在实验室一次次熬夜,一次次失败,才成功做出成品,但是那一次成功之后,我再做类似的就会快很多了,因为之前的一次次失败把坑都踩了,再搞一次不就是张飞吃豆芽,小菜一碟了嘛。

你身边的大佬,肯定也是一个个BUG写上去的,他们也不是生下来就是大佬的。

坚持

所有上面这些,不管是看书,看博客,还是看视频,最后的最后,还是要大家坚持,持之以恒才能看到效果的,你可以看了几天然后跟我说,丙丙我怎么还是拿不到大厂Offer,怎么还是啥都不会,我会回答你:回去继续看。

当然这里是开个玩笑,但是确实是这样,我身边的技术大佬,基本上都是日复一日坚持做一些东西,最后量变引起质变才有他们今天的,其实我在这点上做得很差,我也知道我还有很长的路要走。

你没必要每天起很早睡很晚,但求这一天不荒废就好了,苟有恒,何必三更起五更眠?

契而舍之,朽木不折;契而不舍,金石可偻。过程可能有点艰难,但是总会长风破浪会有时,直挂云帆济沧海,你熬一熬就会发现,山穷水复疑无路,柳暗花明又一村。

费曼学习法

这是我最后要安利的一个学习方法,我个人认为,很不错,不知道你们能不能get到这个学习方法的精髓。

理查德·费曼(1918-1988年),1965年获得诺贝尔物理学奖,美籍犹太人。

他被认为是爱因斯坦之后最睿智的理论物理学家,也是第一位提出纳米概念的人。

选择一个概念

选一个你想学习的概念。

讲授这个概念(费曼技巧的灵魂)

设想,你面对这个领域的菜鸟,甚至面对十岁的孩童,试图解释清楚这个概念,并让对方完全听懂。

这,一方面加深你的理解,另一方面,找到不明白的节点或卡点。

查漏补缺

当你无法解释的时候,重新回头找答案。

回到书上去,回去找同学、找老师、找已经懂的人,把这个概念重新研究一遍。

结果要求,你能够把这个概念重新流利地解释出来,简化语言和尝试类比,举一反三。

继续升华

假若是一个学术化或抽象化的词语,尝试用简洁词语来解释,要么,用别的东西来类比它。

总结

大家要知道现实真的是很残酷的,你们发现不管是文章还是视频我都没聊太多特别现实的东西,学校,职场,演艺圈等等,我怕我号聊没了,也不想传播这么多负能量,虽然涉世未深,但我也接触了不少东西,你会发现我们这么努力还是改变不了世界,改变不了各种潜规则,我们这么做,只是为了不让世界改变我们而已。

不管怎么样,希望你在人生路上扶摇直上九万里,任何事情都是需要付出才会得到回报的,希望大家都认真对待自己的人生,千淘万漉虽辛苦,吹尽狂沙始到金,期待有一天你能跟我分享你成功的喜悦。

絮叨

我是敖丙,你知道的越多,你不知道的越多,我们下期见!

人才们的 【三连】 就是敖丙创作的最大动力,如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 14 收藏 6 评论 2

敖丙 发布了文章 · 7月1日

Redis为什么快?你只知道单线程和基于内存?抱歉我不能给你offer...

面试场景

面试官:Redis有哪些数据类型?

我:String,List,set,zset,hash

面试官:没了?

我:哦哦哦,还有HyperLogLog,bitMap,GeoHash,BloomFilter

面试官:就这?回家等通知吧。

前言

我敢肯定,第一个回答,100%的人都能说上来,但是第二个回答能回答上来的人可能就不多了,但是这也不是我今天探讨的话题。

我就从我自己的去面试的回答思路,以及作为一个面试官他想听到的标准答案来给大家出一期,Redis基础类型的文章(系列文章),写这个的时候我还是很有心得的,不知道大家有多少人跟我最开始一样,面试官问有哪些类型,就回答出那五种就结束了,如果你是这样的可以在评论区留言,让我看看有多少人是这样的。

但是,一场面试少说都是半小时起步上不封顶,你这样一句话就回答了这么重要的五个知识点,这个结果是你想要的么?是面试官想要的么?

我再问你一个问题,你可能就懵逼了:String在Redis底层是怎么存储的?这些数据类型在Redis中是怎么存放的?Redis快的原因就只有单线程和基于内存么?

宝贝,触及知识盲区没?不慌,我以前也是这样的,我以为我背出那五种就完事了,结果被面试官安排了一波,后面我苦心修炼,总算是好了一点,现在对缓存也是非常熟悉了,你不会没事,有我嘛,乖。

正文

Redis是C语言开发的,C语言自己就有字符类型,但是Redis却没直接采用C语言的字符串类型,而是自己构建了动态字符串(SDS)的抽象类型。

就好比这样的一个命令,其实我是在Redis创建了两个SDS,一个是名为aobing的Key SDS,另一个是名为cool的Value SDS,就算是字符类型的List,也是由很多的SDS构成的Key和Value罢了。

SDS在Redis中除了用作字符串,还用作缓冲区(buffer),那到这里大家都还是有点疑惑的,C语言的字符串不好么为啥用SDS?SDS长啥样?有什么优点呢?

为此我去找到了Redis的源码,可以看到SDS值的结果大概是这样的,源码的在GitHub上是开源的大家一搜就有了。

struct sdshdr{
    int len;
    int free;
    char buf[];
}

回到最初的问题,为什么Redis用了自己新开发的SDS,而不用C语言的字符串?那好我们去看看他们的区别。

SDS与C字符串的区别

  1. 计数方式不同

C语言对字符串长度的统计,就完全来自遍历,从头遍历到末尾,直到发现空字符就停止,以此统计出字符串的长度,这样获取长度的时间复杂度来说是0(n),大概就像下面这样:

但是这样的计数方式会留下隐患,所以Redis没有采用C的字符串,我后面会提到。

而Redis我在上面已经给大家看过结构了,他自己本身就保存了长度的信息,所以我们获取长度的时间复杂度为0(1),是不是发现了Redis快的一点小细节了?还没完,不止这些。

  1. 杜绝缓冲区溢出

字符串拼接是我们经常做的操作,在C和Redis中一样,也是很常见的操作,但是问题就来了,C是不记录字符串长度的,一旦我们调用了拼接的函数,如果没有提前计算好内存,是会产生缓存区溢出的。

比如本来字符串长这样:

你现在需要在后面拼接 ,但是你没计算好内存,结果就可能这样了:

这是你要的结果么?很显然,不是,你的结果意外的被修改了,这要是放在线上的系统,这不是完了?那Redis是怎么避免这样的情况的?

我们都知道,他结构存储了当前长度,还有free未使用的长度,那简单呀,你现在做了拼接操作,我去判断一些是否可以放得下,如果长度够就直接执行,如果不够,那我就进行扩容。

这些大家在Redis源码里面都是可以看到对应的API的,后面我就不一一贴源码了,有兴趣的可以自己去看一波,需要一点C语言的基础。

  1. 减少修改字符串时带来的内存重分配次数

C语言字符串底层也是一个数组,每次创建的时候就创建一个N+1长度的字符,多的那个1,就是为了保存空字符的,这个空字符也是个坑,但是不是这个环节探讨的内容。

Redis是个高速缓存数据库,如果我们需要对字符串进行频繁的拼接和截断操作,如果我们写代码忘记了重新分配内存,就可能造成缓冲区溢出,以及内存泄露。

内存分配算法很耗时,且不说你会不会忘记重新分配内存,就算你全部记得,对于一个高速缓存数据库来说,这样的开销也是我们应该要避免的。

Redis为了避免C字符串这样的缺陷,就分别采用了两种解决方案,去达到性能最大化,空间利用最大化:

  • 空间预分配:当我们对SDS进行扩展操作的时候,Redis会为SDS分配好内存,并且根据特定的公式,分配多余的free空间,还有多余的1byte空间(这1byte也是为了存空字符),这样就可以避免我们连续执行字符串添加所带来的内存分配消耗。

    比如现在有这样的一个字符:

我们调用了拼接函数,字符串边长了,Redis还会根据算法计算出一个free值给他备用:

我们再继续拼接,你会发现,备用的free用上了,省去了这次的内存重分配:

  • 惰性空间释放:刚才提到了会预分配多余的空间,很多小伙伴会担心带来内存的泄露或者浪费,别担心,Redis大佬一样帮我们想到了,当我们执行完一个字符串缩减的操作,redis并不会马上收回我们的空间,因为可以预防你继续添加的操作,这样可以减少分配空间带来的消耗,但是当你再次操作还是没用到多余空间的时候,Redis也还是会收回对于的空间,防止内存的浪费的。

    还是一样的字符串:

当我们调用了删减的函数,并不会马上释放掉free空间:

如果我们需要继续添加这个空间就能用上了,减少了内存的重分配,如果空间不需要了,调用函数删掉就好了:

  1. 二进制安全

仔细看的仔肯定看到上面我不止一次提到了空字符也就是’0‘,C语言是判断空字符去判断一个字符的长度的,但是有很多数据结构经常会穿插空字符在中间,比如图片,音频,视频,压缩文件的二进制数据,就比如下面这个单词,他只能识别前面的 不能识别后面的字符,那对于我们开发者而言,这样的结果显然不是我们想要的对不对。

Redis就不存在这个问题了,他不是保存了字符串的长度嘛,他不判断空字符,他就判断长度对不对就好了,所以redis也经常被我们拿来保存各种二进制数据,我反正是用的很high,经常用来保存小文件的二进制。

资料参考:Redis设计与实现

总结

大家是不是发现,一个小小的SDS居然有这么多道理在这?

以前就知道Redis快,最多说个Redis是单线程的,说个多路IO复用,说个基于内存的操作就完了,现在是不是还可以展开说说了?

本文是系列文的第一章,后续会陆续更新的,不知道这样的类型大家是否喜欢,可以留言给我反馈。

大家一同去面试,一样的问题,就是有人能过,有人不能过,大家经常归咎于自己学历,自己过往经历的原因,但是你可以问一下自己,底层的细节字节是否有深究呢?细节往往才是最重要的,也是最少人知道的,如何和别的仔拉开差距拿到offer,我想就是这样些细节决定的吧,背谁不会呢?

絮叨

我是敖丙,一个在互联网苟且偷生的程序员。

你知道的越多,你不知道的越多人才们的 【三连】 就是丙丙创作的最大动力,我们下期见!

注:如果本篇博客有任何错误和建议,欢迎人才们留言!


查看原文

赞 61 收藏 42 评论 4

敖丙 发布了文章 · 6月29日

我以为我对索引非常了解,直到我遇到了阿里面试官...

前言

写数据库,我第一时间就想到了MySQL、Oracle、索引、存储过程、查询优化等等。

不知道大家是不是跟我想得一样,我最想写的是索引,为啥呢?

以下这个面试场景,不知道大家熟悉不熟悉:

面试官:数据库有几千万的数据,查询又很慢我们怎么办?

面试者:加索引。

面试官:那索引有哪些数据类型?索引是怎么样的一种结构?哪些字段又适合索引呢?B+的优点?聚合索引和非聚合索引的区别?为什么说索引会降低插入、删除、修改等维护任务的速度?........

面试者:面试官怎么出我们公司门来着😂。

是的大家可能都知道慢了加索引,那为啥加,在什么字段上加,以及索引的数据结构特点,优点啥的都比较模糊或者甚至不知道。

那我们也不多BB了,直接开始这次的面试吧。

正文

我看你简历上写到了熟悉MySQL数据库以及索引的相关知识,我们就从索引开始,索引有哪些数据结构?

Hash、B+

大家去设计索引的时候,会发现索引类型是可以选择的。

为什么哈希表、完全平衡二叉树、B树、B+树都可以优化查询,为何Mysql独独喜欢B+树?

我先聊一下Hash:

大家可以先看一下下面的动图

注意字段值所对应的数组下标是哈希算法随机算出来的,所以可能出现哈希冲突

那么对于这样一个索引结构,现在来执行下面的sql语句:

select * from sanguo where name='鸡蛋'

可以直接对‘鸡蛋’按哈希算法算出来一个数组下标,然后可以直接从数据中取出数据并拿到所对应那一行数据的地址,进而查询那一行数据, 那么如果现在执行下面的sql语句:

select * from sanguo where name>'鸡蛋'

则无能为力,因为哈希表的特点就是可以快速的精确查询,但是不支持范围查询

如果做成了索引,那速度也是很慢的,要全部扫描。

问个题外话,那Hash表在哪些场景比较适合?

等值查询的场景,就只有KV(Key,Value)的情况,例如Redis、Memcached等这些NoSQL的中间件。

你说的是无序的Hash表,那有没有有序的数据结构?

有序数组,它就比较优秀了呀,它在等值查询的和范围查询的时候都很Nice。

那它完全没有缺点么?

不是的,有序的适合静态数据,因为如果我们新增、删除、修改数据的时候就会改变他的结构。

比如你新增一个,那在你新增的位置后面所有的节点都会后移,成本很高。

那照你这么说他根本就不优秀啊,特点也没地方放。

此言差矣,可以用来做静态存储引擎啊,用来保存静态数据,例如你2019年的支付宝账单,2019年的淘宝购物记录等等都是很合适的,都是不会变动的历史数据。

有点东西啊小伙子,那二叉树呢?

二叉树的新增和结构如图:

二叉树的结构我就不在这里多BB了,不了解的朋友可以去看看数据结构章节。

二叉树是有序的,所以是支持范围查询的。

但是他的时间复杂度是O(log(N)),为了维持这个时间复杂度,更新的时间复杂度也得是O(log(N)),那就得保持这棵树是完全平衡二叉树了。

怎么听你一说,平衡二叉树用来做索引还不错呢?

此言差矣,索引也不只是在内存里面存储的,还是要落盘持久化的,可以看到图中才这么一点数据,如果数据多了,树高会很高,查询的成本就会随着树高的增加而增加。

为了节约成本很多公司的磁盘还是采用的机械硬盘,这样一次千万级别的查询差不多就要10秒了,这谁顶得住啊?

如果用B树呢?

同理来看看B树的结构:

可以发现同样的元素,B树的表示要比完全平衡二叉树要“矮”,原因在于B树中的一个节点可以存储多个元素。

B树其实就已经是一个不错的数据结构,用来做索引效果还是不错的。

那为啥没用B树,而用了B+树?

一样先看一下B加的结构:

我们可以发现同样的元素,B+树的表示要比B树要“胖”,原因在于B+树中的非叶子节点会冗余一份在叶子节点中,并且叶子节点之间用指针相连。

那么B+树到底有什么优势呢?

其实很简单,我们看一下上面的数据结构,最开始的Hash不支持范围查询,二叉树树高很高,只有B树跟B+有的一比。

B树一个节点可以存储多个元素,相对于完全平衡二叉树整体的树高降低了,磁盘IO效率提高了。

而B+树是B树的升级版,只是把非叶子节点冗余一下,这么做的好处是为了提高范围查找的效率

提高了的原因也无非是会有指针指向下一个节点的叶子节点。

小结:到这里可以总结出来,Mysql选用B+树这种数据结构作为索引,可以提高查询索引时的磁盘IO效率,并且可以提高范围查询的效率,并且B+树里的元素也是有序的。

那么,一个B+树的节点中到底存多少个元素最合适你有了解过么?

额这个这个?卧*有点懵逼呀。

过了一会还是没想出,只能老实交代:这个不是很了解咳咳。

你可以换个角度来思考B+树中一个节点到底多大合适?

B+树中一个节点为一页或页的倍数最为合适

为啥?

因为如果一个节点的大小小于1页,那么读取这个节点的时候其实也会读出1页,造成资源的浪费。

如果一个节点的大小大于1页,比如1.2页,那么读取这个节点的时候会读出2页,也会造成资源的浪费。

所以为了不造成浪费,所以最后把一个节点的大小控制在1页、2页、3页、4页等倍数页大小最为合适。

你提到了页的概念,能跟我简单说一下么?

首先Mysql的基本存储结构是(记录都存在页里边):

  • 各个数据页可以组成一个双向链表
  • 每个数据页中的记录又可以组成一个单向链表
    • 每个数据页都会为存储在它里边儿的记录生成一个页目录,在通过主键查找某条记录的时候可以在页目录中使用二分法快速定位到对应的槽,然后再遍历该槽对应分组中的记录即可快速找到指定的记录
    • 其他列(非主键)作为搜索条件:只能从最小记录开始依次遍历单链表中的每条记录

所以说,如果我们写 select * from user where username='丙丙'这样没有进行任何优化的sql语句,默认会这样做:

  • 定位到记录所在的页
    • 需要遍历双向链表,找到所在的页
  • 从所在的页内中查找相应的记录
    • 由于不是根据主键查询,只能遍历所在页的单链表了

很明显,在数据量很大的情况下这样查找会很慢!看起来跟回表有点点像。

哦?回表你聊一下。

卧槽,该死,我嘴干嘛。

回表大概就是我们有个主键为ID的索引,和一个普通name字段的索引,我们在普通字段上搜索:

select * from table where name = '丙丙'

执行的流程是先查询到name索引上的“丙丙”,然后找到他的id是2,最后去主键索引,找到id为2对应的值。

回到主键索引树搜索的过程,就是回表。不过也有方法避免回表,那就是覆盖索引

哦?那你再跟我聊一下覆盖索引呗?

!!! 我这个嘴。。。

这个其实比较好理解,刚才我们是 select * ,查询所有的,我们如果只查询ID那,其实在Name字段的索引上就已经有了,那就不需要回表了。

覆盖索引可以减少树的搜索次数,提升性能,他也是我们在实际开发过程中经常用来优化查询效率的手段。

很多联合索引的建立,就是为了支持覆盖索引,特定的业务能极大的提升效率。

索引的最左匹配原则知道么?

最左匹配原则

  • 索引可以简单如一个列 (a),也可以复杂如多个列 (a,b,c,d),即联合索引
  • 如果是联合索引,那么key也由多个列组成,同时,索引只能用于查找key是否存在(相等),遇到范围查询 (>、<、between、like左匹配)等就不能进一步匹配了,后续退化为线性查找。
  • 因此,列的排列顺序决定了可命中索引的列数

例子:

  • 如有索引 (a,b,c,d),查询条件 a=1 and b=2 and c>3 and d=4,则会在每个节点依次命中a、b、c,无法命中d。(c已经是范围查询了,d肯定是排不了序了)

总结

索引在数据库中是一个非常重要的知识点!

上面谈的其实就是索引最基本的东西,N叉树,跳表、LSM我都没讲,同时要创建出好的索引要顾及到很多的方面:

  • 最左前缀匹配原则。这是非常重要、非常重要、非常重要(重要的事情说三遍)的原则,MySQL会一直向右匹配直到遇到范围查询 (>,<,BETWEEN,LIKE)就停止匹配。
  • 尽量选择区分度高的列作为索引,区分度的公式是 COUNT(DISTINCT col)/COUNT(*)。表示字段不重复的比率,比率越大我们扫描的记录数就越少。
  • 索引列不能参与计算,尽量保持列“干净”。比如, FROM_UNIXTIME(create_time)='2016-06-06' 就不能使用索引,原因很简单,B+树中存储的都是数据表中的字段值,但是进行检索时,需要把所有元素都应用函数才能比较,显然这样的代价太大。所以语句要写成 : create_time=UNIX_TIMESTAMP('2016-06-06')。
  • 尽可能的扩展索引,不要新建立索引。比如表中已经有了a的索引,现在要加(a,b)的索引,那么只需要修改原来的索引即可。
  • 单个多列组合索引和多个单列索引的检索查询效果不同,因为在执行SQL时,MySQL只能使用一个索引,会从多个单列索引中选择一个限制最为严格的索引(经指正,在MySQL5.0以后的版本中,有“合并索引”的策略,翻看了《高性能MySQL 第三版》,书作者认为:还是应该建立起比较好的索引,而不应该依赖于“合并索引”这么一个策略)。
  • “合并索引”策略简单来讲,就是使用多个单列索引,然后将这些结果用“union或者and”来合并起来

思路文献参考:

《MySQL实战》

《高性能MySQL》

最后部分内容来自->java3y《索引和锁》

丁奇《MySQL实战》

絮叨

之前在B站传了视频:

大家反馈效果还是ok的,我后续会多多尝试的,也希望把改进的建议留言反馈给我。

我去年拍摄了第一个超级粗糙的vlog:

因为拍摄剪辑手法都很垃圾,我就删了,但是最近又想着放上去,在纠结哈哈,想看留个言我就传了哈哈,我们下期间。

今天丙丙也开始了来杭16天后的第一次上班,很开心我们公司在杭州第一批复工的名单中,我已经16天没和人这样说过话了,太开心了,不过不能开空调还得开窗户通风,真的是超级超级冷。

这熟悉的工位,这熟悉的显示器,我的眼角又......

白嫖不好,创作不易,各位的点赞就是丙丙创作的最大动力,我们下篇文章见!

持续更新,未完待续......

查看原文

赞 48 收藏 30 评论 5

敖丙 发布了文章 · 6月9日

面试官问我:什么是消息队列?什么场景需要他?用了会出现什么问题?

点赞再看,养成习惯

面试开始

一个风度翩翩,穿着格子衬衣的中年男子,拿着一个满是划痕的mac向你走来,看着铮亮的头,心想着肯定是尼玛顶级架构师吧!但是我们看过暖男敖丙的系列,腹有诗书气自华,虚都不虚。

小伙子之前问了你这么多Redis的知识,你不仅对答如流,你还能把各自场景的解决方案,优缺点说得这么流畅,说你是不是看过敖丙写的《我们一起进大厂》系列呀?

惊!!!老师你怎么知道的,我看了他的系列根本停不下来啊。

呵呵,Redis没难住你,但是我问个新的技术栈我还怕难不住你?我问问你你项目中用过消息队列么?你为啥用消息队列?

噗此,这也叫问题?别人用了我能不用么?别人用了我就用了呗,我就是为了用而用。

你心里嘀咕就好了,千万别说出来哈,说出来了没拿到Offer别到时候就在那说,敖丙那个渣男教我说的!

面试官你好:我们公司本身的业务体量很小,所以直接单机一把梭啥都能搞定了,但是后面业务体量不断扩大,采用微服务的设计思想分布式的部署方式,所以拆分了很多的服务,随着体量的增加以及业务场景越来越复杂了,很多场景单机的技术栈和中间件以及不够用了,而且对系统的友好性也下降了,最后做了很多技术选型的工作,我们决定引入消息队列中间件

哦?你说到业务场景越来越复杂,你那说一下你都在什么场景用到了消息队列?

嗯,我从三个方面去说一下我使用的场景吧。

Tip:这三个场景也是消息队列的经典场景,大家基本上要烂熟于心那种,就是一说到消息队列你脑子就要想到异步、削峰、解耦,条件反射那种。

异步:

我们之前的场景里面有很多步骤都是在一个流程里面需要做完的,就比如说我的下单系统吧,本来我们业务简单,下单了付了钱就好了,流程就走完了。

但是后面来了个产品经理,搞了个优惠券系统,OK问题不大,流程里面多100ms去扣减优惠券。

后来产品经理灵光一闪说我们可以搞个积分系统啊,也行吧,流程里面多了200ms去增减积分。

再后来后来隔壁的产品老王说:下单成功后我们要给用户发短信,也将就吧,100ms去发个短信。

再后来。。。(敖丙你有完没完!!!)

反正就流程有点像这样 ↓

你们可以看到这才加了三个,我可以斩钉截铁的告诉你真正的下单流程涉及的系统绝对在10个以上(主流电商),越大的越多。

这个链路这样下去,时间长得一批,用户发现我买个东西你特么要花几十秒,垃圾电商我不在你这里买了,不过要是都像并夕夕这么便宜,真香

但是我们公司没有夕夕的那个经济实力啊,那只能优化系统了。

Tip:我之前在的电商老东家要求所有接口的RtResponseTime响应时间)在200ms内,超出的全部优化,我现在所负责的系统QPS也是9W+就是抖动一下网络集群都可能炸锅那种,RT基本上都要求在50ms以内。

大家感受一下这个QPS。

嗯不错,链路长了就慢了,那你怎么解决的?

那链路长了就慢了,但是我们发现上面的流程其实可以同时做的呀,你支付成功后,我去校验优惠券的同时我可以去增减积分啊,还可以同时发个短信啊。

那正常的流程我们是没办法实现的呀,怎么办,异步

你对比一下是不是发现,这样子最多只用100毫秒用户知道下单成功了,至于短信你迟几秒发给他他根本不在意是吧。

小伙子我打断你一下,你说了异步,那我用线程,线程池去做不是一样的么?

诶呀,面试官你不要急嘛,我后面还会说到的,骚等。

解耦:

既然面试官这么问了,我就说一下为啥我们不能用线程去做,因为用线程去做,你是不是要写代码?

你一个订单流程,你扣积分,扣优惠券,发短信,扣库存。。。等等这么多业务要调用这么多的接口,每次加一个你要调用一个接口然后还要重新发布系统,写一次两次还好,写多了你就说:老子不干了!

而且真的全部都写在一起的话,不单单是耦合这一个问题,你出问题排查也麻烦,流程里面随便一个地方出问题搞不好会影响到其他的点,小伙伴说我每个流程都try catch不就行了,相信我别这么做,这样的代码就像个定时炸弹💣,你不知道什么时候爆炸,平时不炸偏偏在你做活动的时候炸,你就领个P0故障收拾书包提前回家过年吧。

Tip:P0—PN 是互联网大厂经常用来判定事故等级的机制,P0是最高等级了。

但是你用了消息队列,耦合这个问题就迎刃而解了呀。

哦,帅丙怎么说?

且听我娓娓道来:

你下单了,你就把你支付成功的消息告诉别的系统,他们收到了去处理就好了,你只用走完自己的流程,把自己的消息发出去,那后面要接入什么系统简单,直接订阅你发送的支付成功消息,你支付成功了我监听就好了

那你的流程走完了,你不用管别人是否成功么?比如你下单了积分没加,优惠券没扣怎么办?

问题是个好问题,但是没必要考虑,业务系统本身就是自己的开发人员维护的,你积分扣失败关我下单的什么事情?你管好自己下单系统的就好了。

Tip:话是这么说,但是这其实是用了消息队列的一个缺点,涉及到分布式事务的知识点,我下面会提到。

削峰:

就拿我上一期写的秒杀来说(暗示新同学看我上一期),你平时流量很低,但是你要做秒杀活动00 :00的时候流量疯狂怼进来,你的服务器,RedisMySQL各自的承受能力都不一样,你直接全部流量照单全收肯定有问题啊,直接就打挂了。

那怎么办?

简单,把请求放到队列里面,然后至于每秒消费多少请求,就看自己的服务器处理能力,你能处理5000QPS你就消费这么多,可能会比正常的慢一点,但是不至于打挂服务器,等流量高峰下去了,你的服务也就没压力了。

你看阿里双十一12:00的时候这么多流量瞬间涌进去,他有时候是不是会慢一点,但是人家没挂啊,或者降级给你个友好的提示页面,等高峰过去了又是一条好汉了。

为了这个图特意打高一台服务的流量

为了这个图特意打高一台服务的流量

听你说了辣么多,怎么都是好处,那我问你使用了消息队列有啥问题么?

诶,看过前面我写的文章的人才都知道,我经常说的就是,技术是把双刃剑

没错面试官,我使用他是因为他带给我们很多好处,但是使用之后问题也是接踵而至

同样的暖男我呀,也从三个点介绍他主要的缺点:

系统复杂性

本来蛮简单的一个系统,我代码随便写都没事,现在你凭空接入一个中间件在那,我是不是要考虑去维护他,而且使用的过程中是不是要考虑各种问题,比如消息重复消费消息丢失消息的顺序消费等等,反正用了之后就是贼烦。

我插一句嘴,上面的问题(重复消费、消息丢失、顺序消费)你能分别介绍一下,并且说一下分别是怎么解决的么?

**不要!**我都说了敖丙下一章写啥?

其实不是暖男我不想在这里写,这三个问题我想了下,统统都是MQ重点问题,单独拿一个出来就是一篇文章了,篇幅实在太长了,我会在下一章挨个介绍一遍的。

数据一致性

这个其实是分布式服务本身就存在的一个问题,不仅仅是消息队列的问题,但是放在这里说是因为用了消息队列这个问题会暴露得比较严重一点。

就像我开头说的,你下单的服务自己保证自己的逻辑成功处理了,你成功发了消息,但是优惠券系统,积分系统等等这么多系统,他们成功还是失败你就不管了?

我说了保证自己的业务数据对的就好了,其实还是比较不负责任的一种说法,这样就像个渣男,没有格局这样呀你的路会越走越窄的

所有的服务都成功才能算这一次下单是成功的,那怎么才能保证数据一致性呢?

分布式事务:把下单,优惠券,积分。。。都放在一个事务里面一样,要成功一起成功,要失败一起失败。

Tip:分布式事务在互联网公司里面实在常见,我也不在这里大篇幅介绍了,后面都会专门说的。

可用性

你搞个系统本身没啥问题,你现在突然接入一个中间件在那放着,万一挂了怎么办?我下个单MQ挂了,优惠券不扣了,积分不减了,这不是杀一个程序员能搞定的吧,感觉得杀一片。

至于怎么保证高可用,还是那句话也不在这里展开讨论了,我后面一样会写,像写Redis那样写出来的。

放心敖丙我不是渣男来的,我肯定会对你们负责的。点赞!

看不出来啊,你有点东西呀,那我问一下你,你们是怎么做技术选型的?

目前在市面上比较主流的消息队列中间件主要有,Kafka、ActiveMQ、RabbitMQ、RocketMQ 等这几种。

不过敖丙我想说的是,ActiveMQRabbitMQ这两着因为吞吐量还有GitHub的社区活跃度的原因,在各大互联网公司都已经基本上绝迹了,业务体量一般的公司会是有在用的,但是越来越多的公司更青睐RocketMQ这样的消息中间件了。

KafkaRocketMQ一直在各自擅长的领域发光发亮,不过写这篇文章的时候我问了蚂蚁金服,字节跳动和美团的朋友,好像大家用的都有点不一样,应该都是各自的中间件,可能做过修改,也可能是自研的,大多没有开源

就像我们公司就是是基于KafkaRocketMQ两者的优点自研的消息队列中间件,吞吐量、可靠性、时效性等都很可观。

我们回归正题,我这里用网上找的对比图让大家看看差距到底在哪里:

大家其实一下子就能看到差距了,就拿吞吐量来说,早期比较活跃的ActiveMQRabbitMQ基本上不是后两者的对手了,在现在这样大数据的年代吞吐量是真的很重要

比如现在突然爆发了一个超级热点新闻,你的APP注册用户高达亿数,你要想办法第一时间把突发全部推送到每个人手上,你没有大吞吐量的消息队列中间件用啥去推?

再说这些用户大量涌进来看了你的新闻产生了一系列的附带流量,你怎么应对这些数据,很多场景离开消息队列基本上难以为继

部署方式而言前两者也是大不如后面两个天然分布式架构的哥哥,都是高可用的分布式架构,而且数据多个副本的数据也能做到0丢失。

我们再聊一下RabbitMQ这个中间件其实还行,但是这玩意开发语言居然是erlang,我敢说绝大部分工程师肯定不会为了一个中间件去刻意学习一门语言的,开发维护成本你想都想不到,出个问题查都查半天。

至于RocketMQ(阿里开源的),git活跃度还可以。基本上你push了自己的bug确认了有问题都有阿里大佬跟你试试解答并修复的,我个人推荐的也是这个,他的架构设计部分跟同样是阿里开源的一个RPC框架是真的很像(Dubbo)可能是因为师出同门的原因吧。

Tip:Dubbo等我写到RPC我会详细介绍的。

Kafka我放到最后说,你们也应该知道了,压轴的这是个大哥,大数据领域,公司的日志采集,实时计算等场景,都离不开他的身影,他基本上算得上是世界范围级别的消息队列标杆了。

以上这些都只是一些我自己的个人意见,真正的选型还是要去深入研究的,不然那你公司一天UV就1000你告诉我你要去用Kafka我只能说你吃饱撑的。

记住,没有最好的技术,只有最适合的技术,不要为了用而用

面试结束

嗯,小伙子不错不错,分析得很到位,那你记得下期来说一下消息队列的高可用,重复消费、消息丢失、消息顺序、分布式事务等问题?

嗯嗯好的面试官,不过不确定能不能一口气说完,毕竟敖丙还没开始写,而且读者还有可能白嫖,动力不一定够。

嗯嗯这倒是个问题,不过啊在看的都是人才肯定会给你点赞👍的!

我也这么认为。

总结

消息队列的基础知识我就先介绍这么多,消息队列在面试里面基本上也是跟我前面写的Redis一样必问的。

面试的思路还是一样,要知其然,也要知其所以然,就是要知道为啥用,用了有啥好处,有啥坑。

面试官不喜欢只知道用的,你只会用那哪天线上出问题怎么办?你难道在旁边拜佛?

我是敖丙,一个在互联网苟且偷生的工具人。

创作不易,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见!

查看原文

赞 75 收藏 30 评论 3

敖丙 发布了文章 · 5月18日

死磕synchronized底层实现

前言

多线程的东西很多,也很有意思,所以我最近的重心可能都是多线程的方向去靠了,不知道大家喜欢否?

阅读本文之前阅读以下两篇文章会帮助你更好的理解:

Volatile

乐观锁&悲观锁

正文

场景

我们正常去使用Synchronized一般都是用在下面这几种场景:

  • 修饰实例方法,对当前实例对象this加锁

    public class Synchronized {
        public synchronized void husband(){
    
        }
    }
  • 修饰静态方法,对当前类的Class对象加锁

    public class Synchronized {
        public void husband(){
            synchronized(Synchronized.class){
    
            }
        }
    }
  • 修饰代码块,指定一个加锁的对象,给对象加锁

    public class Synchronized {
        public void husband(){
            synchronized(new test()){
    
            }
        }
    }

其实就是锁方法、锁代码块和锁对象,那他们是怎么实现加锁的呢?

在这之前,我就先跟大家聊一下我们Java对象的构成

在 JVM 中,对象在内存中分为三块区域:

  • 对象头

    • Mark Word(标记字段):默认存储对象的HashCode,分代年龄和锁标志位信息。它会根据对象的状态复用自己的存储空间,也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。
    • Klass Point(类型指针):对象指向它的类元数据的指针,虚拟机通过这个指针来确定这个对象是哪个类的实例。
  • 实例数据

    • 这部分主要是存放类的数据信息,父类的信息。
  • 对其填充

    • 由于虚拟机要求对象起始地址必须是8字节的整数倍,填充数据不是必须存在的,仅仅是为了字节对齐。

      Tip:不知道大家有没有被问过一个空对象占多少个字节?就是8个字节,是因为对齐填充的关系哈,不到8个字节对其填充会帮我们自动补齐。

我们经常说到的,有序性、可见性、原子性,synchronized又是怎么做到的呢?

有序性

我在Volatile章节已经说过了CPU会为了优化我们的代码,会对我们程序进行重排序。

as-if-serial

不管编译器和CPU如何重排序,必须保证在单线程情况下程序的结果是正确的,还有就是有数据依赖的也是不能重排序的。

就比如:

int a = 1;
int b = a;

这两段是怎么都不能重排序的,b的值依赖a的值,a如果不先赋值,那就为空了。

可见性

同样在Volatile章节我介绍到了现代计算机的内存结构,以及JMM(Java内存模型),这里我需要说明一下就是JMM并不是实际存在的,而是一套规范,这个规范描述了很多java程序中各种变量(线程共享变量)的访问规则,以及在JVM中将变量存储到内存和从内存中读取变量这样的底层细节,Java内存模型是对共享数据的可见性、有序性、和原子性的规则和保障。

大家感兴趣,也记得去了解计算机的组成部分,cpu、内存、多级缓存等,会帮助更好的理解java这么做的原因。

原子性

其实他保证原子性很简单,确保同一时间只有一个线程能拿到锁,能够进入代码块这就够了。

这几个是我们使用锁经常用到的特性,那synchronized他自己本身又具有哪些特性呢?

可重入性

synchronized锁对象的时候有个计数器,他会记录下线程获取锁的次数,在执行完对应的代码块之后,计数器就会-1,直到计数器清零,就释放锁了。

那可重入有什么好处呢?

可以避免一些死锁的情况,也可以让我们更好封装我们的代码。

不可中断性

不可中断就是指,一个线程获取锁之后,另外一个线程处于阻塞或者等待状态,前一个不释放,后一个也一直会阻塞或者等待,不可以被中断。

值得一提的是,Lock的tryLock方法是可以被中断的。

底层实现

这里看实现很简单,我写了一个简单的类,分别有锁方法和锁代码块,我们反编译一下字节码文件,就可以了。

先看看我写的测试类:

/**
 *@Description: Synchronize
 *@Author: 敖丙
 *@date: 2020-05-17
 **/
public class Synchronized {
    public synchronized void husband(){
        synchronized(new Volatile()){

        }
    }
}

编译完成,我们去对应目录执行 javap -c xxx.class 命令查看反编译的文件:

MacBook-Pro-3:juc aobing$ javap -p -v -c Synchronized.class
Classfile /Users/aobing/IdeaProjects/Thanos/laogong/target/classes/juc/Synchronized.class
  Last modified 2020-5-17; size 375 bytes
  MD5 checksum 4f5451a229e80c0a6045b29987383d1a
  Compiled from "Synchronized.java"
public class juc.Synchronized
  minor version: 0
  major version: 49
  flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
   #1 = Methodref          #3.#14         // java/lang/Object."<init>":()V
   #2 = Class              #15            // juc/Synchronized
   #3 = Class              #16            // java/lang/Object
   #4 = Utf8               <init>
   #5 = Utf8               ()V
   #6 = Utf8               Code
   #7 = Utf8               LineNumberTable
   #8 = Utf8               LocalVariableTable
   #9 = Utf8               this
  #10 = Utf8               Ljuc/Synchronized;
  #11 = Utf8               husband
  #12 = Utf8               SourceFile
  #13 = Utf8               Synchronized.java
  #14 = NameAndType        #4:#5          // "<init>":()V
  #15 = Utf8               juc/Synchronized
  #16 = Utf8               java/lang/Object
{
  public juc.Synchronized();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."<init>":()V
         4: return
      LineNumberTable:
        line 8: 0
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0       5     0  this   Ljuc/Synchronized;

  public synchronized void husband();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED  // 这里
    Code:
      stack=2, locals=3, args_size=1
         0: ldc           #2                  // class juc/Synchronized
         2: dup
         3: astore_1
         4: monitorenter   // 这里
         5: aload_1
         6: monitorexit    // 这里
         7: goto          15
        10: astore_2
        11: aload_1
        12: monitorexit    // 这里
        13: aload_2
        14: athrow
        15: return
      Exception table:
         from    to  target type
             5     7    10   any
            10    13    10   any
      LineNumberTable:
        line 10: 0
        line 12: 5
        line 13: 15
      LocalVariableTable:
        Start  Length  Slot  Name   Signature
            0      16     0  this   Ljuc/Synchronized;
}
SourceFile: "Synchronized.java"

同步代码

大家可以看到几处我标记的,我在最开始提到过对象头,他会关联到一个monitor对象。

  • 当我们进入一个人方法的时候,执行monitorenter,就会获取当前对象的一个所有权,这个时候monitor进入数为1,当前的这个线程就是这个monitor的owner。
  • 如果你已经是这个monitor的owner了,你再次进入,就会把进入数+1.
  • 同理,当他执行完monitorexit,对应的进入数就-1,直到为0,才可以被其他线程持有。

所有的互斥,其实在这里,就是看你能否获得monitor的所有权,一旦你成为owner就是获得者。

同步方法

不知道大家注意到方法那的一个特殊标志位没,ACC_SYNCHRONIZED

同步方法的时候,一旦执行到这个方法,就会先判断是否有标志位,然后,ACC_SYNCHRONIZED会去隐式调用刚才的两个指令:monitorenter和monitorexit。

所以归根究底,还是monitor对象的争夺。

monitor

我说了这么多次这个对象,大家是不是以为就是个虚无的东西,其实不是,monitor监视器源码是C++写的,在虚拟机的ObjectMonitor.hpp文件中。

我看了下源码,他的数据结构长这样:

  ObjectMonitor() {
    _header       = NULL;
    _count        = 0;
    _waiters      = 0,
    _recursions   = 0;  // 线程重入次数
    _object       = NULL;  // 存储Monitor对象
    _owner        = NULL;  // 持有当前线程的owner
    _WaitSet      = NULL;  // wait状态的线程列表
    _WaitSetLock  = 0 ;
    _Responsible  = NULL ;
    _succ         = NULL ;
    _cxq          = NULL ;  // 单向列表
    FreeNext      = NULL ;
    _EntryList    = NULL ;  // 处于等待锁状态block状态的线程列表
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ;
    _previous_owner_tid = 0;
  }

这块c++代码,我也放到了我的开源项目了,大家自行查看。

synchronized底层的源码就是引入了ObjectMonitor,这一块大家有兴趣可以看看,反正我上面说的,还有大家经常听到的概念,在这里都能找到源码。

大家说熟悉的锁升级过程,其实就是在源码里面,调用了不同的实现去获取获取锁,失败就调用更高级的实现,最后升级完成。

1.5 重量级锁

大家在看ObjectMonitor源码的时候,会发现Atomic::cmpxchg_ptr,Atomic::inc_ptr等内核函数,对应的线程就是park()和upark()。

这个操作涉及用户态和内核态的转换了,这种切换是很耗资源的,所以知道为啥有自旋锁这样的操作了吧,按道理类似死循环的操作更费资源才是对吧?其实不是,大家了解一下就知道了。

那用户态和内核态又是啥呢?

Linux系统的体系结构大家大学应该都接触过了,分为用户空间(应用程序的活动空间)和内核。

我们所有的程序都在用户空间运行,进入用户运行状态也就是(用户态),但是很多操作可能涉及内核运行,比我I/O,我们就会进入内核运行状态(内核态)。

这个过程是很复杂的,也涉及很多值的传递,我简单概括下流程:

  1. 用户态把一些数据放到寄存器,或者创建对应的堆栈,表明需要操作系统提供的服务。
  2. 用户态执行系统调用(系统调用是操作系统的最小功能单位)。
  3. CPU切换到内核态,跳到对应的内存指定的位置执行指令。
  4. 系统调用处理器去读取我们先前放到内存的数据参数,执行程序的请求。
  5. 调用完成,操作系统重置CPU为用户态返回结果,并执行下个指令。

所以大家一直说,1.6之前是重量级锁,没错,但是他重量的本质,是ObjectMonitor调用的过程,以及Linux内核的复杂运行机制决定的,大量的系统资源消耗,所以效率才低。

还有两种情况也会发生内核态和用户态的切换:异常事件和外围设备的中断 大家也可以了解下。

1.6 优化锁升级

那都说过了效率低,官方也是知道的,所以他们做了升级,大家如果看了我刚才提到的那些源码,就知道他们的升级其实也做得很简单,只是多了几个函数调用,不过不得不设计还是很巧妙的。

我们就来看一下升级后的锁升级过程:

简单版本:

升级方向:

Tip:切记这个升级过程是不可逆的,最后我会说明他的影响,涉及使用场景。

看完他的升级,我们就来好好聊聊每一步怎么做的吧。

偏向锁

之前我提到过了,对象头是由Mark Word和Klass pointer 组成,锁争夺也就是对象头指向的Monitor对象的争夺,一旦有线程持有了这个对象,标志位修改为1,就进入偏向模式,同时会把这个线程的ID记录在对象的Mark Word中。

这个过程是采用了CAS乐观锁操作的,每次同一线程进入,虚拟机就不进行任何同步的操作了,对标志位+1就好了,不同线程过来,CAS会失败,也就意味着获取锁失败。

偏向锁在1.6之后是默认开启的,1.5中是关闭的,需要手动开启参数是xx:-UseBiasedLocking=false。

偏向锁关闭,或者多个线程竞争偏向锁怎么办呢?

轻量级锁

还是跟Mark Work 相关,如果这个对象是无锁的,jvm就会在当前线程的栈帧中建立一个叫锁记录(Lock Record)的空间,用来存储锁对象的Mark Word 拷贝,然后把Lock Record中的owner指向当前对象。

JVM接下来会利用CAS尝试把对象原本的Mark Word 更新会Lock Record的指针,成功就说明加锁成功,改变锁标志位,执行相关同步操作。

如果失败了,就会判断当前对象的Mark Word是否指向了当前线程的栈帧,是则表示当前的线程已经持有了这个对象的锁,否则说明被其他线程持有了,继续锁升级,修改锁的状态,之后等待的线程也阻塞。

自旋锁

我不是在上面提到了Linux系统的用户态和内核态的切换很耗资源,其实就是线程的等待唤起过程,那怎么才能减少这种消耗呢?

自旋,过来的现在就不断自旋,防止线程被挂起,一旦可以获取资源,就直接尝试成功,直到超出阈值,自旋锁的默认大小是10次,-XX:PreBlockSpin可以修改。

自旋都失败了,那就升级为重量级的锁,像1.5的一样,等待唤起咯。

至此我基本上吧synchronized的前后概念都讲到了,大家好好消化。

资料参考:《高并发编程》《黑马程序员讲义》《深入理解JVM虚拟机》

用synchronized还是Lock呢?

我们先看看他们的区别:

  • synchronized是关键字,是JVM层面的底层啥都帮我们做了,而Lock是一个接口,是JDK层面的有丰富的API。
  • synchronized会自动释放锁,而Lock必须手动释放锁。
  • synchronized是不可中断的,Lock可以中断也可以不中断。
  • 通过Lock可以知道线程有没有拿到锁,而synchronized不能。
  • synchronized能锁住方法和代码块,而Lock只能锁住代码块。
  • Lock可以使用读锁提高多线程读效率。
  • synchronized是非公平锁,ReentrantLock可以控制是否是公平锁。

两者一个是JDK层面的一个是JVM层面的,我觉得最大的区别其实在,我们是否需要丰富的api,还有一个我们的场景。

比如我现在是滴滴,我早上有打车高峰,我代码使用了大量的synchronized,有什么问题?锁升级过程是不可逆的,过了高峰我们还是重量级的锁,那效率是不是大打折扣了?这个时候你用Lock是不是很好?

场景是一定要考虑的,我现在告诉你哪个好都是扯淡,因为脱离了业务,一切技术讨论都没有了价值。

我git上的脑图我每次写完我都会重新更新,大家可以没事去看看。

我是敖丙,一个在互联网苟且偷生的工具人。

你知道的越多,你不知道的越多人才们的 【三连】 就是丙丙创作的最大动力,我们下期见!

注:如果本篇博客有任何错误和建议,欢迎人才们留言!

查看原文

赞 24 收藏 15 评论 0

敖丙 发布了文章 · 5月7日

面试官没想到一个Volatile,我都能跟他扯半小时

Volatile可能是面试里面必问的一个话题吧,对他的认知很多朋友也仅限于会用阶段,今天我们换个角度去看看。

先来跟着丙丙来看一段demo的代码

你会发现,永远都不会输出有点东西这一段代码,按道理线程改了flag变量,主线程也能访问到的呀?

为会出现这个情况呢?那我们就需要聊一下另外一个东西了。

JMM(JavaMemoryModel)

JMM:Java内存模型,是java虚拟机规范中所定义的一种内存模型,Java内存模型是标准化的,屏蔽掉了底层不同计算机的区别(注意这个跟JVM完全不是一个东西,只有还有小伙伴搞错的)。

那正式聊之前,丙丙先大概科普一下现代计算机的内存模型吧。

现代计算机的内存模型

其实早期计算机中cpu和内存的速度是差不多的,但在现代计算机中,cpu的指令速度远超内存的存取速度,由于计算机的存储设备与处理器的运算速度有几个数量级的差距,所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存(Cache)来作为内存与处理器之间的缓冲。

将运算需要使用到的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步回内存之中,这样处理器就无须等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾,但是也为计算机系统带来更高的复杂度,因为它引入了一个新的问题:缓存一致性(CacheCoherence)

在多处理器系统中,每个处理器都有自己的高速缓存,而它们又共享同一主内存(MainMemory)。

然后我们可以聊一下JMM了。

JMM

Java内存模型(JavaMemoryModel)描述了Java程序中各种变量(线程共享变量)的访问规则,以及在JVM中将变量,存储到内存和从内存中读取变量这样的底层细节。

JMM有以下规定:

所有的共享变量都存储于主内存,这里所说的变量指的是实例变量和类变量,不包含局部变量,因为局部变量是线程私有的,因此不存在竞争问题。

每一个线程还存在自己的工作内存,线程的工作内存,保留了被线程使用的变量的工作副本。

线程对变量的所有的操作(读,取)都必须在工作内存中完成,而不能直接读写主内存中的变量

不同线程之间也不能直接访问对方工作内存中的变量,线程间变量的值的传递需要通过主内存中转来完成。

本地内存和主内存的关系:

正是因为这样的机制,才导致了可见性问题的存在,那我们就讨论下可见性的解决方案。

可见性的解决方案

加锁

为啥加锁可以解决可见性问题呢?

因为某一个线程进入synchronized代码块前后,线程会获得锁,清空工作内存,从主内存拷贝共享变量最新的值到工作内存成为副本,执行代码,将修改后的副本的值刷新回主内存中,线程释放锁。

而获取不到锁的线程会阻塞等待,所以变量的值肯定一直都是最新的。

Volatile修饰共享变量

开头的代码优化完之后应该是这样的:

Volatile做了啥?

每个线程操作数据的时候会把数据从主内存读取到自己的工作内存,如果他操作了数据并且写会了,他其他已经读取的线程的变量副本就会失效了,需要都数据进行操作又要再次去主内存中读取了。

volatile保证不同线程对共享变量操作的可见性,也就是说一个线程修改了volatile修饰的变量,当修改写回主内存时,另外一个线程立即看到最新的值。

是不是看着加一个关键字很简单,但实际上他在背后含辛茹苦默默付出了不少,我从计算机层面的缓存一致性协议解释一下这些名词的意义。

之前我们说过当多个处理器的运算任务都涉及同一块主内存区域时,将可能导致各自的缓存数据不一致,举例说明变量在多个CPU之间的共享。

如果真的发生这种情况,那同步回到主内存时以谁的缓存数据为准呢?

为了解决一致性的问题,需要各个处理器访问缓存时都遵循一些协议,在读写时要根据协议来进行操作,这类协议有MSI、MESI(IllinoisProtocol)、MOSI、Synapse、Firefly及DragonProtocol等。

聊一下Intel的MESI吧

MESI(缓存一致性协议)

当CPU写数据时,如果发现操作的变量是共享变量,即在其他CPU中也存在该变量的副本,会发出信号通知其他CPU将该变量的缓存行置为无效状态,因此当其他CPU需要读取这个变量时,发现自己缓存中缓存该变量的缓存行是无效的,那么它就会从内存重新读取。

至于是怎么发现数据是否失效呢?

嗅探

每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了,当处理器发现自己缓存行对应的内存地址被修改,就会将当前处理器的缓存行设置成无效状态,当处理器对这个数据进行修改操作的时候,会重新从系统内存中把数据读到处理器缓存里。

img

img

嗅探的缺点不知道大家发现了没有?

总线风暴

由于Volatile的MESI缓存一致性协议,需要不断的从主内存嗅探和cas不断循环,无效交互会导致总线带宽达到峰值。

所以不要大量使用Volatile,至于什么时候去使用Volatile什么时候使用锁,根据场景区分。

我们再来聊一下指令重排序的问题

禁止指令重排序

什么是重排序?

为了提高性能,编译器和处理器常常会对既定的代码执行顺序进行指令重排序。

重排序的类型有哪些呢?源码到最终执行会经过哪些重排序呢?

一个好的内存模型实际上会放松对处理器和编译器规则的束缚,也就是说软件技术和硬件技术都为同一个目标,而进行奋斗:在不改变程序执行结果的前提下,尽可能提高执行效率。

JMM对底层尽量减少约束,使其能够发挥自身优势。

因此,在执行程序时,为了提高性能,编译器和处理器常常会对指令进行重排序。

一般重排序可以分为如下三种:

  • 编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序;
  • 指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序;
  • 内存系统的重排序。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行的。

这里还得提一个概念,as-if-serial

as-if-serial

不管怎么重排序,单线程下的执行结果不能被改变。

编译器、runtime和处理器都必须遵守as-if-serial语义。

那Volatile是怎么保证不会被执行重排序的呢?

内存屏障

java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。

为了实现volatile的内存语义,JMM会限制特定类型的编译器和处理器重排序,JMM会针对编译器制定volatile重排序规则表:

需要注意的是:volatile写是在前面和后面分别插入内存屏障,而volatile读操作是在后面插入两个内存屏障

上面的我提过重排序原则,为了提高处理速度,JVM会对代码进行编译优化,也就是指令重排序优化,并发编程下指令重排序会带来一些安全隐患:如指令重排序导致的多个线程操作之间的不可见性。

如果让程序员再去了解这些底层的实现以及具体规则,那么程序员的负担就太重了,严重影响了并发编程的效率。

从JDK5开始,提出了happens-before的概念,通过这个概念来阐述操作之间的内存可见性。

happens-before

如果一个操作执行的结果需要对另一个操作可见,那么这两个操作之间必须存在happens-before关系。

volatile域规则:对一个volatile域的写操作,happens-before于任意线程后续对这个volatile域的读。

如果现在我的变了falg变成了false,那么后面的那个操作,一定要知道我变了。

聊了这么多,我们要知道Volatile是没办法保证原子性的,一定要保证原子性,可以使用其他方法。

无法保证原子性

就是一次操作,要么完全成功,要么完全失败。

假设现在有N个线程对同一个变量进行累加也是没办法保证结果是对的,因为读写这个过程并不是原子性的。

要解决也简单,要么用原子类,比如AtomicInteger,要么加锁(记得关注Atomic的底层)。

应用

单例有8种写法,我说一下里面比较特殊的一种,涉及Volatile的。

大家可能好奇为啥要双重检查?如果不用Volatile会怎么样?

我先讲一下禁止指令重排序的好处。

对象实际上创建对象要进过如下几个步骤:

  • 分配内存空间。
  • 调用构造器,初始化实例。
  • 返回地址给引用

上面我不是说了嘛,是可能发生指令重排序的,那有可能构造函数在对象初始化完成前就赋值完成了,在内存里面开辟了一片存储区域后直接返回内存的引用,这个时候还没真正的初始化完对象。

但是别的线程去判断instance!=null,直接拿去用了,其实这个对象是个半成品,那就有空指针异常了。

可见性怎么保证的?

因为可见性,线程A在自己的内存初始化了对象,还没来得及写回主内存,B线程也这么做了,那就创建了多个对象,不是真正意义上的单例了。

上面提到了volatile与synchronized,那我聊一下他们的区别。

volatile与synchronized的区别

volatile只能修饰实例变量和类变量,而synchronized可以修饰方法,以及代码块。

volatile保证数据的可见性,但是不保证原子性(多线程进行写操作,不保证线程安全);而synchronized是一种排他(互斥)的机制。 volatile用于禁止指令重排序:可以解决单例双重检查对象初始化代码执行乱序问题。

volatile可以看做是轻量版的synchronized,volatile不保证原子性,但是如果是对一个共享变量进行多个线程的赋值,而没有其他的操作,那么就可以用volatile来代替synchronized,因为赋值本身是有原子性的,而volatile又保证了可见性,所以就可以保证线程安全了。

总结

  1. volatile修饰符适用于以下场景:某个属性被多个线程共享,其中有一个线程修改了此属性,其他线程可以立即得到修改后的值,比如booleanflag;或者作为触发器,实现轻量级同步。
  2. volatile属性的读写操作都是无锁的,它不能替代synchronized,因为它没有提供原子性和互斥性。因为无锁,不需要花费时间在获取锁和释放锁_上,所以说它是低成本的。
  3. volatile只能作用于属性,我们用volatile修饰属性,这样compilers就不会对这个属性做指令重排序。
  4. volatile提供了可见性,任何一个线程对其的修改将立马对其他线程可见,volatile属性不会被线程缓存,始终从主 存中读取。
  5. volatile提供了happens-before保证,对volatile变量v的写入happens-before所有其他线程后续对v的读操作。
  6. volatile可以使得long和double的赋值是原子的。
  7. volatile可以在单例双重检查中实现可见性和禁止指令重排序,从而保证安全性。

注:以上所有的内容如果能全部掌握我想Volatile在面试官那是很加分了,但是我还没讲到很多关于计算机内存那一块的底层,那大家就需要后面去补课了,如果等得及,也可以等到我写计算机基础章节。

絮叨

img

因为更新文章和视频,丙丙已经半年多的周末没休息了,都是在公司那个工位冲冲冲,一直想找时间出去玩,想着年假一天没用,就请了两天出去玩一下。

这样五一就可以早点回来,准备恢复视频的更新,你在看的时候呢,敖丙应该在出游的列车上了,是的我就背了这个包,到写完的时候,我还没确定去哪里,提前祝大家节日愉快。

我是敖丙,一个在互联网苟且偷生的工具人。

你知道的越多,你不知道的越多人才们的 【三连】 就是丙丙创作的最大动力,我们下期见!

注:如果本篇博客有任何错误和建议,欢迎人才们留言,你快说句话啊

查看原文

赞 14 收藏 7 评论 0