03-16 11:52 已编辑腾讯_cdg_后端研发

关注

腾讯校招实习后端二面：场景题为王

嗨～我是可拟雀，一个后端开发工程师，毕业于某985大学，目前供职于bat某大厂核心部门后端。每天分享最新面经答案，希望在大环境不好的当下能帮到你，让你多积累面试经验。免费分享个人学习2个月速通大厂路线和面经解析合集，需要请私信

1.有两张表一张商品表，一张订单表，要查询数据，应该考虑做些什么呢？
答：

索引：

在经常用于查询条件的字段上创建索引，例如商品ID、客户ID、订单日期等。

避免在索引字段上使用函数或运算，这可能会导致索引失效。

定期维护和优化索引，以确保其有效性。

查询优化：

避免使用SELECT *，而是明确指定需要查询的字段，以减少数据传输量。

使用JOIN代替子查询，当可能时，因为某些情况下JOIN的性能更好。

减少WHERE子句中的条件数量，只包含必要的条件。

使用EXPLAIN命令来查看查询的执行计划，确保它按照预期的方式执行。

表结构：

确保表结构合理，避免冗余数据和不必要的复杂关联。

规范化数据，但也要注意不要过度规范化，以免增加查询的复杂性。

硬件和配置：

确保数据库服务器具有足够的RAM，以便数据库管理系统可以有效地使用内存缓存。

根据工作负载调整数据库的配置参数，例如缓冲区大小、连接池大小等。

使用SSD替代传统硬盘，以提高I/O性能。

分区和分片：

如果表非常大，考虑使用分区或分片技术，将数据分散到多个物理存储位置，以提高查询性能。

缓存：

利用查询缓存或其他缓存机制，存储经常查询的结果，以减少对数据库的访问。

数据库维护：

定期更新统计信息，以便优化器能够做出更好的决策。

定期清理和优化数据库，例如删除旧数据、重建索引等。

并发控制：

使用合适的并发控制策略，如连接池、读写分离等，以减少锁争用和等待时间。

应用层优化：

在应用层实现分页功能，避免一次性加载大量数据。

减少不必要的数据库请求，例如通过合并多个请求或使用批量操作。

监控和日志：

使用数据库监控工具来跟踪查询性能，及时发现并解决性能瓶颈。

分析慢查询日志，找出并优化那些执行缓慢的查询。

2.商品类型适合做索引吗？
答：
考虑商品类型的多样性。如果商品类型非常多样，且每个类型下的商品数量差异很大，那么对商品类型进行索引可能有助于提高查询效率。因为索引能够加速数据库对特定类型商品的检索速度。

如果商品类型数量有限，或者类型之间的商品数量分布较为均匀，那么对商品类型进行索引可能并不会带来明显的性能提升。此外，过多的索引会增加数据库的存储空间和维护成本，因此需要在索引的数量和性能之间做出权衡。

除了商品类型的多样性外，还需要考虑查询的频繁程度。如果经常需要根据商品类型进行查询，那么对商品类型进行索引是有意义的。但如果查询不频繁，或者查询方式更加复杂，那么可能需要考虑其他优化策略，如优化查询语句、调整数据库结构等。

还需要考虑具体的数据库管理系统和硬件环境。不同的数据库管理系统和硬件环境对索引的支持和性能表现可能有所不同，因此在实际应用中需要根据具体情况进行性能分析和优化。

3.商品下单的时候，要做一些什么考虑呢？
答：

1. 数据完整性和准确性：

确保接收到的订单数据完整，没有遗漏或错误。

验证商品信息、数量、价格等数据的准确性，防止因数据错误导致的订单问题。

2. 并发处理能力：

考虑到可能的高并发下单场景，需要确保系统能够处理大量并发请求，避免系统崩溃或响应超时。

合理利用缓存、分布式锁等技术手段，提高系统并发处理能力。

3. 事务一致性：

下单过程可能涉及多个数据库操作（如库存扣减、订单生成等），需要确保这些操作在一个事务中完成，以保持数据的一致性。

使用数据库事务管理来确保操作的原子性、一致性和隔离性。

4. 安全性：

对用户输入进行严格的验证和过滤，防止SQL注入、跨站脚本攻击等安全问题。

使用HTTPS协议进行数据传输，确保数据的加密和安全。

5. 性能优化：

对下单流程进行性能分析，找出瓶颈并进行优化，提高系统的响应速度和吞吐量。

利用负载均衡、缓存等技术手段来分摊请求压力，提高系统性能。

6. 错误处理和日志记录：

对下单过程中可能出现的错误进行妥善处理，并向用户返回友好的错误信息。

记录详细的操作日志和错误日志，方便后续的故障排查和问题定位。

7. 库存管理与同步：

在下单时，确保库存扣减操作的原子性，避免超卖现象。

如果系统涉及多个服务或数据源，需要确保库存数据的实时同步和一致性。

8. 通知与回调：

在订单生成后，及时通知用户和其他相关系统（如支付系统、物流系统等）。

