wordpress建站优缺点专业的网络推广

Redis分布式锁的实现原理

Redis实现分布式锁主要利用Redis的setnx（SET if not exists）命令，】

• 获取锁：

# 添加锁 NX 是互斥 EX是设置超时时间
SET lock value NX EX 10

• 释放锁

# 释放锁 删除即可
DEL key

Redis实现分布式锁如何合理的控制锁的有效时常？

• 根据业务执行时间预估
  这个时间不好控制，时间长或短都会对业务造成影响
• 给锁延期
  我们可以添加一个线程来监控当前线程，如果业务还未完成，就给锁延期，如果业务完成，就释放锁。

有些许麻烦，还需要我们自己创建一个线程，这里有一个现成的解决方案，那就是redisson是实现的分布式锁

---

redisson实现的分布式锁

redisson实现的锁是可重入的，底层使用hash结构来完成锁的重入。
将锁名作为Key
将线程名和锁可重入的次数作为Value

redisson实现的如何保证主从一致性

RedLOck（红锁）：不能只在一个redis实例上创建锁，应该是在多个redis实例上创建锁（n/2 +1），避免在一个redis实例上上锁

• 获取锁时，向多个 Redis 节点中获取锁，只有每个节点都获取锁成功，才算-获取锁成功。实现了，只要有一个节点存活，其他线程就不能获取锁，锁不会失效。

• 当其中有节点宕机时，其他节点仍然含有锁信息，其他节点仍然有效

Redis的集群方案

1.主从复制

搭建主从集群，实现读写分离

主从数据的同步原理

全量同步

主从全量同步：
Replication Id： 简称replid，是数据集的标记，id一致说明是同一个数据集，每一个master都有唯一的replid，slave则会继承master节点的replid
offset： 偏移量，随着记录在repl_baklog中的数据增多而逐渐增大，slave完成同步时也会记录当前同步的offset，如果slave的ofset小于master的offset，说明slave数据落后于master，需要更新

1. 从节点请求主节点同步数据，（replication id，offset）
2. 主节点判断是否是第一次请求，是的话就同步版本信息（replication id 和 offset）
3. 主节点执行bgsave，生成RDB文件，发送给从节点执行
4. 在RDB执行期间，主节点会以命令的形式记录到缓冲区（日志文件）
5. 把生成的日志文件发送给从节点同步

增量同步

主从增量同步（slave重启或后期数据变化）

1.从节点请求主节点建立连接，主节点判断不是第一次连接，就获取从节点的offset
2. 主节点从日志文件中获取offset之后的值，发送给从节点进行同步

2.哨兵模式

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复

• 监控： Sentinel会不断检查master和slave是否按照与其工作

Sentinel基于心跳监测服务状态，每隔一秒向集群的每个实例发送一个ping命令
– 主观下线： 如果某个Sentinel发现某实例未在规定时间内响应，则认为该实例主观下线
– 客观下线： 超过指定数量（quorum）的sentinel都认为该实例主观下线，则认为该实例客观下线，quorum的值最好超过Sentinel实例数量的一半

• 自动故障恢复： 如果master故障，Sentinel会将一个slave提升为master，当故障实例恢复后也以新的master为主

哨兵选主原则

• 首先判断主从节点断开时间长短，如超过指定值就排除该从节点不会被提升为主节点
  判断从节点的slave-priority值，越小优先级越高
  如果slave-priority一样，则判断slave节点的offset值，越大优先级越高
  最后是判断slave节点的运行id大小，越小优先级越高

• 通知： Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端
  

Redis的集群脑裂是什么？

集群脑裂是由于主节点和从节点和sentinel处于不同的网络分区，使得sentinel没有能够心跳感知到主节点，所以通过选举的方式提升了一个从节点为主节点，这样就存在了两个master，这样就会导致客户端还在旧的主节点哪里写入数据，新节点无法同步数据，当网络恢复后，sentinel会将旧的主节点降为从节点，再从新的master中同步数据，就会导致数据丢失

解决方案：
修改redis的配置，设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求，就可以避免大量的数据丢失。

# 表示最少的slave节点为1个
min-replicas-to-write 1 # 表示数据复制和同步的延迟不能超过5秒
min-replicas-max-lag 5

---

小结：
主从和哨兵可以解决高可用，高并发读的问题
但是当出现数据量很多或者需要高并发写的场景时，主从和哨兵模式就会吃力。 为了解决这个问题，引入分片集群的概念

3.分片集群

分片集群：

• 集群中有多个master，每个master保存不同的数据
• 每个master有自己的slave节点
• master之间通过ping来监测彼此的健康状态

• 客户端的请求可以访问集群任意节点，最终都会被转发到正确节点

工作细节：

• Redis分片集群引入了哈希槽的概念，Redis集群有16384个哈希槽
• 将16384个哈希槽分配到不同的master实例上
• 读写数据：根据key的有效部分计算哈希值（有效部分：如果key前有大括号，那么有效部分就是大括号内的内容，如果没有，则以key本身作为有效部分），对16384取余，余数为插槽，寻找插槽所在的实例