Redis——主从&哨兵配置

目录

基础概念

‌一、核心原理‌

‌二、核心特性‌

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

‌四、典型应用场景‌

案例部署

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

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

‌关键注意事项‌


基础概念

一、核心原理

  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)。
### Redis 主从复制与哨兵模式配置及运行机制 #### 配置主从复制 为了实现高可用性和数据冗余,在Redis环境中通常设置一个或多个从服务器来备份主服务器的数据。可以通过两种方式完成这一过程: - **通过配置文件配置** 修改`redis.conf`中的`slaveof`参数指向主服务器地址和端口,从而让该实例成为指定主服务器的副本[^1]。 - **通过命令配置** 使用`SLAVEOF host port`指令动态地使当前节点作为另一台机器上的特定Redis实例的从属设备;输入`SLAVEOF NO ONE`可取消这种关系并恢复独立运作状态。 对于具体的环境部署而言,比如构建由一台主服务器(Master)加两台从服务器组成的架构,则需要相应调整各节点间的连接属性以确保正常同步操作能够顺利执行。 #### 哨兵模式概述及其配置方法 哨兵系统用于监控管理一组Redis服务器的状态变化情况,并能在检测到故障发生时自动实施修复措施&mdash;&mdash;最常见的是触发一次Failover流程即重新选定一个新的Leader角色承担起原有Primary职责继续对外提供服务而不影响业务连续性[^3]。 针对上述提到的一主二丛结构加上三个Sentinel进程共同构成完整的HA解决方案案例来说,具体步骤如下所示[^2]: 1. 准备好三份不同路径下存放着各自专属配置项(sentinel.conf) 的哨岗程序; 2. 编辑这些文档定义监听目标以及通知邮箱列表等内容; 3. 利用命令行工具依次开启每一个守护者单元使之进入待命姿态等待接收事件报告; 4. 确认所有组件均已成功上线之后便可以测试整个体系能否按照预期发挥作用了。 ```bash cd /opt/redis-5.0.7/ redis-sentinel sentinel.conf &amp; ``` 以上述脚本为例说明如何启动单个哨位实体,实际应用当中应当重复此动作直至覆盖全部预定位置。 #### 运作逻辑解析 一旦某个Slave失去联系超过一定时限后就会被标记为已离线(Suspect),此时其余在线成员之间会展开一轮投票决议是否要将其正式认定为不可达(Down)[^4]。如果确实如此则立即挑选出一位表现最佳的竞争者晋升为首脑带领剩余群体维持日常运营秩序直到失联个体恢复正常为止。 在此过程中涉及到的关键考量因素之一就是所谓的&ldquo;优先级&rdquo;,它决定了候选名单里谁最有资格接替前任领导者的位置。默认情况下数值越低代表权重越高,默认设定为100,用户可以根据实际情况自定义调整这个值以便更好地适应不同的应用场景需求。 另外值得注意的地方在于原先担任过Master职务的那个对象即便后来降格成为了Follower身份也依然保留着曾经拥有的那份记忆不会轻易改变自己的定位除非再次遭遇类似的权力更迭情形才会考虑做出相应的转变。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值