MySQL 和 Redis 一致性问题，重点在更新和删除场景更常见的实践是“先更新 MySQL，再删除 Redis”删除缓存失败时，MQ 重试通常是更实用的补偿方案Redis 锁性能更好，但在故障场景下的一致性和可靠性要谨慎评估ZooKeeper 锁性能较弱，但自动释放和强一致性更适合高可靠场景RedLock 可以增强 Redis 锁的可靠性，但不等于所有问题都能完全消失真正落地时，不要只看技术名

你们是否也认为这个主库不可用了客观下线（Objectively Down，简称odown这个判断通常要求达到配置的法定票数，也就是常说的 quorum。需要达到 Sentinel 配置中的法定票数要求只有当主库被判定为客观下线后，后续的故障转移流程才会真正开始。哨兵之间通过主库上的频道互相发现单个哨兵只能判断主观下线，多个哨兵达成共识后才会形成客观下线主库被判定客观下线后，哨兵集群会选出一个 Le

AOF 的全称是 Append Only File。把 Redis 收到的写命令，以追加的方式记录到日志文件中当 Redis 重启恢复时，就可以重新执行这些命令，从而恢复数据。某一时刻 Redis 的全量数据快照RDB 文件是二进制格式，因此恢复时可以直接把快照内容读入内存，而不需要逐条重放命令。RDB 恢复速度通常比 AOF 更快以 RDB 快照作为基础在两次快照之间，用 AOF 记录增量命令定

IO 多路复用的目标是：“让一个线程同时监听多个文件描述符，当其中某些就绪时再处理。selectpollepoll它们本质上都在做同一件事：帮助应用进程找到“哪些连接现在可以读写”。BIO：一个线程盯一个连接，简单但浪费NIO：线程不阻塞，可以管理多个连接IO 多路复用：帮助线程高效发现哪些连接就绪epoll：Linux 高并发场景下最常见的选择AIO：由系统在完成后主动通知，更偏异步如果你后面准

Redis 集群常见有两种方式：主从哨兵和切片集群主从哨兵主要解决高可用问题，切片集群主要解决水平扩展问题Redis Cluster 使用 16384 个哈希槽实现 key 到实例的映射key 先通过 CRC16 计算，再对 16384 取模，确定所属槽客户端通过缓存槽位映射关系来定位数据MOVED表示槽已经正式迁移完成，客户端需要更新缓存ASK表示槽仍在迁移中，只做一次临时重定向理解 Redis

Redis 作为内存数据库，内存资源有限，必须妥善处理内存占用问题。决定内存达到上限时如何移除数据，涵盖 noeviction、LRU、LFU 等多种算法及其实现细节；（惰性删除 + 定期删除）负责及时清理已过期的键，并说明如何避免读到过期数据。掌握这些机制，有助于合理配置 Redis 实例，平衡内存效率与数据可用性。

在分布式架构中，多台服务器共享同一资源时，传统的 JVM 锁已无法保障数据一致性，分布式锁由此成为关键。Redisson 基于 Redis 实现的分布式锁，不仅支持可重入、自动续期，还通过发布订阅机制高效处理锁竞争。本文从加锁、锁续命、锁释放三个环节，深入解析 Redisson 的核心设计，包括 Lua 脚本保证原子性、Watch Dog 看门狗的定时续期机制，以及如何灵活控制锁的失效策略。

公网 IP 是可以在互联网范围内参与路由的地址。通常一个家庭宽带、一个企业出口、一个云服务器，都会有一个或多个公网 IP。从互联网的视角看，真正能被外部网络直接识别和访问的，通常是这个公网 IP。私网 IP 是保留给局域网内部使用的地址，不能直接在公网中路由。10.0.0.0/8到这类地址更准确地叫“私网 IP”，不是“虚拟 IP”“在链路上”表示目标是直连可达的，不需要经过下一跳网关路由表负责选

把整个过程压缩成一句话就是：“先解析域名，再建立 TCP 连接，然后发送 HTTP 请求，服务器返回响应，浏览器解析资源并渲染页面，最后按需复用或关闭连接。DNS 解析TCP 三次握手HTTP 请求与响应路由转发与网关TCP 四次挥手这也是理解整个互联网通信过程最好的入口。如果这篇文章对你有帮助，欢迎继续阅读本系列后续内容。若文中有不准确或需要补充的地方，也欢迎指出。

CPU 缓存不是按“一个变量”来管理的，而是按“缓存行”来管理的。缓存行通常是 64 字节，它是缓存系统中最小的管理单位和失效单位。CPU 读取一个变量时，往往会把它周围相邻的一块数据一起读入缓存所以连续内存访问通常更高效，因为它更容易命中缓存行。伪共享是并发编程里一个很常见但不容易一眼看出来的性能问题。线程 A 修改变量x线程 B 修改变量yx和y虽然是两个不同变量，但它们刚好落在同一个缓存行里