提供回调接口，以便其他系统能够实时获取订单状态变化。

4.数据库层面怎么保证数据原子性呢？

5.如果把订单表放在redis里面怎么保证一致性呢？
6.如果数据表非常大，做查询的时候要做些什么考虑呢？
答：
1. 索引优化：

为经常用于查询的列创建索引，可以显著提高查询速度。但请注意，索引也会占用存储空间并可能增加插入、更新和删除操作的时间，因此需要根据实际情况权衡。
使用复合索引时，要注意列的顺序，将最常用于查询条件的列放在前面。
定期审查和优化现有索引，删除不再需要的索引，避免索引冗余。

2. 查询优化：

尽量避免使用SELECT *，只选择需要的列，减少数据传输量。
使用WHERE子句限制结果集，避免返回过多数据。
避免在列上使用函数或计算，这可能导致索引失效。
尝试将复杂的查询分解为多个简单的查询，然后合并结果，有时这样可以提高效率。

3. 分区与分片：

如果表的数据量非常大，可以考虑使用分区技术将数据分散到多个物理存储上，提高查询并行性。
对于分布式数据库系统，可以采用分片策略将数据分散到多个节点上，实现负载均衡和扩展性。

4. 缓存策略：

对于经常访问且不经常变动的数据，可以使用缓存技术（如Redis、Memcached等）来存储查询结果，减少对数据库的访问。

5. 数据库参数调整：

根据数据库的类型和版本，调整相关的配置参数，如缓冲区大小、连接数等，以优化数据库性能。

6. 定期维护：

定期对数据库进行维护，如更新统计信息、重建索引、清理无用数据等，保持数据库的健康状态。

7. 监控与日志分析：

使用数据库监控工具实时观察查询性能，及时发现和解决性能瓶颈。
分析慢查询日志，找出执行缓慢的查询并进行优化。

8. 数据库设计：

合理的数据库设计是查询优化的基础。避免数据冗余、减少数据关联复杂度、使用合适的数据类型等都可以提高查询效率。

9.结合慢查询相关八股进行说明。

7.tcp为什么要三次握手呢，两次握手不行吗？

8.如果要你做一个qq之类的通讯功能，你会选择什么协议呢？
答：如果要设计一个类似于QQ的通讯功能，我会选择基于TCP/IP协议的即时通讯协议作为核心通讯机制。这种协议能够确保消息的可靠传输，并在双方用户之间建立稳定的连接。

具体来说，当用户登录时，客户端可以采用TCP协议与服务器进行通信，以确保登录过程的安全和稳定。一旦登录成功，客户端和服务器之间会保持一个TCP连接，用于维持在线状态。

在消息传输方面，虽然UDP协议在某些情况下可以提供更高的传输效率，但由于其不保证消息的可靠传输，可能会导致消息丢失或乱序。因此，为了确保消息的准确性和完整性，我会选择使用TCP协议来传输文本消息。同时，我也会利用上层协议来确保消息的可靠传输，并在消息发送失败时提供重新发送的机制。

对于文件传输等需要较高效率的场景，我会考虑采用基于UDP的P2P技术。这种技术可以在用户之间直接传输文件，而无需通过服务器中转，从而提高了传输效率。当然，为了确保文件传输的可靠性，我也会设计相应的校验和重传机制。

综上所述，我会选择基于TCP/IP协议的即时通讯协议作为核心通讯机制，并根据不同的应用场景和需求，结合使用TCP和UDP协议，以提供稳

定、高效且可靠的通讯功能。

9.用长连接还是短链接呢？
答：
每个方案都有自己的优点和缺点。

在设计类似于QQ的通讯功能时，对于连接类型的选择，长连接（Persistent Connection）和短连接（Short Connection）都有各自的优缺点，具体选择取决于应用场景和需求。

长连接：

优点：

减少连接建立和断开的开销：由于连接在建立后保持打开状态，因此避免了频繁地建立和断开连接所带来的时间和资源消耗。

实时性更好：长连接使得服务器和客户端能够实时地交换数据，适用于需要即时响应的场景。

减少网络拥塞：由于减少了连接建立和断开的次数，长连接有助于降低网络拥塞的可能性。

缺点：

资源占用：长时间保持连接状态会占用服务器和客户端的资源，如果连接数过多，可能会导致资源耗尽。

心跳包维护：为了保持连接活跃，通常需要定期发送心跳包，这会增加一定的网络流量和开销。

短连接：

优点：

资源占用少：每次数据传输完成后即断开连接，减少了长时间占用资源的情况。

简单明了：短连接每次数据传输都是独立的，无需考虑连接状态的维护。

缺点：

连接建立和断开开销大：每次数据传输都需要建立新的连接，并在传输完成后断开连接，这增加了时间和资源的消耗。

实时性较差：由于需要频繁建立和断开连接，短连接在实时性方面不如长连接。

由于需要实现实时聊天、文件传输等功能，通常建议选择长连接。长连接能够确保客户端和服务器之间保持稳定的连接状态，实现实时通信，并且减少了连接建立和断开的开销。当然，在实际应用中，还需要根据具体需求和场景来权衡选择长连接还是短连接，以及合理设计心跳包等机制来维护连接的活跃性。

