问懵了：滴滴9大灵魂拷问.....60W年薪面试真题

说在前面

在40岁老架构师尼恩的（50+）读者社群中，最近小伙伴，面试滴滴、央企、美团、京东、阿里、百度、头条等大厂。

下面是一个小伙伴成功拿到通过了滴滴一面面试，现在把面试真题和参考答案收入咱们的宝典。

通过滴滴一面真题，大家可以看看，收个优质Offer需要学点啥？

总之，光代码漂亮不够，面试，还得会吹。

这里把题目以及答案，经过整理和梳理之后，收入咱们的《尼恩Java面试宝典PDF》 V138版本，供后面的小伙伴参考，提升大家的 3高架构、设计、开发、吹牛水平。

《尼恩架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请到文末公号【技术自由圈】取

文章目录

10年经验：滴滴一面试真题

1、你的超高并发10Wqps自动驾驶核心平台的项目，是指的某个查询服务还是指的整体项目支撑10wqps？为什么？

在我的超高并发 10W QPS 自动驾驶核心平台项目中，我们面临的是整体平台的并发性能挑战。

这意味着整个平台，包括路径规划、视觉选图等多个核心服务，都需要设计成低延迟、高性能的架构，以确保在极端情况下也能稳定处理 10 万 QPS 的请求。

为了满足这一要求，我们采取了多种技术和策略：

微服务架构：将不同的功能拆分成微服务，每个微服务负责一个特定的功能，如路径规划、视觉选图等。这样可以独立扩展和优化每个服务的性能。
负载均衡：使用负载均衡器来分配请求到不同的服务实例，确保请求均匀分布在各个实例上，避免单个服务成为瓶颈。
数据库优化：对数据库进行分区、索引优化，以及使用缓存机制来减少数据库访问，提高数据检索速度。
异步处理：对于耗时的操作，如路径规划，采用异步处理方式，避免阻塞主线程，提高系统的并发处理能力。
消息队列：使用消息队列来异步处理图像识别等计算密集型任务，这样可以避免阻塞服务响应。
资源池：对关键资源（如数据库连接、网络连接）使用池化技术，减少资源创建和销毁的开销。
性能监控和自动扩容：实施实时性能监控，并根据监控数据自动调整资源，如自动扩容实例数量，以应对流量高峰。
代码优化：对服务端的代码进行性能优化，减少不必要的计算和网络传输。
容器化和自动部署：使用 Docker 容器化技术，确保服务能够在短的时间内部署和扩展。
持续性能测试和优化：通过持续的性能测试来发现瓶颈，并进行相应的优化。

综上所述，为了支撑自动驾驶核心平台的超高并发需求，我们采取了一系列技术和策略，不仅针对单个服务进行性能优化，还确保整个平台在架构和部署上的高可用性和可扩展性。这样的设计可以确保在用户请求量激增时，平台仍然能够稳定运行，提供低延迟的服务。

老架构师尼恩提示：更多的核心架构面试题、大厂架构面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《架构专题》。

2、路径规划的过程应用场景及路径规划用到哪些算法？

路径规划是自动驾驶、机器人技术以及智能交通系统等领域中的关键技术之一。

它在各种应用场景中发挥着重要作用，例如，自动驾驶车辆中的路径规划可以帮助车辆在复杂环境中找到从起点到终点的最佳路径；

智能交通系统中的路径规划可以优化车辆的行驶路线，减少拥堵和提高交通效率；工业机器人中的路径规划可以指导机器人在工作空间中高效地移动和执行任务。

路径规划算法

在路径规划的过程中，通常会用到多种算法，以适应不同的应用场景和需求。以下是一些常见的路径规划算法：

基于图的路径规划算法：这类算法通常使用图论中的概念和方法来解决问题。图中的节点代表路径规划中的位置，边代表节点之间的连接关系。常见的算法有A*算法、Dijkstra算法、Bellman-Ford算法等。
基于采样的路径规划算法：这类算法通过随机采样来探索环境，并基于采样点之间的连接关系来规划路径。常见的算法有随机树搜索、蚁群算法、粒子群优化等。
基于模型的路径规划算法：这类算法使用环境模型来预测未来可能的位置，并据此规划路径。常见的算法有动态规划、马尔可夫决策过程等。
基于学习的路径规划算法：这类算法通过从经验中学习来改进路径规划。常见的算法有遗传算法、神经网络、强化学习等。
基于仿生的路径规划算法：这类算法模仿自然界中的生物行为来规划路径。常见的算法有蚁群算法、遗传算法、粒子群优化等。

