Redis 原理深入

掌握 base 基础和 plus 数据类型后，可以沿着“数据怎么存、命令怎么执行、故障后留下什么”理解原理。

数据类型与底层编码

数据类型决定命令语义，编码决定内部表示。同一种类型可能因数据量、元素大小、配置或版本使用不同编码。不能把“Hash 类型”直接等同于“始终采用哈希表”，也不能把内部结构名称当成新的一种业务类型。

可在实验服务用 TYPE key 查看类型，用 OBJECT ENCODING key 观察编码，用 MEMORY USAGE key 估算该键占用。比较时同时记录版本、元素数量与大小，不能仅凭一个小样本推断所有数据的内存成本。

命令执行、网络 I/O、后台持久化和内存释放属于不同工作。分析性能时，应区分服务端处理耗时与客户端观察到的总耗时；网络、连接等待和返回数据大小也会影响延迟。

先检查慢命令、大量返回和长脚本，再结合客户端指标定位。Pipeline 减少往返次数，但不会降低单条复杂命令本身的计算成本，也不提供事务隔离。

过期解决数据的时间有效性，淘汰解决达到内存限制时如何腾出空间。设置了 TTL 的键可能在到期之前因淘汰被删除；没有 TTL 的键也不意味着能在所有淘汰策略下永久保留。

maxmemory 和策略需要匹配业务用途。可重建缓存与不能随意丢失的限额、锁状态，往往需要不同的容量与隔离策略。选择 noeviction 也需要应用处理写入失败，不能把失败留给业务偶然发现。

快照和 AOF 都会引入磁盘、内存和后台任务成本。理解它们时要分别检查写入成功、同步磁盘、备份生成和恢复完成这几个时刻；客户端收到成功响应，不代表独立备份已经包含该写入。

机制	主要解决的问题	必须考虑的边界
主从复制	将主节点的变化传播给副本	通常异步，读副本可能看到旧数据，切换可能丢失未复制写入
Sentinel	非 Cluster 部署中的监控与自动故障切换	不负责把数据分片；客户端需要支持发现当前主节点
Cluster	按哈希槽分布数据并管理节点故障	多键操作通常要求同槽，客户端需要处理重定向

复制不能替代备份，自动切换也不能直接推导出强一致或零数据丢失。学习时应画出“写主节点 → 复制 → 主节点故障 → 副本接管”的时序，检查各时刻哪些数据可能尚未传播。

本页说明机制，不包含已执行的多节点部署实验。实际搭建需要按版本文档确认拓扑、网络、客户端与恢复方案。