前言
裁员增效潮滚滚而来,特总结一些实际场景方案的面试题,希望对大家找工作有一些帮助。
注册中心
题目: 有三台机器,分别部署了微服务A、微服务B、注册中心,其中A和B都有服务接口提供并正常注册到了注册中心,A和B之间有依赖调用,当前整个环境在正常运行,如果现在注册中心这台机器断电了,整个环境还是否可用,有哪些影响?
解析: 此题考察对注册中心原理的理解,这里不管注册中心是zookeep还是eureaka都是一样的。部分面试者会反问:注册中心一般会部署多台,不会都死掉的,面试官会强调场景中只有一台,并且部署多台也无法保证不会都出故障,只是概率问题。
首先要想清楚有没有影响,
- 微服务中的消费者是如何知道生产者的IP端口的呢?
是通过向注册中心问询得知; - 是什么阶段问的?
服务启动时 - 生产者增加或减少怎么知道?
zk是推给消费者更新生产者列表
eureaka是消费者定时查询生产者列表并更新
答案: 整个环境可用,但如果A或B需要重启,就无法正常运行了。
消息中间件
题目: 有三台机器,分别部署了微服务A、微服务B、消息中间件(比如RockeMQ),现在定义了一条点对点的消息,其中A是生产者、B是消费者,已知A成功生产一条消息,问B有没有可能收到两条消息?
解析: 消息中间件有什么作用,什么场景适合使用这些我向大家在各种面试宝典中已背的滚瓜烂熟,初级程序员还可以蒙混过关,但高级程序员是要独立负责一个子系统的定位,要有一定的技术把控力,你可以不懂具体实现,但你要知道这里有坑。
答案: 有可能,您问为什么有可能,请官方文档说明:
什么叫至少,什么是大多数就不用我多解释了吧。有同学会问那其他的消息中间件呢,其实都是一样的产品规格,这是通用规格,并非RocketMQ一家缩水。
解决方案
题目: 公司有个一个官网,是N年前开发的,伴随者客户访问量的增长,运行缓慢,请给出一个优化方案?
解析: 这个案例在公司中发生的概率很高,是考你解决问题的整体思路是否有,或者说有没有方法论,回答的不同能反映出你不同的经历,知识结构等等。
答案: 一个老法师的回答:
- 看病先诊脉,公司是否有链路追踪等监控系统,如果没有建议接入sky-walking看最大的病因在哪里。
- 根据我几年积累的经验有以下几种优化的策略:
动静分离: 动态服务器(比如Tomcat\Jboss)处理静态资源的效率很低,可以分离使用Nginx部署静态资源。
分级缓存: 本地缓存+Redis缓存 当然通常用Redis就够了
消峰解耦: 结合具体业务可以利用消息中间件进行消峰解耦。
题目: 现在我们公司要提供一个服务接口给第三方调用,如何保障通信安全?
解析: 这个问题是旨在考察面试者的知识储备,是否在工作中对加解密问题进行过自己的理解和思考或是学习。
答案:首先通信协议约定为https,设置网络白名单,当然以上是防君子难防小人,要想安全还要采用非对称方式进行签名,保证通讯的安全性。
题目: 我司现有一个手机充值业务,业务模式如下: 商户预充值到我司电子账户,我司提供手机充值接口,比如入参商户号、手机号、充值金额、签名,出参: 是否成功。收到充值请求后,处理流程如下:
- 检查商户是否在黑明单
- 检查商户的账户状态是否冻结
- 检查商户的电子账户余额是否充足
- 加锁
- 电子账户余额扣减
- 调用第三方接口对手机号充值
- 释放锁
大部分商户都运转正常,但其中一个大商户,部署终端比较多,反馈经常卡顿,请分析可能是什么原因导致,如何进行优化提升性能?
解析: 这个一个比较开放的题目,旨在考察面试者的实际应用经验,面对一个具体业务场景,能否找到关键问题,并给出一些行之有效的解决方案
答案:
- 产生的原因
大概率是加锁导致的, 大部分商户没有产生问题是因为他们的并发量小,锁冲突的概率小,而大商户的业务量大,这个锁就成了业务瓶颈。 - 优化可以考虑以下几个方面
大商户都是我们的重要客户,一般都具有良好的资质,既然有黑名单,是不是可以有白名单或大客户名单,对白名单客户,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年刚刚过去,伴随着经济周期的变化,国际关系的动荡,越来越多的公司认清了现实,保留子弹,活下去才是硬道理。朋友圈子不断传来公司裁员的消息,但却少有招人的公司,市场供需严重失调,活下去才是硬道理,天行健,君子当自强不息,与君共勉。