应用场景

路径规划的应用场景确实非常广泛，特别是在自动驾驶、智能交通和机器人技术等领域。

以下是针对您提供的两个应用场景的详细解答：

制图人员验证地图准确性：在这个场景中，路径规划服务起到了关键作用。制图人员可以使用路径规划算法来模拟车辆在地图上的行驶路线，以验证地图的准确性。这个过程通常涉及以下步骤：

制图人员提供地图数据和起始、终止点坐标。
路径规划服务接收这些信息，并计算出一条或多条路径。
然后，制图人员可以根据计算出的路径与实际的道路情况进行对比，以检查地图数据的准确性。
如果发现路径规划服务计算出的路径与实际路径有偏差，制图人员可以据此对地图进行调整，确保地图数据的准确性。

车辆刚刚下线之后，车联网平台会进行路径规划验证车辆硬件等配置是否无误：在这个场景中，路径规划被用来验证车辆的硬件配置和系统性能。这个过程通常涉及以下步骤：

车联网平台接收到车辆的硬件配置信息和起始、终止点坐标。
路径规划服务根据车辆的硬件配置（如传感器、控制器等）计算出一条路径。
然后，车联网平台可以将计算出的路径与预期路径进行对比，以检查车辆的硬件配置和系统性能是否满足要求。
如果发现计算出的路径与预期路径有偏差，车联网平台可以据此对车辆的硬件配置进行调整，确保车辆的正常运行。

在实际应用中，路径规划算法的选择和实现需要考虑到多个因素，包括实时性、准确性、鲁棒性等。针对不同的应用场景，可能需要设计不同的路径规划算法，以满足不同的需求。

例如，对于实时性要求较高的自动驾驶车辆，可能需要使用快速计算的路径规划算法；而对于准确性要求较高的场景，可能需要使用更为复杂的路径规划算法。

总之，路径规划算法在现代科技领域中起着至关重要的作用，其应用场景和影响范围将继续扩大。

3、Kafka是如何保证顺序性的？

Kafka 是一个分布式流处理平台，它被设计用来处理高吞吐量的数据。

在 Kafka 中，消息被存储在称为分区的日志文件中，每个分区可以有多个副本，以提供容错和高可用性。

Kafka 保证分区内的消息顺序性，但不能保证跨分区的顺序性。

kafka保证消息顺序有两种方案：

方案一，kafka topic 只设置一个partition分区

方案二，producer将消息发送到指定partition分区

解析：

方案一：kafka默认保证同一个partition分区内的消息是有序的，则可以设置topic只使用一个分区，这样消息就是全局有序，缺点是只能被consumer group里的一个消费者消费，降低了性能，不适用高并发的情况

方案二：既然kafka默认保证同一个partition分区内的消息是有序的，则producer可以在发送消息时可以指定需要保证顺序的几条消息发送到同一个分区，这样消费者消费时，消息就是有序。

producer发送消息时具体到topic的哪一个partition分区，提供了三种方式

指定分区
不指定分区，有指定key 则根据key的hash值与分区数进行运算后确定发送到哪个partition分区
不指定分区，不指定key，则轮询各分区发送

老架构师尼恩提示：更多的核心消息队列面试题、大厂消息队列面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《消息队列专题》。

4、你在使用redis的时候，有没有什么最佳实践？

在使用 Redis 的时候，确实有一些最佳实践可以帮助你更有效地使用这个内存中的数据结构存储系统。以下是一些重要的最佳实践：

1. 避免使用 KEYS 命令

KEYS 命令会扫描指定pattern的所有键，并返回匹配的键列表。
这个命令会阻塞 Redis 服务器，直到扫描完成。如果 pattern 匹配大量键，可能会导致长时间的阻塞。
最佳做法是使用 SCAN 命令，它以迭代的方式返回匹配的键，不会一次性阻塞整个服务器。

2. 避免使用 FLUSHDB 或 FLUSHALL

FLUSHDB 命令会清空当前数据库中的所有键值对，而 FLUSHALL 命令会清空所有数据库中的所有键值对。
使用这些命令会丢失所有数据，包括未过期的数据。
如果需要清除数据，尽量使用删除特定键的命令，如 DEL、UNLINK 或利用 SDIFF、SINTER 等命令来清除特定的键集合。

