致远互联java实习生面试

目录

简介

提问

数据库的优化策略,你知道哪些?

场景问题: 你的项目中的点赞功能在高并发场景下该如何优化 ?

List集合下. ArrayList和LinkedList有什么区别? 

== 和 equals的区别 

你了解HashMap吗?

线程的生命周期

java多线程中, sleep和wait有什么区别? 

你了解红黑树吗 

TCP和UDP的区别

你了解哪些设计模式? 

 如何保证懒汉模式的线程安全

---

简介

• 时间: 2024年3月28日19:24:30
• 面试内容
  • java基础
  • mybatis
  • 数据库优化
  • java集合体系
  • java多线程
  • 项目场景
  • 设计模式
  • 数据结构
  • 缓存

提问

数据库的优化策略,你知道哪些?

 我的回答:

        数据库测优化策略有很多, 比如说合理使用索引, 多去使用聚簇索引, 尽量避免未被最最左匹配原则, 然后在使用索引的时候, 应该避免一些回表的操作, 多使用覆盖索引等.

分析 : 

        我的这种回答有一个很不好的地方, 就是只是点介绍的不够全面, 给面试官介绍的零零散散, 完全就没有一个顺序逻辑可言, 这个让面试官听起来也会很失望. 所以我们掌握知识, 应该有深度的研究, 有体系的学习, 而不是东拼西凑.

标准回答: 

        数据库的优化策略主要包括多个方面，旨在提高数据存储和处理的效率，减少系统资源消耗，降低运营成本，以及提升企业的竞争力。以下是一些主要的优化策略：

1. 表结构优化：根据实际需求，对数据库表结构进行合理设计，减少数据冗余，提高数据一致性。
2. SQL语句优化：编写高效的SQL语句，避免全表扫描,回表等操作，减少不必要的计算和数据访问。可以使用索引、分区等技术来提高查询性能,多使用聚簇索引而非单列索引, 多使用覆盖索引。
3. 索引优化：为常用查询字段创建索引，提高查询效率。但要注意避免过度索引，以免增加数据更新的时间复杂度。同时，可以考虑使用多列索引和覆盖索引来进一步提高查询性能。
4. 分区与分表：将表数据按照一定规则进行分区或分表，可以提高查询性能和管理效率。分区可以将一张表的数据分散到多个物理存储位置，而分表则可以将一张大表拆分成多个小表。
5. 硬件设备升级：使用高速的缓存存储（如RAM或SSD）来存放频繁访问的数据，而将不常用的数据存放在较慢的存储设备上。此外，增加内存、使用多核CPU等也可以提高数据库性能。
6. 数据库软件优化：针对数据库软件本身进行优化，如调整数据库参数、优化查询计划等。
7. 存储过程与函数：使用存储过程和函数来封装复杂的SQL逻辑，减少网络传输开销，提高执行效率, 例如一个常规的点赞操作, 那么被点赞的内容会被插入到关系表中, 并且被点赞的点赞数会 + 1, 这个时候如果将其分为两步, 那么就会有两次网络传输的开销, 但是如果使用存储过程, 那么在点赞之后, 存储过程自动识别并 + 1操作, 就不需要再次进行网络传输。
8. 定期维护：定期对数据库进行清理、备份和维护，保证数据库的稳定性和可用性。同时，定期更新索引统计信息，帮助数据库优化查询计划。
9. 数据缓存: 如果短时间内有大量的sql语句执行, 那么必然会造成数据库崩溃, 我们应该尽量避免这种情况, 首先考虑到使用redis, mq等作为数据缓存, 让其异步的形式刷新到内sql中去, 这样就避免了短时间内的大量请求, 减少了sql数据库崩溃的可能性. 

总之，数据库优化是一个综合性的过程，需要根据实际情况选择合适的优化策略。在优化过程中，要注意权衡各种因素，确保优化效果的最佳化。

