货拉拉面试：全程八股！被问麻了

今天来看货拉拉 Java 技术岗的面试问题，废话不多说，先看问题。

一面问题

1. 
   
2. 先让介绍项目，超卖问题项目是怎么实现的？有什么改进的想法？
   
3. 线程池的核心参数？
   
4. 在秒杀的过程中，比如只有 10 个名额，有 100 个人去抢，页面上需要做一些什么处理？
   
5. HashSet 了解吗？
   
6. HashMap 了解吗？从 0 个 put 20 个数据进去，整个过程是怎么样的？HashMap 扩容机制？是 put 12 个数据之前扩容还是之后扩容？什么时候装红黑树？为什么是 8 的时候转，为什么是 6 的时候退化回链表？
   
7. ConcurrenHashMap 了解吗？用到哪些锁？
   
8. CAS 原理了解吗？
   
9. synchronized 有多少种锁？锁升级。
   
10. MySQL 有哪些锁？
    
11. 一条 SQL 执行的全流程？
    
12. 地址输入 URL 到数据返回页面，整个流程？
    
13. 域名服务器寻址？
    

二面问题

1. 
   
2. 问了一下项目的锁，问怎么优化？
   
3. 怎么进行项目部署的？
   
4. 之前搭过最复杂的项目是什么？
   
5. 你感觉这种架构有什么好处？为什么要进行微服务拆分？
   
6. Nacos 用过吗？
   
7. CAP 理论？Base 理论？
   
8. MQ 用过吗？
   
9. 有什么技术优势？
   

1.怎么解决超卖问题？

答：超卖问题是一个相对来说，比较经典且相对难处理的问题，解决它可以考虑从以下三方面入手：

1. 
   
2. 前端初步限制：前端先做最基础的限制处理，只允许用户在一定时间内发送一次抢购请求。
   
3. 后端限流：前端的限制只能针对部分普通用户，如果有恶意刷单程序，那么依靠前端是解决不了任何问题的，所以此时就需要后端做限流操作了，而后端的限流又分为以下手段：
   
   1. 
      
   2. IP 限流：限制一个 IP 在一定时间内，只能发送一个请求。此技术实现要点：通过在 Spring Cloud Gateway 中编写自定义全局过滤器来实现 IP 限流。
      
   3. 接口限流：某个接口每秒只接受一定数量的请求。此技术实现要点：通过 Sentinel 的限流功能来实现。
      
   
   
   
4. 排队处理：即时做了以上两步操作，仍然不能防止超卖问题的发生，此时需要使用分布式锁排队处理请求，才能真正的防止超卖问题的发生。此技术实现要点：
   
   1. 
      
   2. 方案一：使用 Lua 脚本 + Redis 实现分布式锁。
      
   3. 方案二：使用 Redisson 实现分布式锁。
      
   
   
   

PS：关于这些技术实现细节，例如：Spring Cloud Gateway 全局自定义过滤器的实现、Sentinel 限流功能的实现、分布式锁 Redisson 的实现等，篇幅有限私信获取。

2.CAP 理论和 Base 理论？

CAP 理论

CAP 理论是分布式系统设计中的一个基本原则，它提供了一个思考和权衡一致性、可用性和分区容错性之间关系的框架。
CAP 理论的三个要素如下：

1. 
   
2. 一致性（Consistency）：在分布式系统中的多个副本或节点之间，保持数据的一致性。也就是说，如果有多个客户端并发地读取数据，在任何时间点上，它们都应该能够观察到相同的数据。
   
3. 可用性（Availability）：系统在任何时间点都能正常响应用户请求，即系统对外提供服务的能力。如果一个系统不能提供响应或响应时间过长，则认为系统不可用。
   
4. 分区容忍性（Partition tolerance）：指系统在遇到网络分区或节点失效的情况下，仍能够继续工作并保持数据的一致性和可用性。
   

CAP 理论指出，在分布式系统中，不能同时满足一致性、可用性和分区容错性这三个特性，只能是 CP 或者是 AP。

• 
  
• CP：强一致性和分区容错性设计。这样的系统要求保持数据的一致性，并能够容忍分区故障，但可用性较低，例如在分区故障期间无法提供服务。
  
• AP：高可用性和分区容错性设计。这样的系统追求高可用性，而对一致性的要求较低。在分区故障期间，它可以继续提供服务，但数据可能会出现部分不一致。
  

CAP 无法全部满足的原因

CA 或 CAP 要求网络百分之百可以用，并且无延迟，否则在 C 一致性要求下，就必须要拒绝用户的请求，而拒绝了用户的请求就违背了 A 可用性，所以 CA 和 CAP 在分布式环境下是永无无法同时满足的，分布式系统要么是 CP 模式，要么是 AP 模式。

BASE 理论

BASE 理论是对分布式系统中数据的一致性和可用性进行权衡的原则，它是对 CAP 理论的一种补充。
BASE 是指：

1. 
   
2. 基本可用性（Basically Available）：系统保证在出现故障或异常情况下依然能够正常对外提供服务，尽管可能会有一定的性能损失或功能缺失。在分布式系统中，为了保证系统的可用性，有时会牺牲一致性。
   
3. 软状态（Soft State）：系统中的数据的状态并不是强一致的，而是柔性的。在分布式系统中，由于网络延迟、节点故障等因素，数据可能存在一段时间的不一致。
   
4. 最终一致性（Eventually Consistent）：系统会保证在一段时间内对数据的访问最终会达到一致的状态。即系统允许数据副本在一段时间内存在不一致的状态，但最终会在某个时间点达到一致。
   

BASE 理论强调系统的可用性和性能，尽可能保证系统持续提供服务，而不是追求强一致性。在实际应用中，为了降低分布式系统的复杂性和提高性能，可以采用一些方法来实现最终一致性，如版本管理、异步复制等技术手段。

PS：BASE 理论并不是对 CAP 理论的颠覆，而是对分布式系统在某些场景下的设计原则，在具体系统设计中，开发人员需要根据业务需求和场景来权衡和选择适当的一致性和可用性策略。

3.你有什么技术优势？

当面试官问你这个问题时，你可以从以下几个方面回答：

1. 
   
2. 总结你掌握的技术点：首先，从你所应聘的职位和相关领域出发，总结并列出你的技术专长或专业专长。注意，你讲的这些技术点一定要向面试公司要求的技术点靠拢。
   
3. 强调你的技术专长：在列举领域后，强调你在这些领域中的技术专长。你可以提及一些主要技术、框架等方面的技术专长。
   
4. 举例说明：提供一些具体的项目案例或工作经验，展示你在技术领域上的实际应用能力。说明你如何使用所掌握的技术解决具体问题、优化系统性能或提升用户体验等。这样可以更加具体地说明你的技术优势，并证明你的技能在实践中是有价值的。
   
5. 强调自己“软”优势：向面试官展示你的“软”优势，例如：喜欢专研技术（加上具体的例子，例如每天都有写代码提交到 GitHub）、积极学习和持续成长等能力。同时，强调你在团队合作中的贡献和沟通技巧等其他能力，这些也是技术优势的重要补充。
   

PS：其他常规的八股问题，可以在我的网站 http://www.javacn.site 找到答案，本文就不再赘述了，大家自己去看吧。

小结

货拉拉解决了日常生活中搬家难的痛点，也是属于某一个细分赛道的龙头企业了，公司不大，但算的上是比较知名的企业。他们公司的面试题并不难，以八股和项目中某个具体问题为主，只要好好准备，拿到他们公司的 Offer 还是比较简单的。

最后：祝大家都能拿到满意的 Offer。