小程序商城模板下载_南昌seo_石家庄网站建设案例_手游cpa推广平台

---

1.安装部署(基于Docker)

1.编排Redis主从节点

• 编写docker-compose.yml
  • 创建/root/redis/docker-compose.yml，同时cd到yml所在⽬录中
  • 说明：docker中可以通过容器名字作为ip地址，进⾏相互之间的访问

  version: '3.7'
  services:master:image: 'redis:5.0.9'container_name: redis-masterrestart: alwayscommand: redis-server --appendonly yesports: - 6379:6379slave1:image: 'redis:5.0.9'container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6380:6379slave2:image: 'redis:5.0.9'container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6381:6379
  

• 启动所有容器：docker-compose up -d
• 查看运行日志：docker-compose logs

---

2.编排Redis-Sentinel节点

• 说明：可以把redis-sentinel放到和上⾯的Redis的同⼀个yml中进⾏容器编排，但此处分成两组，主要是为了两⽅⾯：
  • 观察⽇志⽅便
  • 确保Redis主从节点启动之后才启动redis-sentinel
    • 如果先启动redis-sentinel的话，可能触发额外的选举过程，混淆视听
    • 不是说先启动哨兵不⾏，⽽是观察的结果可能存在⼀定随机性
• 编写docker-compose.yml
  • 创建/root/redis-sentinel/docker-compose.yml ,同时cd到yml所在⽬录中

  version: '3.7'
  services:sentinel1:image: 'redis:5.0.9'container_name: redis-sentinel-1restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel1.conf:/etc/redis/sentinel.confports:- 26379:26379sentinel2:image: 'redis:5.0.9'container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3:image: 'redis:5.0.9'container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- 26381:26379
  networks:default:external:name: redis-data_default
  

• 创建配置文件：创建sentinel1.conf、sentinel2.conf、sentinel3.conf，三分文件的内容是完全相同的，都放在/root/redis-sentinel/⽬录中

  bind 0.0.0.0
  port 26379
  sentinel monitor redis-master redis-master 6379 2
  sentinel down-after-milliseconds redis-master 1000
  

  • 理解sentinel monitor：
    • 主节点名：这个是哨兵内部⾃⼰起的名字
    • 主节点ip：部署redis-master的设备ip
      • 此处由于是使⽤docker，可以直接写docker的容器名，会被⾃动DNS成对应的容器ip
    • 法定票数：哨兵需要判定主节点是否挂了，但是有的时候可能因为特殊情况
      • ⽐如主节点仍然⼯作正常，但是哨兵节点⾃⼰⽹络出问题了，⽆法访问到主节点了
      • 此时就可能会使该哨兵节点认为主节点下线，出现误判
      • 使⽤投票的⽅式来确定主节点是否真的挂了是更稳妥的做法
      • 需要多个哨兵都认为主节点挂了，票数 >= 法定票数之后，才会真的认为主节点是挂了

    sentinel monitor 主节点名 主节点 ip 主节点端⼝ 法定票数
    

  • 理解sentinel down-after-milliseconds：
    • 主节点和哨兵之间通过⼼跳包来进⾏沟通
    • 如果⼼跳包在指定的时间内还没回来，就视为是节点出现故障
  • 既然内容相同，为啥要创建多份配置⽂件?
    • redis-sentinel在运⾏中可能会对配置进⾏rewrite，修改⽂件内容
    • 如果⽤⼀份⽂件，就可能出现修改混乱的情况
• 启动所有容器：docker-compose up -d
• 查看运行日志：docker-compose logs

---

2.重新选举

1.redis-master宕机之后

• 哨兵发现了主节点sdown，进⼀步的由于主节点宕机得票达到$2/3$，达到法定得票，于是master被判定为odown

  • 主观下线(Subjectively Down，SDown)：哨兵感知到主节点没⼼跳了，判定为主观下线
  • 客观下线(Objectively Down，ODown)：多个哨兵达成⼀致意⻅，才能认为master确实下线了
    

• 接下来，哨兵们挑选出了⼀个新的master，上图中，是172.22.04:6379这个节点
  

• 此时，对于Redis来说仍然是可以继续使用的

---

2.redis-master重启之后

