简历中项目经验这么写(下)

174 阅读10分钟

二、模拟:面试问题

1. 数据质疑

面试官一定会通过简历的项目描述,首先对你所描述内容的一个质疑。因为毕竟面试官是不了解你的,所以会通过质疑的方式来判断这样一个项目是否能有因有果,承上启下,自圆其说。

1.1 这个营销系统是之前就有,你去接手了。还是你从0到1构建的

  • 题目:这个营销系统是之前就有,你去接手了。还是你从0到1构建的。

  • 解答:如果是公司的项目,有几种情况;

    1. 原来有一个抽奖系统,但设计实现上不好满足业务需求,代码维护成本越来越高。所以开始重新架构设计从0开始开发。
    2. 进入公司后,刚是公司开始准备在核心业务上做营销拉量的时候,所以从0开始搭建开发。这个过程中做了大量的技术调研和架构设计评审。
    3. 进入公司后是一个已经存在的项目,为了更好的支撑业务快速迭代,对系统进行重构。设计了新的模块;规则引擎、策略算法【可以多几种抽奖方式】。
  • 画外:几种不同方式的回答,也会牵扯到后续提问中的一些问题点。别回答回答着,前面说从0搭建的,后面解答不上来的问题,又说是其他同事之前遗留的。

1.2 线上是部署的机器数量和规格是什么样,几核几G的机器,部署了多少台?

  • 题目:线上是部署的机器数量和规格是什么样,几核几G的机器,部署了多少台?

  • 解答

    1. 这个回答到不难,但你所描述出的机器数量会牵扯到系统所能承载的峰值流量,比如;通过双机房部署了4台4核8G的服务器。
    2. 同时这里也可能提到服务器带宽问题,像互联网大厂中至少是千兆网卡,核心应用都在万兆网卡。以10M公网宽带举例,下载速度在1.25M/秒 = 1280KB/秒。如果一个网站加载是30KB,那么 1280/30 ≈ 42,也就是10M带宽能支撑42个并发在1秒打开。所以通过你提到的这些数据,面试官也是能粗略估计出应该能在多少流量。

1.3 简历上系统峰值QPS3000,RT1.2s,但你刚说是双机房部署了4台应用实例,这个数据准确吗?

  • 题目:简历上系统峰值QPS3000,RT1.2s,但你刚说是双机房部署了4台应用实例,这个数据准确吗?

  • 解答

    1. 这里有一个基本的公式,并发数 = QPS * RT【响应时间/秒】,那么 QPS 3000 * 1.2秒 = 3600个并发。4台应用实例 * 150【默认tomcat配置】 = 600 并发。虽然这是评估值,甚至 tomcat 也可以配置到 200个并发,但这个值仍与 3600 有较大差异,所以会被质疑。
    2. 这里还会牵扯到数据库的配置,数据库总连接数是多少,每台机器应用实例分配的连接数是多少。所有占用的连接数一定是小于总连接数的,否则连接池被打满,可能会出现几万毫秒的慢查询,直至拖垮数据库,让整个系统崩溃。
    3. 再举例个关于流量评估的场景【28法则】,可以根据这个评估自己的系统QPS;系统有1000万用户,那么每天来点击页面的占比20%,也就是200万用户访问。假设平均每个用户点击50次,那么总用有1亿的PV。一天24个小时,平均活跃时间段算在5个小时内【24*20%】,那么5个小时预计有8000万点击,也就是平均每秒4500个请求。4500是一个均值,按照电商类峰值的话,一般是3~4倍均值量,也就是5个小时每秒18000个请求【QPS=1.8万】
    4. 对于一个真实场景的系统来说,所有的评估数据都只能作为压测配置参考数据。因为接口的逻辑不同,所以也可能倒置并发数的高低。所以像各大互联网在大促前要进行接口的血脉梳理和服务器配置调整,并进行N轮压测和优化,这样才能拿到一个准确的数据。

1.4 抽奖系统 TPS 5000~8000 服务器配置大概情况

  • Redis 集群服务,基本申请个16G就够了,存储信息不多。

  • QPS 约等于 TPS 的8~10倍,有时候不同业务也有不同的情况。

  • 分库分表,解决连接数瓶颈、解决数据增量,通常可能数据存量200万-300万增量在单表50万就会拆了(可能最开始很小,都设计成分库分表,因为分库分表很成熟,不会因为引入后导致开发效率低),因为拆分的库大多数也是虚拟机,并不会浪费多少服务器资源。后续数据量真大了,在迁移物理机。而分库分表后,数据就分散了,不用集中打到某个库表上。

  • TPS 8k 左右,qps 8w 差不多有10台-15台虚拟机就够了,4核8G的。15台虚拟机约等于1台物理机。1台物理机大概64核,2T的。

2. 架构设计

