Spring事务1. Spring事务失效场景访问权限问题 Spring 使用动态代理或字节码增强来实现 AOP。当调用一个被 @Transactional 注解标记的方法时，代理对象会拦截调用，并在方法执行前后添加事务管理逻辑。然而，private 方法无法被代理对象拦截，因为它们对外部不可见。 Spring要求被代理的事务方法必须是public的。如果将事务方法定义为private、defa

Spring是如何解决循环依赖的 循环依赖在Spring中主要有三种情况： 构造器注入时产生的循环依赖问题 多例模式下通过setter方法注入产生的循环依赖问题 单例模式下通过setter方法注入产生的循环依赖问题 1. Spring的三级缓存产生循环依赖的三种情况里，只有单例模式下通过setter方法注入产生的循环依赖问题被Spring解决了，其他两种情况下都会抛出异常。 Spring 创

Redis字符串的embstr编码和raw编码之间的界限为什么是44字节 引用：https://juejin.cn/post/7278858311595900987 核心结论：44 字节是为了让整个 RedisObject 对象（包含 SDS Header 和字符串内容）刚好填满 64 字节的内存块 1. Redis字符串编码类型Redis 字符串内部内部编码有三种： int：存储 8 个字节

Redis SDS的5种类型1. 结构概览与区别为了极致地节省内存，Redis 开发者并没有使用一种通用的结构，而是根据字符串的长度，定义了五种不同的 Header 结构。这五种类型的核心区别在于：用于保存字符串长度（len）和分配空间（alloc）的变量类型不同。 类型 len变量类型 alloc变量类型 flags占用 最大容纳长度 Header自身占用 sdshdr5 无 (由

Redis渐进式rehash 渐进式 rehash 是 Redis 为了避免在扩容或收缩哈希表（Dict）时导致服务器“卡死”而设计的一种高明策略。 如果 Redis 像传统方式那样一次性完成百万级键值的搬迁，会导致主线程长时间阻塞，对于追求高并发、低延迟的 Redis 来说，这显然是不可接受的。 1. 核心数据结构在 Redis 的字典结构中，实际上维护了两个哈希表： ht[0]：平时使用的

Redis性能排查调优 Redis执行命令变慢的原因 1. 网络问题2. 业务问题 设置慢日志阈值，开启慢日志slowLog 2.1 命令复杂度过高 经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令 使用 O(N) 复杂度的命令，但 N 的值非常大 解决方法： 尽量不使用 O(N) 以上复杂度过高的命令，对于数据的聚合操作，放在客户端做

Caffeine常见面试题一、Caffeine 基础相关Caffeine 的原理、特性是什么？原理采用 W-TinyLFU 淘汰算法，底层通过分段锁减少并发竞争，结合惰性删除、异步加载等机制实现高性能 特性性能高：基于 W-TinyLFU 淘汰算法，命中率 / 吞吐量比传统的 LRU、LFU 算法要好 缓存策略比较丰富：支持基于大小、时间、引用类型的过期 / 淘汰策略； 加载比

Redis本身有事务为什么还要用Lua脚本?Redis有事务（MULTI/EXEC），但更青睐Lua脚本，主要因为Lua提供更强大的逻辑灵活性（可依赖前一步结果）、更好的性能（减少网络往返）和更适合实现复杂原子操作，如分布式锁、限流等，而Redis事务在复杂场景下难以处理依赖关系且有执行错误不回滚的限制，因此Lua脚本成为处理复杂业务逻辑的优选方案。 Redis事务（MULTI

MySQL-MVCC MySQL通过ReadView和undo log实现了MVCC ReadView 创建该ReadView的事务id（creator_trx_id） 创建该ReadView时，当前活跃且未提交事务id列表（m_ids） 创建该ReadView时，最小活跃未提交事务id（min_trx_id） 创建该ReadView时，下一个事务id（max_trx_id） 记录的隐

MySQL深分页问题1. 什么是深分页问题深分页的性能瓶颈源于MySQL处理LIMIT的机制。当执行： 1SELECT * FROM tabLe LIMIT 1000000, 20 MySQL需要先定位到第1000000条记录，然后再取出接下来的20条记录。这个过程需要跳过前面的100万条记录，即使有索引，这种跳跃操作的成本也是非常高的。随着偏移量的增加，查询时间会线性增长，这就是深分页问题的根