Redis渐进式rehash
Redis渐进式rehash 渐进式 rehash 是 Redis 为了避免在扩容或收缩哈希表（Dict）时导致服务器“卡死”而设计的一种高明策略。 如果 Redis 像传统方式那样一次性完成百万级键值的搬迁，会导致主线程长时间阻塞，对于追求高并发、低延迟的 Redis 来说，这显然是不可接受的。 1. 核心数据结构在 Redis 的字典结构中，实际上维护了两个哈希表： ht[0]：平时使用的
Redis性能排查调优
Redis性能排查调优 Redis执行命令变慢的原因 1. 网络问题2. 业务问题 设置慢日志阈值，开启慢日志slowLog 2.1 命令复杂度过高 经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令 使用 O(N) 复杂度的命令，但 N 的值非常大 解决方法： 尽量不使用 O(N) 以上复杂度过高的命令，对于数据的聚合操作，放在客户端做
Caffeine常见面试题
Caffeine常见面试题一、Caffeine 基础相关Caffeine 的原理、特性是什么？原理采用 W-TinyLFU 淘汰算法，底层通过分段锁减少并发竞争，结合惰性删除、异步加载等机制实现高性能 特性性能高：基于 W-TinyLFU 淘汰算法，命中率 / 吞吐量比传统的 LRU、LFU 算法要好 缓存策略比较丰富：支持基于大小、时间、引用类型的过期 / 淘汰策略； 加载比
Redis本身有事务为什么还要用Lua脚本?
Redis本身有事务为什么还要用Lua脚本?Redis有事务（MULTI/EXEC），但更青睐Lua脚本，主要因为Lua提供更强大的逻辑灵活性（可依赖前一步结果）、更好的性能（减少网络往返）和更适合实现复杂原子操作，如分布式锁、限流等，而Redis事务在复杂场景下难以处理依赖关系且有执行错误不回滚的限制，因此Lua脚本成为处理复杂业务逻辑的优选方案。 Redis事务（MULTI
MySQL-MVCC
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深分页问题
MySQL深分页问题1. 什么是深分页问题深分页的性能瓶颈源于MySQL处理LIMIT的机制。当执行： 1SELECT * FROM tabLe LIMIT 1000000, 20 MySQL需要先定位到第1000000条记录，然后再取出接下来的20条记录。这个过程需要跳过前面的100万条记录，即使有索引，这种跳跃操作的成本也是非常高的。随着偏移量的增加，查询时间会线性增长，这就是深分页问题的根
MySQL索引优化手段
MySQL索引优化手段假设有一张表 user，三个字段 id (主键索引) 、 age(非唯一索引)、name(联合索引idx_name_age)、gender、empid（联合索引idx_gender_empid）。 表中现有数据： id: 10, age: 10_v1, name: aaa，gender: M，empid: 10 id: 11, age: 10_v2, name: bbb，g
LongAdder相比AtomicLong的优势
LongAdder相比AtomicLong的优势LongAdder相比AtomicLong最核心的优势在于大幅降低了高并发场景下的CAS竞争开销。当多个线程频繁对AtomicLong进行递增操作时，所有线程都会竞争同一个内存位置，导致大量CAS失败重试，性能急剧下降。这就像几十个人同时去抢一把锁，成功率极低，大家都在空转浪费CPU。 LongAdder采用分段累加策略巧妙地解决了这个问题。它的核心