• 哨兵日志：刚才新启动的redis-master被当成了slave
  

---

3.总结

• Redis主节点如果宕机，哨兵会把其中的⼀个从节点，提拔成主节点
• 当之前的Redis主节点重启之后，这个主节点被加⼊到哨兵的监控中，但是只会被作为从节点使⽤

---

3.选举原理

• 假定生产环境如下
  

1. 主观下线：
   • 当redis-master宕机，此时redis-master和三个哨兵之间的⼼跳包就没有了
   • 此时，站在三个哨兵的⻆度来看，redis-master出现严重故障，因此三个哨兵均会把redis-master判定为主观下线(SDown)
2. 客观下线：
   • 此时，哨兵sentenal1, sentenal2, sentenal3均会对主节点故障这件事情进⾏投票
   • 当故障得票数 >= 配置的法定票数之后，意味着redid-master故障这个事情被坐实，此时触发客观下线(ODown)

     sentinel monitor redis-master 172.22.0.4 6379 2
     

3. 选举出哨兵的leader
   • 接下来需要哨兵把剩余的slave中挑选出⼀个新的master，这个⼯作不需要所有的哨兵都参与，只需要选出个代表(称为leader)，由leader负责进⾏slave升级到master的提拔过程
   • 这个选举过程涉及到Raft算法，假定一共三个哨兵节点S1，S2，S3
     • 每个哨兵节点都给其他所有哨兵节点，发起⼀个"拉票请求"
       • S1 -> S2, S1 -> S3, S2 -> S1, S2 -> S3，S3 -> S1, S3 -> S2
     • 收到拉票请求的节点，会回复⼀个 “投票响应”，响应的结果有两种可能, 投or不投
       • 例如：S1给S2发了个投票请求，S2就会给S1返回投票相应
       • S2是否要投S1，取决于S2是否给别人投过票了(每个哨兵只有一票)
       • 如果没投过(S1是第一个向S2拉票的)，S2就会投给S1，否则则不投
     • 一轮投票完成之后，发现得票超过半数的节点，自动成为leader
       • 如果出现平票，则重新再投一次即可
       • 这也是为啥建议哨兵节点设置成奇数个的原因，如果为偶数个，则增大了平票的概率，带来了不必要的开销
     • leader节点负责挑选⼀个slave成为新的master，当其他的sentenal发现新的master出现了，就说明选举结束了
   • 综上，Raft算法的核心就是”先下手为强”，谁率先发出了拉票请求，谁就有更大的概率成为leader
     • 决定因素：网络延时，其本身就带有一定的随机性
   • 具体选出的哪个节点是leader不重要，重要的是能选出一个节点
4. leader挑选出合适的slave成为新的master
   • 挑选规则：
     1. 比较优先级，优先级高(数值小的)的上位
        • 优先级是配置文件中的配置项slave-priority或者replica-priority
     2. 比较replication offset，谁复制的数据多，高的上位
     3. **比较run id**，谁的id`小，谁上位
        • 即：大小全凭缘分，选谁都可以，随便挑一个
   • 当某个slave节点被指定为master之后
     • leader指定该节点执行slave no one，成为master`
     • leader指定剩余的slave节点，都依附于这个新master

---

4.总结

• 上述过程，都是"⽆⼈值守"，Redis ⾃动完成的，这样做就解决了主节点宕机之后需要⼈⼯⼲预的问题，提⾼了系统的稳定性和可⽤性
• 注意事项：
  • 哨兵节点不能只有一个，否则哨兵节点挂了也会影响系统可用性
    • 分布式系统中，应该避免使用“单点”，应该有冗余
  • 哨兵节点最好是奇数个，方便选举leader，得票更容易超过半数
    • 大部分情况下，3个就足够了
  • 哨兵节点不负责存储数据，仍然是Redis主从节点负责存储
    • 哨兵节点可以使用一些配置不高的机器来部署
  • 哨兵 + 主从复制解决的问题是”提高可用性”，不能解决”数据极端情况下写丢失”的问题
  • 哨兵 + 主从复制不能提高数据的存储容量，当需要存的数据接近或者超过机器的物理内存，这样的结构就不能胜任了
    • 为了能存储更多的数据，就引入了集群