🌙 睡前复盘 | 八股心得和项目难点总结#

1. Redis 底层数据结构：跳表与 Listpack

Hash 结构： 与 Java (数组+链表+红黑树) 不同，Redis 采用 Listpack (小基数) 和 Hashtable (大基数)。触发阈值： 键值对 > 512 或 Key/Value 长度 > 64 字节。扩容机制： 渐进式 rehash，避免了 Java 那种一次性迁移导致的阻塞。每次增删改查时，迁移rehashIndex位置的桶到哈希表2中，等哈希表1全部迁移完成，释放1的内存。

Zset 结构： 引入跳表 (SkipList)。通过多级索引实现 O(log n) 的范围查询。

Listpack 的进化： 彻底解决了 Ziplist 的级联更新问题（不记录前节点长度，只记录自身长度）。

2. 重新认识“单线程”模型

一直以来的误区： Redis 并非绝对单线程。网络 I/O 和 键值对读写 是单线程，但持久化、集群同步、异步删除等是由后台多线程处理的。

I/O 多路复用： 面对高并发，Redis 不靠增加 CPU 核心（避免上下文切换开销），而是靠多路复用技术高效处理网络请求。

多线程的地方：多线程异步处理网络请求后进入主线程串行执行，既保证了效率，又无需处理并发锁问题。因为redis本身就是线程安全的

3. 项目进展：秒杀业务与分布式锁

昨天问题：用redis分布锁 + Lua 脚本处理“误删”与“超卖”问题。

今日问题： SETNX 分布式锁的四大缺陷：

❌ 超时释放 ---> ✅ 看门狗机制 (Watchdog)

❌ 重入问题 ---> ✅ Redisson (Hash 计数)

❌ 不可重试 ---> ✅ Pub/Sub 订阅机制

❌ 主从一致性 ---> ✅ Redlock 算法

📅 明日计划：

先从redission开始学，解决setnx这四个问题。继续刷LeetCode ，找找手感。

（注：文档部分内容可能由 AI 生成）