自我介绍一下吧
口试官您好，我是 xxx 大学软件工程的一名大三学生，从大一开始学习前端，产生了对编程的兴趣，大二开始打仗 Java，大二放学期学了 ssm，Spring Boot 等框架，也做了一些项目。后来创造根本很主要，于是从大三开始一贯到现在，一贯在对根本进行学习。比如：JVM，并发，操作系统，网络等。
看你的项目是分布式系统，那你的上游系统调用你的系统时可能会涌现超时的问题，怎么处理?
在我们的系统的话，一样平常有监控平台，要求超时会抛出非常，会触发企业微信邮件告警，开拓职员知道往后去看一下对应的日志中的非常信息。查到详细是调用哪个接口涌现的问题，这个接口里是否调用外部系统，定位问题是外部的还是内部的问题。
那如果你看到的日志便是很多要求，你认为这种是什么问题，在外部系统没有问题的情形下核心线程池被打满了?
我以为可能是有人新改了一个功能并上线，欠妥心写了去世循环导致的 CPU 飘高。
PS：review code 的主要性
您说的线程池爆满的缘故原由是可能一个接口中存在耗时的操作，导致要求这个接口的要求一贯占用线程池，线程池被打满，从而导致后续来的其他接口的要求也会被影响。
这种情形一样平常可以做事降级、限流来处理。
在外部流量没有暴增的情形下，如果你的做事每隔半个小时会涌现做事不可用的情形，这种怎么排查?
它这个是溘然每隔半个小时还是其他情形?
便是这一天 11 点涌现了，往后每隔半小时就会有两分不可用，qps 都保持正常值
我猜这种情形一样平常涌如今，定时任务同步一些数据到其他系统，由于网络的问题，那边做事慢的话就会导致一个超时，然后就会发生这个问题。
正常接管要求，也没有任务跑，你会往哪个方面想?
那它会不会受到支配机器其他做事的影响呢。
没有
想了几分钟…..，这个目前还想不到其他的。
我可以给你个提示，往内存方面想
昂，立马 get 到点，是可能存在内存透露吗？是不是由于存在内存透露导致 full gc，gc 太频繁导致的。
对，那这种问题怎么排查办理
如果内存溢出的话，一样平常可能会有 OOM 抛出，JVM 可以设置参数在涌现 OOM 时 dump 下内存的镜像，然后你可以利用一些剖析工具，剖析这个 dump 文件，有的工具直接可以给你一些优化建议，或者你可以找到哪个类的内存利用情形，找到内存透露的点，去看代码。一样平常是 NIO 引起的，由于 Java 8 开启方法区利用的是元空间，不是永久代了。元空间是本地内存，不是堆内存，不受 JVM 管理，由操作系统管理，以是利用不当可能会涌现内存透露的问题。
好，那下一个问题，你那边用的是 dubbo 把
是
是借鉴 dubbo 开拓的一个 rpc 框架吧
正常 Java 用的是 dubbo，之前是 php，为了 php 和 java 微做事之间的跨措辞调用，实现了一个跨措辞的 rpc，现在已经全部转为 Java 了，都用 dubbo 调用。而且微做事架构方面又做了改进，利用了 Service Mesh，面向云原生。
dubbo 做事的启动、注册流程，说一下
首先，有个做事的供应者启动起来后，会先向做事注册中央注册做事，如果是 zk 的话，它便是在某个 dubbo 的目录下注册高下，其他消费者想调用的话，就从 zk 上把对应的供应者的 ip 地址啥的拉下来缓存起来。然后就可以调用了。
那供应做事的供应者 ip 变动了，消费者是如何动态感知做事供应者的改变呢
一样平常分布式注册做事可以动态感知。如果是 zk 的话，做事供应者在 zk 上注册做事时创建的是临时节点，如果做事 ip 变动了或者做事挂了，做事的调用者通过 zk 的 watch 机制可以监听到做事供应者目录下的节点增加、删除、修正事宜。
你用到了很多行列步队，kafka、rabbitmq 理解吗
我现在这边用的是 nsq 和 kafka，kafka 一样平常是大数据那边离线处理一些东西，nsq 一样平常是告警信息，两个别系之间进行解耦，进行信息交互时，发到 nsq。差异的话，kafka 对大数据处理能力比较好，nsq 的话一样平常作为一个正常的行列步队，同步改异步就可以用 nsq。
既然 Kafka 可以处理大数据，那为什么不用 kafka，而用 nsq 呢？
这个问题我之前想过，问过我的 leader。kafka 一样平常是大数据那边流处理什么的，它那边一样平常都只接管 kafka 的，和大数据集成比较好。至于选 nsq 的话，它是结合当时的业务场景选择的，这个也没有选哪个好哪个坏。
那他当时选型的时候，为什么不用 kafka
由于 kafka 貌似对付延时等支持的不太好，事务这些，它虽然对大数据的处理的好，但是它也有缺漏的地方，它有它的专攻方向，比如：吞吐量方面，但是也有它的不敷之处，就好比打算机中的摩尔定律。一样平常业务系统常须要一些延时就须要用 nsq 了。
根据我的项目问的一些问题
……
有数据库调优履历吗？对付数据库有多索引匹配时，有什么履历吗
这个匹配的话，比如：ABC 三个组合索引，必须要顺序实行，比如 A = 2，C =2 。这个时候就不会实行，由于它毁坏了顺序性。
你说这种情形是完备用不到吗
是的，由于它不知足索引的最左匹配原则。
那比如说，我数据库有多个索引，A，B，BC，一个查询条件 A，B，C 都有，那一样平常怎么查看呢
这个一样平常的话是用 explain 去剖析一下 sql 的实行操持，它会输出可能走的索引，真正走的索引，扫描的行数，额外的花费（extra），用没用临时表等。
那它剖析出来的索引便是数据库一定会用的索引吗
explain 剖析出来的吗
或者说，你以为它 explain 剖析出来的便是最佳的索引吗
一样平常情形下最佳的，数据库会根据你的 sql，通过解析器天生对应的语法剖析树，它对这个树进行一些规则的优化后，会天生一些查询操持，通过基于韶光本钱的剖析算法选出一个尽可能是最佳的查询操持。这个详细合不得当很难说。
你没有碰着建的索引不好，导致走的索引是最差的情形吗
这个一样平常的话，可能是你对索引一无所知，导致一些索引的规则不去遵守，而且数据库索引的匹配规则很多，很随意马虎走坑。如果你的业务一定要走你设置的那个索引，mysql 也可以通过设置逼迫走你设置的某个索引。
你对 Java8 理解吗
理解，由于我现在参与的项目就大量用了 Java8 的特性。比如：stream，lambda 表达式，韶光 API 等。详细运用处景的话，比如你一个接口要返回 VO List 凑集，而你数据库查出来的是 DO List 凑集，这个时候你就可以用凑集的 stream 去做这个转换。比较于传统的写法，代码会变的很大略和清爽。
流式编写代码的好处和坏处可以说一下嘛
好处的话，写代码的效率快了，看着很舒畅。
坏处的话，流式性能不怎么好，并发情形很多的情形下才表示出好。
我以为最紧张的是，之前你自己写的话，就面向过程化了。流式的话，Java8 提倡的是面向函数式编程嘛。编程模型之前最开始是面向过程，然后面向工具，面向元编程，面向切面编程，面向函数式编程，往后 java9 的面向模块化编程。而且把过程封装在函数中，通过函数去转换数据的状态对付线程安全方面也有很大的好处。
如果数据库对一些记录存在热点更新操作，有大量的更新，怎么办理呢
一样平常可以利用多级缓存去办理。如果数据量太猛增的话，你用 redis 客户端访问 redis 做事端都访问不到，由于带宽被打满了嘛。这种情形可以提前去探测某个 key 是不是热点，然后在本地缓存操作。
你怎么即时同步数据给其他人呢
它会有一个算法提前探测某个 key 是否是热点，然后框架会帮你进行本地缓存的管理。
数据库有单热点，那你怎么办理
这种一样平常先做一个缓存，然后可以用行列步队削峰填谷。
操作缓存可能会超时，你怎么担保这个数据的精确性呢？由于你加了缓存呀
对对，这个数据库和缓存保持同等性比较难担保。而且大量数据访问更新，也不能加锁，由于数据库通过行锁担保线程并发安全问题。
我要你办理的便是行锁等待导致的性能被拉低的问题，用缓存也是可以的，但是不能担保 100% 的数据同等性，那我的业务场景便是想要 100% 的数据同等性，你现在有大概的办理思路吗
这个可以用多套数据库主从集群来办理吗？通过这种办法来提升数据库的写性能。让多个集群去抗。数据库中间件可以把流量分散到各个主从集群中的主库上。
可以，这算是一种办理方案，那还有其他办法吗
修正数据库隔离级别也弗成，由于它并发写的时候就会加行锁。
你冲破这个行锁就行了
…… 我再想想。这个 ……
紧张是单条记录引起的，它便是频繁更新引起的。
昂，这个是不是可以……… 我看 JDK 源码，频繁更新它一样平常是：HashMap 是非线程安全的，后来涌现了线程安全版的 HashTable，但是它性能比较差，由于它直接就对全体 hash 表进行了加锁。后来涌现了 CurrentHashMap，涌现了分段锁，降落了锁的粒度，实在便是一种思想，你对一个热点数据的访问的话，便是分而治之，多去搞几个，均摊一下。难道是利用 hash 同等性算法把这些写要求，多分几张表。
差不多吧，思想便是分而治之，只要把单点数据拆分掉，让它变成多条数据，然后去更新多条数据，末了再合成一条。
嗯嗯。现在大数据一样平常也这样，大的搞不动就拆分。
从和你的对话来看，我以为你根本也不错，根本我就不问了，我这边没有什么问题了，我看你这边，演习经历丰富，offer 收的也挺多。你有什么想问的
贵公司的技能栈，还有如果我进去往后所在的产品线。
口试官讲述了他们公司的技能栈和一些业务
口试官对我的一些职业方案的建议
多磨炼自己的技能思维 + 业务思维，可以往业务中台方向走。更好的支持别人的业务，技能紧张做事于技能，要培养业务架构思维。
总结
我以为口试过程中要避免自己一贯在说，可以多和口试官去互动，去问口试官是不是这样子，这样可以避免你理解错口试官的问题。我们的项目可能大部分是 CRUD，但是我们的思维不可以勾留在 CRUD，多去结合业务，也便是结合场景去思考你项目，这可能是一个很大的上风。毕竟技能是用于做事业务，去办理业务需求。
如果喜好本篇文章，欢迎。关注订阅号「Web项目聚拢地」，回答「进群」即进入咱自己的技能互换群。
1.2. 4. 5.6.
在看