分析:

        这种答法很有逻辑性, 首先数据库的优化, 我们应该从需求的角度出发, 去分析这张表的设计与实现, 在设计的时候, 就应该避免一些冗余字段, 到后面要对这个sql进行操作的时候, 就去优化操作sql的sql语句, 优化语句就涉及到一些索引, 计算, 和数据访问的只知识, 然后细说索引里面的如何去优化索引.

        如果这些都是最高效的了, 还想继续优化, 那么就可以考虑分库分表, 在存储的时候进行一些取模操作来决定数据的存储与查询, 这样就减少了查询的时间.

        还想要升级的话, 那么就加钱, 升级设备, 更好的设备, 比如网卡的读写速度, 好的硬盘, 来或者内存和cpu, 来提高数据处理的速度.

        硬件说完了就来说软件, 例如mysql, sqlserver等主流数据库中的软件优化, 或者软件解决方案, 例如存储过程等等.

        软硬件说完了, 剩下的就是好好地去维护这些表和库, 定期对其进行一个清理, 清理掉一些僵尸数据.

        自己的软件说完了, 就说说别人的软件呗? 比如redis, 他的精髓就是内存的非关系型数据库, 性能高. 使用其作为数据缓存, 或者是热点数据的存储, 让sql底层压力更小.

        怎么样, 这样的回答, 可算仔细? 而且这样的回答更有体系, 顺理成章, 面试官也会为你点赞的.

场景问题: 你的项目中的点赞功能在高并发场景下该如何优化 ?

        我的一个论坛系统的项目, 里面涉及到一个点赞的功能, 我的实现方法是, 用户请求点赞之后, 将请求发送给controller层, 然后controller层调用service层, 然后service层进行相关校验工作之后, 调用dao层去插入一条sql记录, 然后同步执行sql操作给对应的帖子点赞数 + 1 操作 . 这个时候 我底层用户和用户自己点赞的帖子靠着一张表实现了, 用户点赞就插入, 取消点赞就删除相关记录即可, 但是今天面试官问了我一个问题, 如果高并发情况下, 同时有大量用户对同一个帖子点赞, 该怎么处理 ? 

        场景问题有时候确实头疼, 因为它牵扯到一些底层, 当然也牵扯到你的业务处理能力, 这会直接让面试官给你判决定分. 本人是面试小白(假), 下面看看小白我是怎么回答的.

我的回答:

        我考虑到的是, 如果这种高并发情况系, 会涉及到大量的用户对同一个帖子进行点赞, 每一次点赞的操作都会发送一个http请求,给后端的接口, 后端接收到之后, 就去对应的数据库中插入当前点赞用户的记录(也就是标记这个帖子被当前用户点赞), 但是大量的请求就意味着大量的请求会直接发送给sql数据库, 那么数据库肯定会承受不住而崩溃, 我的解决办法是引入数据缓存, 例如redis, 将这些数据以热点数据的形式发布, 然后同步到sql, 或者是将redis作为sql操作缓存, 将操作异步刷新给sql, 这样sql处理起来就避免了过多的网络请求, 避免了数据库崩溃.

分析:         

        各位认为我说的对吗???  哈哈哈, 我这个人当然对自己也是直言不讳啦, 我说的对, 虽然答到点子上面去了, 但是, 还不够深入,同时也不够体系.  光耀深的, 浅的不要嘛? 肯定要啊? 这个点应该从表的设计, 索引的设计, sql语句的设计等底层开始一步步实现.

标准回答:

        在高并发情况下，大量用户同时对同一个帖子点赞确实会带来挑战，主要涉及数据库并发写入性能、数据一致性和并发控制等方面。以下是一些建议来应对这个问题：

1. 数据库优化：
   • 索引优化：确保对用于查询的帖子ID和用户ID字段建立了适当的索引，以提高查询和写入性能。
   • 批量插入：如果可能，考虑使用批量插入的方式减少数据库交互次数，提高性能。
   • 存储过程: 如果可以, 使用存储过程, 将多个修改插入操作, 合并为一次交互的过程, 避免多次交互. 
   • 使用合适的数据库引擎：比如，如果使用的是MySQL，可以考虑使用InnoDB等支持事务的存储引擎。