3. 控制数据大小

避免在 Redis 中存储过大的数据块，这可能会导致内存碎片化和性能下降。
如果需要存储大量数据，考虑使用数据库或其他存储系统。
对于大型数据集，可以使用 Redis 的哈希表或有序集合，但要确保合理地分片和索引数据。

4. 合理设置过期时间

为键值对设置合理的过期时间，可以防止内存溢出和数据长期占用。
过长的过期时间可能会导致内存占用过高，过短的过期时间可能会导致频繁的过期和重入，影响性能。
根据数据的使用情况和访问模式来调整过期时间。

5.还有一些，扩展的最佳实践

使用 LRU、LFU 等驱逐策略来管理内存，确保经常访问的数据留在内存中。
考虑使用 Redis 的持久化机制来备份数据，防止数据丢失。
使用 Redis 的监控工具来跟踪内存使用情况和性能指标。
在设计应用时，尽量遵循 Redis 的使用规范，避免不必要的复杂操作。

遵循这些最佳实践可以帮助你更有效地使用 Redis，避免性能问题，并确保数据的持久性和安全性。

老架构师尼恩提示：更多的核心redis 面试题、大厂redis面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《redis专题》。

5、redis缓存过期时间设置，在什么场景下可以设置成不过期，在业务场景下应该设置多久过期？

Redis 缓存过期时间设置取决于业务需求和场景。在某些场景下，缓存数据可能需要设置不过期，以保持数据的持久性。而在其他场景下，需要设置合理的过期时间以确保数据的时效性和内存占用。以下是一些建议：

1. 不过期的场景：

固定数据，不需要定期更新，如一些配置信息、常量等。
数据量较小，且对内存占用影响不大，可以设置不过期。

2. 设置合理过期时间的场景：

动态数据，需要定期更新，如新闻、商品信息等。
数据量较大，需要控制内存占用，如图片、视频等。

3. 业务场景下的过期时间设置：

针对不同的数据类型和业务需求，可以设置不同的过期时间。例如，新闻信息可以设置为 1 天过期，商品信息可以设置为 7 天过期，图片可以设置为 30 天过期等。
可以根据数据的使用频率和访问模式来调整过期时间。例如，访问频率高的数据可以设置较短的过期时间，而访问频率低的数据可以设置较长的过期时间。

总之，在设置 Redis 缓存过期时间时，需要根据业务需求和场景来判断，确保数据的时效性和内存占用之间的平衡。

老架构师尼恩提示：更多的核心redis 面试题、大厂redis面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《redis专题》。

6、redis内存淘汰策略有哪些？

Redis 的内存淘汰策略主要分为三类，分别针对不同的键集和业务需求：

不淘汰：

这种策略下，Redis 不会主动删除任何键。适用于那些不需要定期清理的键，比如静态配置或者数据量非常小的场景。

所有键：

Redis 会删除所有键，而不是只删除设置了过期时间的键。
这种策略可能会导致大量数据的丢失，因此使用时需要谨慎。

设置过期时间的键：

Redis 只会删除那些设置了过期时间的键。
这种策略可以根据键的过期时间来决定哪些数据需要被淘汰。

根据上述三类策略，Redis 提供了以下八种具体的内存淘汰算法：

volatile-lru：针对设置了过期时间的键，使用 LRU 算法进行淘汰。
allkeys-lru：针对所有键，使用 LRU 算法进行淘汰。
volatile-lfu：针对设置了过期时间的键，使用 LFU 算法进行淘汰。
allkeys-lfu：针对所有键，使用 LFU 算法进行淘汰。
volatile-random：针对设置了过期时间的键，随机删除一些键。
allkeys-random：针对所有键，随机删除一些键。
timestamp：根据键的创建时间进行排序，删除较早创建的键。
redis-call：允许用户自定义内存淘汰行为，通过 Lua 脚本来实现复杂的淘汰逻辑。

在实际应用中，选择哪种内存淘汰算法取决于具体的业务场景和数据访问模式。例如，如果业务中频繁访问的是最近的数据，那么 LRU 策略可能更合适。如果数据访问比较均匀，那么 LFU 策略可能更合适。此外，还可以根据数据的使用频率和访问模式来调整过期时间，以优化内存使用和提高性能。

