二面项目技术面
主要针对自己最熟悉的项目,画出项目的架构图,主要的数据表结构,项目中使用到的技术点,项目的总峰值qps,时延,以及有没有分析过时延出现的耗时分别出现在什么地方,项目有啥改进的地方没有?如果请求出现问题没有响应,如何定位问题,说下思路?tcp 粘包问题怎么处理?问了下缓存更新的模式,以及会出现的问题和应对思路?除了公司项目之外,业务有没有研究过知名项目或做出过贡献?
基本都没有啥问题,除了面试官说项目经验稍弱之外,其余还不错。
三面综合技术面
这面面的是阵脚大乱,面试官采用刨根问底的方式提问,终究是面试经验不够,导致面试的节奏有点乱。 举个例子:
其中有个题是go程和线程有什么区别?
答:1 起一个go程大概只需要4kb的内存,起一个Java线程需要1.5MB的内存;go程的调度在用户态非常轻量,Java线程的切换成本比较高。接着问为啥成本比较高?因为Java线程的调度需要在用户态和内核态切换所以成本高?为啥在用户态和内核态之间切换调度成本比较高?简单说了下内核态和用户态的定义。接着问,还是没有明白为啥成本高?心里瞬间崩溃,没完没了了呀,OS这块依旧是痛呀,支支吾吾半天放弃了。
后面等等的面试都是这种情况,结果就是回答的节奏全无,差不多都是上面这种形式,基本都能达到一点,但是深入的OS层面就GG了。
后面问了下项目过程中遇到的最大的挑战,以及时怎么解决的?
后面还问了一个问题定位的问题,服务器CPU 100%怎么定位?可能是由于平时定位业务问题的思维定势,加之处于蒙蔽状态,随口就是:先查看监控面板看有无突发流量异常,接着查看业务日志是否有异常,针对针对100%那个时间段,取一个典型业务流程的日志查看。最后才提到使用top命令来监控看是哪个进程占用到100%。果然阵脚大乱,张口就来,捂脸。。。
本来正确的思路应该是先用top定位出问题的进程,再用top定位到出问题的线程,再打印线程堆栈查看运行情况,这个流程换平时肯定能答出来,但是,但是没有但是。还是得好好总结。
最后问了一个系统设计题目(朋友圈的设计),设计系统的架构图,主要的表结构和讲解主要的业务流程,如果流量变大,架构将怎么扩展,怎样应对。
这个答的也有点乱,直接上来自顾自的用了一个通用的架构,感觉毫无亮点。后面反思应该先定位业务的特点,这个业务明显是读多写少,然后和面试官沟通一期刚开始的方案的用户量,性能要求,单机目标qps是什么等,?在明确系统的特点和约束之后再来设计,而不是一开始就是用典型互联网的那种通用架构自己搞自己的。