2.1 为什么使用DDD,主要用于解决什么问题?

  • 题目:为什么使用DDD,主要用于解决什么问题?
  • 解答:从软件的复杂度和需求迭代次数来看,最开始的开发成本并不是最大的。因为在长周期迭代中,后期的维护成本才是最大的。那么对于这样的系统来说,更易维护就显得非常重要。而 DDD 恰好以领域为核心设计,分拆业务逻辑为独立的模块,在通过应用层编排的方式对外提供服务,这样更加容易扩展。

2.2 DDD架构和MVC架构有什么区别?

  • 题目:DDD架构和MVC架构有什么区别?

  • MVC:更偏向与数据建模实现,由数据调用驱动,所以也就引申出的DAO、PO、VO类会随着项目开发不断的膨胀,不易于迭代和维护。

  • DDD:以业务流程提炼领域模型为驱动,设计和实现模块开发,在一个领域中包含mode对象、仓储数据、服务实现,也更注重设计模式的使用,否则实现的DDD徒有其表更多的只是归类了 DAO、PO、VO 对象。

2.3 抽奖系统的核心域,支撑域和通用域分别对应哪些呢?

  • 题目:抽奖系统的核心域,支撑域和通用域分别对应哪些呢?

企业微信截图_98187825-70eb-4d8f-a25d-8fb17afb5646.png

3.1 近期用抽奖项目去面试,老被问到有没有线上出现CPU或内存飙高等线上问题,让我说说具体的场景以及如何解决的。

  • 事故级别:P0

  • 事故判责:营销活动推广用户较多,影响范围较大,研发整改代码并做复盘。

  • 事故名称:秒杀方案独占竞态实现问题

  • 事故现象:线上监控突然报警,CPU占用高,拖垮整个服务。用户看到可以购买,但只要一点下单就活动太火爆,换个小手试试。造成了大量客诉,紧急下线活动排查。

  • 事故描述:这个一个商品活动秒杀的实现方案,最开始的设计是基于一个活动号ID进行锁定,秒杀时锁定这个ID,用户购买完后就进行释放。但在大量用户抢购时,出现了秒杀分布式锁后的业务逻辑处理中发生异常,释放锁失败。导致所有的用户都不能再拿到锁,也就造成了有商品但不能下单的问题。 事故处理:优化独占竞态为分段静态,将活动ID+库存编号作为动态锁标识。当前秒杀的用户如果发生锁失败那么后面的用户可以继续秒杀不受影响。而失败的锁会有worker进行补偿恢复,那么最终会避免超卖以及不能售卖。

  • 学习总结: 核心的技术实现需要经过大量的数据验证以及压测,否则各个场景下很难评估是否会有风险。当然这也不是唯一的实现方案,可以根据不同的场景有不同的实现处理。

  • 总结:最开始锁的范围大了,以活动ID进行锁定,如果业务报错,影响其他用户持有锁。改进方案为活动ID+库存编号作为动态锁标识,每个用户拿一个库存编号,实现了业务隔离,互不影响。

3.2 因为员工误删了redis已使用库存key,出现活动库存超卖怎么解决?

Lottery 的设计把这事给办了;

  1. Lottery 采用的是滑块锁,按照库存编号自动成,如【key_1、key_2、key_3、key_4、...】这些key都被秒杀到的用户 setNx 加锁了。
  2. 如果key被删,则会从0开始计数 incr 但计数后,又会生成 key_1 加锁,可是这个key已经被加锁过,所以会告诉冲突。直到key incr 到当前为加锁的 key_n 时才能被正常购买。

3.3 抽奖项目分布式事务如何解决?

  1. 其实是这样的,使用对于跨库的事务处理,一种是分布式事务,另外一种就是基于MQ+任务调度补偿的方式,完成最终一致性。
  2. 那么鉴于抽奖系统的实时性要求,从用户流程体验上,希望更加流畅,支撑更大的并发量,而不是对整个流程添加过多的事务,降低性能。因为事务来说,是一种集中化的竞态,所以这部分设计上采用最终一致性的方式进行处理,而不是直接添加大块的事务。
  3. 此外由于营销场景的多样性和复杂性,自定义路由组件,可能更好的适应短平快的变化,如我们这样的系统中添加的路由,不仅可以支持数据库路由,也支持Redis路由,避免热key都打到一个服务上。在库存分片后,可以支撑更大的秒杀体量。同时对于单key的秒杀,还采用了滑块分段锁的方式进行处理,所以整个流程来看,都是希望是去中心化的,提高吞吐量的。
  4. 当然,也可以储备些分布式事务的知识,这样也可以说明某些其他项目在用,表明不是你不会这样的技术,只是在适合的场景使用最合适的方案处理问题。PS:不能手里有个锤子🔨,看谁都是钉子。

4. 其他问题

4.2 项目遇到最大的挑战是什么。

  1. 在工期压榨下,满足于当下快速上线还为做出符合未来预期的可持续性系统,是最大的挑战。

  2. 怎么与产品沟通、怎么和领导说明、怎么完成交付,这些在项目初期时候做了不小的沟通。才得以让目前的项目落地。我个人也在这里成长很多。