老架构师尼恩提示：更多的核心redis 面试题、大厂redis面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《redis专题》。

7、场景题：有一个dubbo服务，必须在1秒内返回结果（成功/失败），给出你的设计思路

设计一个必须在 1 秒内返回结果的 Dubbo 服务时，我们需要考虑以下几个关键点：

参数校验：

服务接收请求后，首先对请求参数进行校验。
如果校验失败，则立即返回错误信息，避免后续资源浪费。

服务独立部署：

确保服务可以独立部署，以减少依赖复杂性。
采用轻量级容器化技术，如 Docker，快速启动和停止服务。

预加载数据：

通过预加载机制，将所需数据提前加载到本地内存。
减少数据查询时间，提高服务响应速度。

异步数据处理：

对需要耗时处理的数据，采用异步方式。
例如，通过消息队列（如 Kafka、RabbitMQ）将数据发送到后台处理。

数据库优化：

设计表结构时，根据查询频率添加索引。
优化 SQL 查询，使用缓存机制减少数据库访问。

性能监控和调优：

监控服务性能，找出瓶颈进行优化。
调整服务参数，如连接池大小、缓存过期时间等。

异常处理：

确保服务在异常情况下也能快速响应。
编写详细的错误日志，便于问题追踪。

接口协议优化：

使用高效的接口协议，如 gRPC，减少网络通信开销。

服务限流：

防止服务被过多请求压垮，通过限流保护系统稳定性。

分布式一致性：

如果服务涉及分布式系统，确保一致性机制，如使用分布式锁。

在实现时，可以考虑使用 Dubbo 的异步调用机制，结合 Spring Boot 和 Dubbo 提供的注解和配置，快速搭建服务框架。同时，利用缓存框架（如 Redis）来存储热点数据，减少数据库访问。此外，通过 Dubbo 的监控工具，实时监控服务状态，快速响应服务异常。

扩展思路：

考虑使用 Dubbo 服务治理和控制台，对服务进行实时监控和管理。
实现服务自动扩容和缩容，以应对流量高峰。
使用分布式搜索引擎（如 Elasticsearch）来优化全文搜索性能。
实现自动化的性能测试和基准测试，确保服务在各个环境下都能满足性能要求。

综上所述，设计一个高效的 Dubbo 服务需要综合考虑多个方面，从架构设计到具体实现，都需要围绕性能和稳定性进行优化。

老架构师尼恩提示：更多的核心dubbo 面试题、大厂dubbo面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《dubbo专题》。

8、你用的jdk是哪个版本？垃圾收集器用的哪个？有没有遇到什么问题？

我使用的 JDK 版本是 1.8。在 JDK 1.8 中，垃圾收集器默认使用的是 ParallelGC（又称为 Throughput Collector），这是一种并发的垃圾收集器，适用于多核 CPU 的机器，并且适用于对吞吐量有较高要求的场景。
在使用 JDK 1.8 的过程中，确实遇到过 Full GC 频繁的问题。起初，这种情况每周只会发生一次，但后来有一天晚上，Full GC 的发生次数突然增加到了四次。为了解决这个问题，我首先采取的措施是重启服务，这样可以立即减轻 Full GC 对系统的影响。

随后，为了从根本上解决问题，我进行了压力测试（压测）。通过分析测试结果，我发现了一个大对象，这个对象包含了商品属性等相关所有商品信息。这个大对象在一次 Full GC 过程中没有被及时回收，导致了问题的发生。
为了解决这个问题，我将大对象分隔成了不同的小对象。这样，每个小对象在内存中的占用变得更小，就可以在垃圾收集器进行 Minor GC 时被及时回收，从而减少了 Full GC 的发生频率。同时，这也使得我们可以更灵活地管理商品信息，提高了系统的稳定性。

通过这次问题解决的过程，我认识到了垃圾收集器在系统性能中的重要性，以及在面对大对象时，合理地拆分和优化数据结构对提高系统稳定性也是非常关键的。此外，对于 JDK 1.8 的垃圾收集器，了解不同收集器的特点和适用场景，以及如何根据实际业务需求进行调整，也是保证系统高效运行的关键。

老架构师尼恩提示：更多的核心JVM 面试题、大厂JVM 面试题，请参见 5000page+《尼恩Java面试宝典PDF》 V138版本中的《JVM 专题》。