JVM——类加载器子系统 类加载器子系统：负责从文件系统/网络中加载class文件 1. 类加载器分类 启动类加载器Bootstrap ClassLoader 扩展类加载器Extension ClassLoader 系统类加载器AppClassLoader 用户自定义加载器 除Bootstrap CLassLoader，其他类加载器都继承于ClassLoader 2. 双亲委派机制

Redis哨兵1. 投票1：判断主服务器是否下线哨兵集群中的一个哨兵判定主节点下线后（主观下线），会发起投票，若多数哨兵都认为主节点下线，则为客观下线，需要切换主节点。 2. 投票2：选举leader哨兵切换主从节点需要一个哨兵来做，这个哨兵称为leader哨兵，需要经过推选得到。 3. leader哨兵进行主从切换 选出新主节点：先排除已离线的从节点，再排除网络状况不好的从节点，剩下的从节点依据

Redis主从复制1. 第一次同步（全量复制） 建立主从服务器连接 同步数据：主服务器执行bgsave生成RDB文件，发送给从服务器，从服务器加载RDB文件 在同步数据过程中新生成的写操作命令会被记录到从服务器的replication_buffer缓冲区，待从服务器加载完RDB文件后，执行这些写操作以实现主从一致。 如果同步数据过程太长导致replication_buffer缓冲区满了，则重

Redis过期删除与内存淘汰1. Redis过期删除策略1.1 惰性删除不主动删除，访问key时再判断是否过期，是否需要删除（节省cpu，但是占内存） 1.2 定期删除一段时间（每秒10次）随机抽20个key检查，将过期的删除，若过期数量超25%即5个，重复前面流程再来一次。 2. Redis内存淘汰策略2.1 不主动淘汰不主动淘汰，当内存满了还想添加数据则报错 2.2 在有过期时间的key中淘汰

Redis持久化1. AOF日志1.1 AOF日志在Redis执行完一条命令后，将该命令记录到AOF日志中 为什么是在执行完命令之后记录日志呢？ 避免额外的检查开销，AOF 记录日志不会对命令进行语法检查； 在命令执行完之后再记录，不会阻塞当前的命令执行。 这样也带来了风险： 如果刚执行完命令 Redis 就宕机会导致对应的修改丢失； 可能会阻塞后续其他命令的执行（AOF 记录日志是在 Re

Redis数据结构 引用：小林coding、JavaGuide、https://juejin.cn/post/7525640395234230326 1. Redis是如何实现键值对数据库的？Redis是使用了一个哈希表保存所有键值对，哈希表其实就是一个数组，数组中的元素叫哈希桶。哈希桶存放的是指向键值对的指针（dictEntry*），键值对则保存了key和value的指针。 特别说明下，vo

Kafka工作原理 1. Kafka核心概念 Message（消息）：Kafka中的数据单元称为消息。可以将消息看成是数据库中的一条“数据行”或一条“记录”。消息是Kafka中最基本的单位，每一条消息都是一个独立的记录，包含消息的键、值、时间戳等信息。 Batch（批次）：为了提高效率，Kafka将消息进行批量处理。消息被分批写入Kafka，这种方式提高了吞吐量，但也会增加响应时间。批次处理使得

为什么Integer用==比较时127相等而128不相等？ 引用：https://zhuanlan.zhihu.com/p/368421654 一、问题引出1234567public static void main(String[] args) { for (int i = 0; i < 150; i++) { Integer

点评项目面经总结1. 使用Redis解决了在集群模式下的Session共享问题，使用拦截器实现用户的登录校验和权限刷新 Session共享问题：在多台Tomcat服务器的集群模式下，多台Tomcat之间不会共享Session，导致在Tomcat1中携带有用户的登录信息，但Tomcat2中没有，当用户使用Tomcat2时，会判断为未登录 基于Redis实现： 将随机生成的token作为key值，

Redisson分布式锁一、基于Redis的setnx实现的分布式锁存在的问题 不可重入：同一个线程无法多次获取同一把锁 不可重试：获取锁只尝试一次，失败就返回 false，没有重试机制 超时释放：锁超时释放虽然可以避免死锁，但如果是业务执行耗时较长，也会导致锁释放，存在安全隐患 主从一致性：如果 Redis 提供了主从集群，主从同步存在延迟，此时某个线程从主节点中获取到了锁，但是尚未同步给从节点