10.如果用长连接的话，有大量的用户同时连接，会出现一些什么问题呢？

答：如果使用长连接，并且有大量用户同时连接，确实可能会出现一些问题。以下是可能面临的一些挑战：

资源消耗：每个长连接都会占用服务器的一定资源，包括内存、CPU和网络带宽。当有大量用户同时连接时，这些资源的消耗会急剧增加，可能导致服务器性能下降，甚至引发服务崩溃。

连接管理：服务器需要维护大量的长连接，这增加了连接管理的复杂性。服务器需要有效地管理这些连接，包括监控连接状态、处理连接断开和重新连接等情况。

网络稳定性：长连接对网络稳定性要求较高。如果网络出现波动或中断，长连接可能会受到影响，导致数据传输中断或连接断开。

安全性问题：大量的长连接可能增加安全风险。恶意用户可能会尝试利用长连接进行攻击，如拒绝服务攻击（DoS）或分布式拒绝服务攻击（DDoS），导致服务器过载或无法正常工作。

为了解决这些问题，可以采取一些措施：

负载均衡：使用负载均衡技术将用户请求分发到多个服务器上，以减轻单一服务器的压力。

连接池：使用连接池技术来管理和复用连接，减少连接建立和断开的开销。

心跳机制：实现心跳机制来定期检测连接的活性，及时发现并处理失效的连接。

安全策略：加强安全策略，包括使用加密技术保护数据传输、限制并发连接数、设置防火墙等，以提高系统的安全性。

11.会给服务器哪些方面带来压力呢，内存、CPU、磁盘还是什么呢？
答：

使用长连接在大量用户同时连接的情况下，会给服务器带来多方面的压力，主要体现在以下几个方面：

内存压力：每个长连接都需要在服务器上占用一定的内存资源来维护连接状态和数据缓冲区。当连接数大幅增加时，内存消耗会迅速增长，可能导致内存不足，进而影响服务器性能。

CPU压力：处理大量的长连接会增加服务器的CPU负担。服务器需要为每个连接进行数据处理、协议解析和响应生成等操作，这些操作都会消耗CPU资源。如果CPU资源不足，可能会导致响应延迟或处理失败。

网络带宽压力：长连接意味着数据在客户端和服务器之间持续传输，这会占用网络带宽。当大量用户同时在线并进行数据传输时，网络带宽可能成为瓶颈，限制数据传输的速度和稳定性。

磁盘I/O压力：虽然长连接本身并不直接增加磁盘I/O压力，但如果服务器需要频繁地读写磁盘以支持连接相关的数据存储或日志记录等操作，那么磁盘I/O也可能成为性能瓶颈。

12.对于CPU的压力，要怎么解决呢（说的是加服务器）？
答：

优化应用程序：首先，对运行在服务器上的应用程序进行优化是关键。这包括优化代码逻辑，减少不必要的计算，使用更高效的数据结构和算法。此外，定期更新软件版本以确保使用的是最新、最优化的代码。

限制进程CPU使用率：使用工具如cpulimit可以限制特定进程的CPU使用率。这对于那些资源消耗过大的进程特别有用，可以确保它们不会过度占用CPU资源。

关闭不必要的后台程序：通过任务管理器或系统监控工具，关闭那些不常用或不必要的后台程序，以释放CPU资源。

升级硬件：如果服务器的CPU性能确实较低，无法满足业务需求，那么考虑升级硬件可能是一个长期解决方案。更换更强大的CPU或增加CPU核数都可以提升服务器的整体性能。

负载均衡：通过实施负载均衡策略，将用户请求分发到多个服务器上，从而分散CPU负载。这有助于确保每个服务器都能处理适量的请求，避免单一服务器过载。

使用缓存：对于频繁访问的数据，使用缓存技术（如Redis或Memcached）可以减少对数据库的访问次数，从而降低CPU负载。

监控与告警：实施CPU使用率的监控和告警机制，当CPU使用率超过预设阈值时，及时发出告警通知，以便管理员可以及时采取措施进行干预和调整。

13.单台服务器怎么做呢？从12问回答中挑选单机相关。
14.有用过netty之类的吗，NIO、BIO、AIO之类的
15.操作系统内核层面怎么做优化呢
16.java的线程模型和操作系统的线程模型
17.如果用UDP的话，要考虑一些什么问题呢
18.UDP的话，除了丢包问题还有什么问题呢
19.如果用HTTP的话，要考虑一些什么问题呢
20.常用的web服务器会遇到的问题有那些呢
21.共享桌面写一个多线程的题，创建10个线程，主线程要在这10个线程执行完成后执行，很快写了个例子但线程忘记start了（汗流浃背了），然后面试官提醒才加上去
22.家是哪里的
23.为什么想要去深圳发展

原文链接

大厂校招实习最新面经解析文章被收录于专栏

专注于最新各大厂最新面筋解析