记录代码路上的点滴思考。

Redis从单线程到多线程的演进

Redis提供了RDB和AOF两种持久化机制来保障数据可靠性。RDB通过定时生成内存快照实现高效持久化，具有文件小、恢复快的特点，但存在数据丢失风险。AOF则通过记录每条写命令实现更精细的持久化，支持三种刷盘策略平衡性能与安全性，并通过重写机制解决文件膨胀问题。两种方式各有优劣：RDB适合大规模数据备份恢复，AOF提供更高数据安全性。实际应用中可根据业务需求选择或组合使用这两种方式，在性能与数据可靠性间取得平衡。

摘要：本文深入剖析了Redis底层数据结构的设计原理。string类型采用SDS结构实现二进制安全；hash类型使用ziplist和hashtable两种编码，其中ziplist通过连续内存提升空间利用率但存在连锁更新问题，为此Redis 7.0引入listpack替代方案。重点分析了dict字典结构，其采用渐进式rehash策略，通过双哈希表设计和后台任务分批迁移数据，既保证扩容时不阻塞主线程，又能确保数据一致性。

本文系统介绍了Redis缓存技术的核心原理与应用实践。首先从缓存概念入手，通过生活实例类比解释缓存本质；然后详细分析Redis的两种缓存更新策略（定期更新和实时更新）及其工作流程；重点探讨了Redis的过期策略（惰性删除+定期删除）和8种内存淘汰策略；最后针对缓存穿透、击穿、雪崩等典型问题提出了布隆过滤器、互斥锁、错峰过期等解决方案，并强调数据库与缓存一致性保障的关键在于"先更库再删缓存"。文章为高并发系统设计提供了全面的Redis缓存优化思路。

Redis集群模式通过哈希槽分区算法实现数据分布，解决了主从复制的单点写入瓶颈问题。该算法预设16384个哈希槽，平均分配给多个主节点，避免了传统哈希求余扩容时的数据大量迁移问题，同时比一致性哈希算法更均衡。集群采用心跳检测和投票机制实现自动故障转移，当主节点故障时，从节点通过选举晋升为新主节点。集群具有水平扩展、高可用等优势，但也存在不支持跨槽操作、异步复制导致数据不一致等局限。相比单节点或主从模式，集群模式需要更多资源但能更好地支持高并发场景。

摘要： Redis哨兵模式通过独立进程监控主从节点，实现自动故障转移，提升系统高可用性。其核心机制包括主观下线判定、客观下线投票、领头哨兵选举及从节点晋升流程。优点在于自动容灾、易用兼容；缺点包含写单点瓶颈、数据一致性风险及转移延迟。哨兵模式有效解决了主从复制的手动切换痛点，但需权衡其复杂度与性能局限。适用于对自动容灾有强需求的Redis主从架构场景。

本文详细介绍了Redis主从模式(Master-Slave Replication)的原理与实践。主要内容包括：1)通过"一主两从"架构演示配置过程和数据同步；2)主从模式的核心作用是提高系统可用性和并发能力；3)数据同步原理分为全量复制和增量复制两种方式，并详细说明其工作流程；4)分析了主从模式的优缺点，指出其在读多写少场景下的优势，以及存在主节点单点故障等问题。最后提到哨兵模式可解决自动故障转移问题，为后续内容做铺垫。文章从实践到理论全面解析了Redis主从复制机制。

Redis作为高性能内存数据库，其持久化机制是保障数据可靠性的关键。本文详细解析了RDB和AOF两种持久化方式：RDB通过定时全量快照实现高效备份，但存在数据丢失风险；AOF则以追加日志方式提供更细粒度的数据保护，但文件体积较大。文章深入探讨了两种机制的工作原理、触发条件、执行流程及优缺点对比，特别分析了RDB的fork开销和AOF的刷盘策略对性能的影响。通过实际配置演示和故障模拟，验证了持久化机制的数据恢复能力，为Redis使用者提供了全面的技术参考。