2. 缓存策略：
   • 读缓存：使用Redis等内存数据库缓存帖子点赞数，减少直接对数据库的读取操作。
   • 写缓存：对于写操作，也可以考虑先写入缓存，再异步同步到数据库，以减轻数据库的压力。
3. 并发控制：
   • 乐观锁：使用乐观锁机制（如版本号控制）来确保在并发更新时数据的一致性。
   • 悲观锁：使用数据库的行锁或表锁来确保数据在更新过程中的一致性，但需要注意避免死锁问题。
4. 消息队列：(同缓存)
   使用消息队列（如Kafka、RabbitMQ等）来异步处理点赞操作，将请求先放入队列，再由后台服务异步处理，减轻前端请求对数据库的直接压力。
5. 限流与降级：
   • 限流：通过限流策略（如令牌桶算法、漏桶算法等）控制对数据库的请求频率，避免过多的请求同时涌入。
   • 降级：在极端情况下，可以考虑降级服务，比如暂时关闭点赞功能，或返回缓存中的旧数据, 或者是是限制用户的单个时间内的点赞的次数。
6. 分布式解决方案：
   • 如果单数据库实例无法满足性能要求，可以考虑使用分布式数据库解决方案，如分片、读写分离读写等。
7. 业务逻辑优化：
   • 去重：在业务逻辑层面确保同一个用户短时间内对同一个帖子只能点赞一次，避免重复操作。
   • 合并请求：对于短时间内多次的点赞请求，可以考虑在服务器端合并处理，减少数据库操作次数。
8. 监控与报警：
   • 实施完善的监控和报警机制，实时监控系统的性能指标（如QPS、响应时间、错误率等），及时发现并处理潜在问题。
   • 通过报警系统及时通知相关人员，以便快速响应和解决问题。

在回答面试官的问题时，可以综合以上策略进行说明，并强调根据具体的业务场景和系统架构来选择适合的解决方案。同时，也可以提及在实际项目中如何通过压力测试、性能分析和监控等手段来发现和解决高并发问题。

        我们的设计中, 最应该注意的就是第三点, 并发控制, 这一点也是经常要考的, 为什么? 因为我们在帖子点赞的时候, 需要对点赞数进行一个+ 1 操作, 然后向后端插入一个记录, 这两步都涉及到sql的交互, 因此其他几个都是在与sql交互的层面进行优化, 但是我们还应该保持数据一致性和多线程的安全问题. 例如 多个线程+1操作, 最后的结果可能会小于 正确结果. 这是不允许发生的. 于是我们可以使用锁的机制来控制:

// 使用数据库事务来确保操作的原子性  
BEGIN TRANSACTION;  
    // 读取当前的点赞数  
    int currentLikes = getPostLikes(postId);  
    // 增加点赞数  
    currentLikes++;  
    // 更新帖子的点赞数  
    updatePostLikes(postId, currentLikes);  
COMMIT TRANSACTION;

        如果你不熟悉这个语言, 那么下面是java的代码案例:

import org.springframework.beans.factory.annotation.Autowired;  
import org.springframework.stereotype.Service;  
import org.springframework.transaction.annotation.Transactional;  
  
import java.util.concurrent.locks.Lock;  
import java.util.concurrent.locks.ReentrantLock;  
  
@Service  
public class PostService {  
  
    private final Lock lock = new ReentrantLock();  
  
    @Autowired  
    private PostRepository postRepository; // 假设有一个对应的JPA仓库  
  
    @Transactional  
    public void likePost(Long postId) {  
        lock.lock(); // 获取锁  
        try {  
            Post post = postRepository.findById(postId).orElse(null);  
            if (post != null) {  
                post.setLikes(post.getLikes() + 1);  
                postRepository.save(post);  
            }