目录

基础概念

‌一、核心原理‌

‌二、核心特性‌

‌三、技术意义与应用价值‌

‌四、典型应用场景‌

案例部署

‌一、主从复制配置命令‌

‌二、哨兵模式部署命令‌

‌关键注意事项‌

---

基础概念

‌一、核心原理‌

1. ‌内存存储与高性能‌
   Redis 所有数据存储于内存中，读写操作直接在内存完成，避免磁盘 I/O 瓶颈。单线程模型（6.0 前）通过多路复用处理并发请求，确保原子性操作，延迟低至微秒级，支撑 10W+ QPS 高并发场景。

2. ‌数据结构与对象系统‌

   • ‌底层数据结构‌：包括简单动态字符串（SDS）、双向链表、哈希表、跳表、压缩列表（ziplist）等。
   • ‌对象封装‌：通过 redisObject 结构体封装数据类型（如 String/Hash/List/Set/ZSet），动态选择最优编码（如 ziplist 或 hashtable），平衡内存与性能。
   • ‌示例‌：Hash 类型在元素少时使用 ziplist（节省内存），元素多时转为 hashtable（提升操作效率）。

3. ‌持久化机制‌

   • ‌RDB（快照）‌：定时生成内存数据的二进制快照，适合灾难恢复，但可能丢失最后一次快照后的数据。
   • ‌AOF（日志追加）‌：记录每条写操作指令，支持实时持久化。通过重写机制压缩日志文件。
   • ‌混合模式‌（Redis 4.0+）：结合 RDB 快照与 AOF 增量日志，平衡恢复速度与数据安全性。

4. ‌集群与高可用‌

   • ‌主从复制‌：主节点（Master）异步同步数据到从节点（Slave），支持读写分离。断线重连后可触发全量同步（RDB 传输）或增量同步（缓冲区指令补发）。
   • ‌Redis Cluster‌：分片存储数据至 16384 个哈希槽（Slot），节点间通过 Gossip 协议通信，支持自动故障转移与水平扩展。
   • ‌哨兵模式（Sentinel）‌：监控主节点状态，自动选举新主节点，实现高可用。

---

‌二、核心特性‌

‌特性‌	‌说明‌
‌多数据结构支持‌	String、List、Hash、Set、ZSet（有序集合）等，覆盖复杂业务场景（如排行榜、社交关系）。
‌原子性操作‌	单线程模型保证命令原子执行，结合 Lua 脚本实现多操作原子性。
‌发布订阅（Pub/Sub）‌	支持消息广播机制，用于简易消息队列。
‌过期与淘汰策略‌	支持 TTL 过期时间，内存不足时启用 LRU/LFU/TTL 等淘汰算法。
‌事务支持‌	通过 MULTI/EXEC 实现弱事务（不保证回滚）。

---

‌三、技术意义与应用价值‌

1. ‌解决性能瓶颈‌
   作为缓存层，将热点数据置于内存，减轻后端数据库压力，提升响应速度（如秒杀系统）。

2. ‌丰富数据模型支持‌
   超越传统 KV 存储，提供集合运算、范围查询、排序等能力，直接实现排行榜（ZSet）、好友关系（Set）等场景。

3. ‌分布式系统基石‌

   • ‌分布式锁‌：通过 SETNX 命令实现跨进程互斥锁。
   • ‌消息队列‌：List 结构实现轻量级队列，Pub/Sub 支持实时消息推送。
   • ‌会话共享‌：集中存储用户 Session，支持水平扩展。

4. ‌高可用架构支撑‌
   集群与哨兵模式保障服务连续性，满足企业级可用性要求。

---

‌四、典型应用场景‌

• ‌缓存加速‌：数据库查询结果缓存。
• ‌实时计数器‌：String 结构的原子增减（如浏览量统计）。
• ‌排行榜‌：ZSet 按分数排序（如游戏积分榜）。
• ‌社交功能‌：Set 实现共同关注、好友推荐。
• ‌限流与分布式锁‌：控制 API 访问频率，协调分布式资源。

---

Redis 通过内存计算、灵活数据结构与分布式架构，重塑了高性能数据处理的范式，成为现代应用中缓解数据库压力、实现复杂逻辑的关键组件。其设计平衡了速度、灵活性与可靠性，在微服务、实时计算等领域持续发挥核心价值。

案例部署

‌一、主从复制配置命令‌

1. ‌主节点配置‌

   • 主节点无需特殊配置，默认启动即为 Master 角色：

     redis-server /path/to/redis.conf 

   • 验证主节点状态：

     redis-cli -p 6379 info replication # 查看角色（role:master）及从节点连接数

2. ‌从节点配置‌

   • ‌方式1‌：启动时指定主节点（临时生效）

     redis-server --slaveof <master-ip> <master-port> 

   • ‌方式2‌：运行时动态切换为主节点的从节点

     redis-cli -p 6380 slaveof <master-ip> <master-port> # 6380为从节点端口

   • ‌方式3‌：配置文件永久生效（推荐）
     修改从节点的 redis.conf：

     slaveof <master-ip> <master-port> replica-read-only yes # 从节点只读

3. ‌验证主从同步‌

   • 在主节点写入数据后，从节点执行：

     redis-cli -p 6380 get key_name # 检查数据是否同步

---

‌二、哨兵模式部署命令‌

1. ‌哨兵配置文件‌
   创建 sentinel.conf，关键配置示例：

   sentinel monitor mymaster <master-ip> 6379 2 # 监控主节点，2表示至少2个哨兵同意才触发故障转移:ml-citation{ref="12,14" data="citationList"} 
   
   sentinel down-after-milliseconds mymaster 5000 # 主节点5秒无响应视为主观下线:ml-citation{ref="14" data="citationList"} 
   
   sentinel failover-timeout mymaster 60000 # 故障转移超时时间（毫秒）:ml-citation{ref="11" data="citationList"} 

2. ‌启动哨兵节点‌

   redis-sentinel /path/to/sentinel.conf # 每个哨兵节点独立启动:ml-citation{ref="12" data="citationList"} 

3. ‌模拟故障转移测试‌

   • 手动停止主节点：

     redis-cli -p 6379 shutdown 

   • 观察哨兵日志，确认新主节点选举：

     tail -f /var/log/redis/sentinel.log # 输出包含"+failover"和"+switch-master":ml-citation{ref="12,14" data="citationList"} 

4. ‌客户端重定向‌
   应用需配置哨兵节点地址而非直接连接主节点，哨兵会自动返回当前主节点信息。

---

‌关键注意事项‌

• ‌主从复制‌：从节点重启后需重新执行 slaveof 命令或配置持久化。
• ‌哨兵集群‌：至少部署3个哨兵节点以避免脑裂问题。
• ‌网络互通‌：确保主从节点及哨兵间防火墙开放对应端口（如6379、26379）。