Java程序员面试-场景篇

前言

裁员增效潮滚滚而来，特总结一些实际场景方案的面试题，希望对大家找工作有一些帮助。

注册中心

题目： 有三台机器，分别部署了微服务A、微服务B、注册中心，其中A和B都有服务接口提供并正常注册到了注册中心，A和B之间有依赖调用，当前整个环境在正常运行，如果现在注册中心这台机器断电了，整个环境还是否可用，有哪些影响？

解析： 此题考察对注册中心原理的理解，这里不管注册中心是zookeep还是eureaka都是一样的。部分面试者会反问：注册中心一般会部署多台，不会都死掉的，面试官会强调场景中只有一台，并且部署多台也无法保证不会都出故障，只是概率问题。
首先要想清楚有没有影响，

• 微服务中的消费者是如何知道生产者的IP端口的呢？
  是通过向注册中心问询得知；
• 是什么阶段问的？
  服务启动时
• 生产者增加或减少怎么知道？
  zk是推给消费者更新生产者列表
  eureaka是消费者定时查询生产者列表并更新

答案： 整个环境可用，但如果A或B需要重启，就无法正常运行了。

消息中间件

题目： 有三台机器，分别部署了微服务A、微服务B、消息中间件（比如RockeMQ），现在定义了一条点对点的消息，其中A是生产者、B是消费者，已知A成功生产一条消息，问B有没有可能收到两条消息？

解析： 消息中间件有什么作用，什么场景适合使用这些我向大家在各种面试宝典中已背的滚瓜烂熟，初级程序员还可以蒙混过关，但高级程序员是要独立负责一个子系统的定位，要有一定的技术把控力，你可以不懂具体实现，但你要知道这里有坑。

答案： 有可能，您问为什么有可能，请官方文档说明：

什么叫至少，什么是大多数就不用我多解释了吧。有同学会问那其他的消息中间件呢，其实都是一样的产品规格，这是通用规格，并非RocketMQ一家缩水。

解决方案

题目： 公司有个一个官网，是N年前开发的，伴随者客户访问量的增长，运行缓慢，请给出一个优化方案？

解析： 这个案例在公司中发生的概率很高，是考你解决问题的整体思路是否有，或者说有没有方法论，回答的不同能反映出你不同的经历，知识结构等等。

答案： 一个老法师的回答：

1. 看病先诊脉，公司是否有链路追踪等监控系统，如果没有建议接入sky-walking看最大的病因在哪里。
2. 根据我几年积累的经验有以下几种优化的策略：
   动静分离： 动态服务器（比如Tomcat\Jboss）处理静态资源的效率很低，可以分离使用Nginx部署静态资源。
   分级缓存： 本地缓存+Redis缓存 当然通常用Redis就够了
   消峰解耦： 结合具体业务可以利用消息中间件进行消峰解耦。

题目： 现在我们公司要提供一个服务接口给第三方调用，如何保障通信安全？

解析： 这个问题是旨在考察面试者的知识储备，是否在工作中对加解密问题进行过自己的理解和思考或是学习。

答案：首先通信协议约定为https，设置网络白名单，当然以上是防君子难防小人，要想安全还要采用非对称方式进行签名，保证通讯的安全性。

题目： 我司现有一个手机充值业务，业务模式如下： 商户预充值到我司电子账户，我司提供手机充值接口，比如入参商户号、手机号、充值金额、签名，出参： 是否成功。收到充值请求后，处理流程如下：

1. 检查商户是否在黑明单
2. 检查商户的账户状态是否冻结
3. 检查商户的电子账户余额是否充足
4. 加锁
5. 电子账户余额扣减
6. 调用第三方接口对手机号充值
7. 释放锁

大部分商户都运转正常，但其中一个大商户，部署终端比较多，反馈经常卡顿，请分析可能是什么原因导致，如何进行优化提升性能？

解析： 这个一个比较开放的题目，旨在考察面试者的实际应用经验，面对一个具体业务场景，能否找到关键问题，并给出一些行之有效的解决方案

答案：

1. 产生的原因
   大概率是加锁导致的， 大部分商户没有产生问题是因为他们的并发量小，锁冲突的概率小，而大商户的业务量大，这个锁就成了业务瓶颈。
2. 优化可以考虑以下几个方面
   大商户都是我们的重要客户，一般都具有良好的资质，既然有黑名单，是不是可以有白名单或大客户名单，对白名单客户，1-3的检查项进行简化。
   大商户的电子账户可以设计成多个，可以把资金分散到多个子账户上，这个余额扣减就可以分散了，等同小商户。
   加锁的范围有点大了，还包含调用第三方充值接口，其实没有必要，这部分可以放到锁的外部。

题目： 假定现在有一张余额表，用于存储所有电子账户的余额数据，关键字段如下：

英文	数据类型	中文
account_no	String	账号 pk
amount	Decimal	余额

现在需要提供一个转账接口，具体规格如下：
请求

英文	数据类型	中文
from_account_no	String	来源账号
to_account_no	String	目标账号
trans_amount	Decimal	转账金额

响应

英文	数据类型	中文
code	String	响应码
message	String	响应消息
data	Boolean	是否成功

请说明此接口具体如何实现，需要注意哪些问题？

场景复现：
小范：先扣钱，再加钱，保障整体的事务一致性，资金安全最重要。
爷叔：那你具体说下怎么保障一致性？

小范：就用synchronized关键字好了，简单方便，搞定。
爷叔：你说的这个是可以，但是我们是生产环境不会是一个节点，至少有两个节点，还能安全吗？

小范：两个节点呀，那换分布式锁，加好锁就先查一把from账户钱够不够，不够就失败，够用就扣from，加to,然后释放锁，结束。
爷叔：分布式锁你选哪个中间件来做？

小范：Redis
爷叔：主备、哨兵还是cluster？

小范：都什么年代了，现在一般都上云，一步到位，就选cluster.
爷叔：年轻人敢拼敢闯是好事，但我问你这样你的分布式锁有没有被击穿的可能？

小范：cluster是高可用模式，不会发生。
爷叔：要是发生脑裂呢？

小范：额 。。。 这个似乎听说过，确实有击穿的概率，不过嘛，小概率事件，忽略。
爷叔：这个是资金处理，容不得半点马虎，小概率不是没概率，墨菲定律听过伐，细节决定成败。

答案：资金处理，这是要保障资金安全为第一要务，锁用什么来实现，不要犹豫数据库行级锁。千万不要不考虑场景，分布式锁脱口而出。

结束语

2023年刚刚过去，伴随着经济周期的变化，国际关系的动荡，越来越多的公司认清了现实，保留子弹，活下去才是硬道理。朋友圈子不断传来公司裁员的消息，但却少有招人的公司，市场供需严重失调，活下去才是硬道理，天行健，君子当自强不息，与君共勉。