面试专题

解决 Redis 热 Key 问题，核心思路是分散热 Key 的访问压力，避免单个 Redis 节点因高频请求过载，具体可通过以下方法实现： 1. 热 Key 前置缓存

建立索引规则 索引不宜过多：每张表的索引数量应根据实际业务需求控制，一般建议不超过5 - 6个。过多索引会增加数据插入、更新和删除的开销，因为每次数据变更时，相关的索引都需要更新。

在对账时，每次获取一批交易记录进行核对，核对完成后，根据这批记录中的最大 id 继续获取下一批记录。这样可以快速地遍历大量交易记录进行对账，提高查询性能。

JVM中用元空间代替永久代，主要是出于内存管理优化、垃圾收集效率提升、解决类卸载问题以及性能增强等多方面的考虑

前端负载均衡： 使用如 Nginx 等负载均衡器，它可根据不同策略（如轮询、IP 哈希等）将流量均匀分发到后端多个应用服务器上，避免单台服务器承受过高流量压力。

冒泡排序（Bubble Sort）： 基本思想：通过相邻元素的比较和交换，将最大（或最小）的元素逐步“冒泡”到数组的末尾。每一轮比较都会将未排序部分的最大（或最小）元素放到合适位置。

优化查询语句写法： 减少子查询嵌套：过多的子查询嵌套会使查询逻辑复杂，查询优化器难以生成高效执行计划。尽量将子查询改写为 JOIN 操作，提高查询效率。

1.在联合索引的场景下，查询条件不满足最左匹配原则。 2.使用了select *。3.索引列进行了函数处理和运算处理4.索引列发生了隐式转换5.2个索引列发生了比较。等等情况

思路：先确认队列分配是否均衡，解决负载分配问题； 再排查慢机器的资源和代码问题，优化消费逻辑； 最后通过批量消费、异步处理等机制提升整体消费效率，避免局部瓶颈。

Kafka主要从分区设计和消费端处理两个层面来实现顺序消费： 分区层面 分区有序存储：Kafka的每个分区本质上是一个有序的消息日志序列。

饿汉式 实现思路：在类加载时就创建单例实例，由于类加载由 JVM 保证线程安全，所以天生线程安全。 懒汉式（双重检查锁） 以及静态内部类方式

线程状态流程图 新建-就绪-运行-阻塞-等待-超时等待-终止。会进行各种状态之间的流转。重点区分阻塞和等待的区别

Dubbo提供了多种机制来处理服务请求失败的情况： 1.重试机制： Dubbo默认提供了失败重试功能。2.妇在均衡和故障转移3.服务降级4.熔断器（Hystrix集成）

MyBatis 提供了一级缓存和二级缓存机制，用于提高数据查询性能。 一级缓存 作用范围：一级缓存是 SqlSession 级别的缓存。二级缓存是namespace级别的缓存,需要开启生效。

TCP 三次握手细节： 第一次握手：客户端向服务器发送一个SYN（同步序列号）报文段，该报文段包含客户端打算连接的服务器的端口，以及初始序号（Sequence Number，记为seq=x）。

MySQL binlog 有三种格式：STATEMENT（记录SQL语句）、ROW（记录行变更）、MIXED（前两者混合）。各有优劣，影响复制和恢复。

DispatcherServlet为核心，向服务器发送一个HTTP请求，请求访问某个URL对应的资源