1 redis分片集群，突然大量热点数据的请求落在同一个节点上，要扛不住了，有什么解决办法？

相关节点加从节点、可人工配置的热key的本地缓存层、热点Key施加随机Hash分散到其它节点

2 redis部署方案有哪些？

主从、主从+哨兵(故障监听自动切换)、客户端代理分配、中间件代理分片(Codis、Temproxy)、Cluster(去中心化)

主从不说了，哨兵所有节点存储所有数据，各种代理需要额外引入维护，Cluster故障转移、分片存储、数据找寻都是天然的最优解

数据少用哨兵，数据多用Cluster

3 Cluster为何要配置所有IP:Port?

提升性能和高可用，配置所有可以直连无需跳转，且防止启动时某个节点恰巧挂掉

4 Mysql主键索引，假如2000万数据，你能计算一下查询要几次IO吗？说说过程

主键索引结构B+树，Root加载于内存无需IO，另外叶子存储的是具体数据

磁盘一次IO是一页(16KB)，指针为6字节、主键号int为4字节，非叶子不存值都是指针

每次IO一页 16000/10 = 1600 个指针，两次为256万 此处再看数据平均空间 若一页能存8条数据

则两次IO可获取2000万数据，若少于则3次

5 spring启动流程

6 Lock比Sync快在哪里，之后怎么又差不多，两者取舍

JDK1.5之前Sync无脑进入内核态阻塞，而Lock是有一定CAS最后不行再阻塞，当然最终都是重量级锁，依靠OS的mutex

1.6后Sync引入了偏向锁、轻量锁大大降低阻塞概率，而且官方建议在Sync满足情况下，推荐用Sync后续还有优化空间

Lock可以中断、可构造多个Condition条件、可公平

7 线程池随机几问

项目中用到不少线程池，为了方便定位问题，我们需要给不同线程池命名，请问如何做到？

线程池中有核心线程和非核心线程，当任务完成后，非核心线程是什么时候，怎样被回收的？

当线程池中某个线程出现异常时，线程池会如何处理该线程？我们又如何获取其异常信息？

线程池如何一开始就new出核心线程？

对于线程命名和异常处理，用自定义工厂解决

new ThreadFactoryBuilder()

.setNameFormat(prefix+"%d")

.setUncaughtExceptionHandler((thread, throwable)- > log.error("ThreadPool {} got exception", thread, throwable))

.get()

默认异常走System.err.print("Exception in thread \""+ t.getName() + "\" ");

e.printStackTrace(System.err); 然后线程销毁退出，当然不会影响其它线程和线程池的继续运行

UncaughtExceptionHandler只适用execute，如果是submit则异常信息存在于FutureTask里，我们自己获取时会抛出异常

用preStartAllCoreThreads 线程池预热

8 Redis偶尔查询会比较耗时，排查思路？

可能因素非常多：复杂命令、大Key、fork、集中过期、内存满触发淘汰、AOF每次均刷盘、绑定CPU、网卡负载过高、内存数据被换到Swap

排查思路：

1 慢查询日志 -> 查看慢查询里是否有复杂命令

2 bigkeys命令 -> 查看是否有大Key

3 查看是否使用expireat或pexpireat(绝对时间过期) --> 绝对时间+Random

4 Fork - AOF、RDB --> 若开启则最好在从节点搞，刷盘用1s间隔策略、

info命令查看最后一次fork执行的耗时latest_fork_usec

5 查看内存、SWAP、网卡、CPU使用情况

9 Redis过期策略

主动+被动

主动：定时任务占用主线程每100毫秒从过期字典中随机取20个key，删除过期的key，如果过期key的比例超过了25%，则继续获取20个key，删除过期的key，循环往复，

直到过期key的比例下降到25%或者这次任务的执行耗时超过了25毫秒，才会退出循环；

懒惰：只有当访问某个key时，才判断这个key是否已过期，如果已经过期，则从实例中删除；

如果redis配置了主从，这两种删除，只会在master中执行，然后通过del key的方式同步到slave

10 Redis淘汰策略

volatile -- 从已设置过期时间的数据集中挑选

allkeys -- 从数据集中挑选

volatile-lru、volatile-ttl、volatile-random、volatile-lfu

allkeys-lru、allkeys-lfu、allkeys-random、no-enviction（驱逐）

我们选用的是volatile-lru，key都是有过期时间的且有明显的时间轴特征

11 Redis AOF RDB

都是数据备份持久化机制，一个增量一个全量，一般从节点挂载时需要RDB搞一次全量数据，之后AOF增量更新就行

开启后不要绑定CPU，部署在物理机上，同时持久化最好在从节点执行

非必要就不要开启了，注意AOF刷盘用1s间隔的

如果JVM每分钟GC时间长达几秒，请结合JVM内存结构分析一下可能存在的问题？大家来分析下

12 JVM垃圾回收过程

13 RocketMQ

13 一致性Hash算法

普通hash算法：hash(key) % n。这时候如果一台服务器宕机或新增一台服务器，那么我们的n值就会变，这样就会导致我们所有的请求都会变更

一致性hash算法

哈希环：对2^32取模，将整个环组织成0-2^32-1

将服务器（ip+端口）hash，映射到环上一个节点。当请求到来时，根据key-hash映射到环上，顺时针选取最近的一个服务器进行请求

虚拟节点：当环上服务器较少时，会出现分配不均匀的情况，为了避免这种情况引入虚拟节点。比如通过添加后缀的方式给物理节点克隆出三个虚拟节点，如果两台物理节点，都克隆三个虚拟节点，那么环上就一共有8个节点。只是被克隆的虚拟节点最后还是会定位到实际物理节点上，但是可以有效的分摊请求。

一致性哈希相对于普通hash，优点在于映射到环上的其请求，是发送到环上离他最近的一个服务器，如果我们一台服务器宕机或者新增一台服务器，那么影响的请求只有这台服务器和前一个服务器节点之间的请求，其他的并不会影响。