郑州网站建设xinsu360,福田企业网站优化有用吗,怎么申请百度网盘免费空间,手机登录凡科网文章目录 Redis分布式锁的实现原理Redis实现分布式锁如何合理的控制锁的有效时常#xff1f;**redisson实现的分布式锁**redisson实现的如何保证主从一致性 Redis的集群方案1.主从复制主从数据的同步原理全量同步增量同步 2.哨兵模式Redis的集群脑裂是什么#xff1f;3.分片集… 文章目录 Redis分布式锁的实现原理Redis实现分布式锁如何合理的控制锁的有效时常**redisson实现的分布式锁**redisson实现的如何保证主从一致性 Redis的集群方案1.主从复制主从数据的同步原理全量同步增量同步 2.哨兵模式Redis的集群脑裂是什么3.分片集群 Redis分布式锁的实现原理
Redis实现分布式锁主要利用Redis的setnxSET if not exists命令】
获取锁
# 添加锁 NX 是互斥 EX是设置超时时间
SET lock value NX EX 10释放锁
# 释放锁 删除即可
DEL keyRedis实现分布式锁如何合理的控制锁的有效时常
根据业务执行时间预估 这个时间不好控制时间长或短都会对业务造成影响给锁延期 我们可以添加一个线程来监控当前线程如果业务还未完成就给锁延期如果业务完成就释放锁。
有些许麻烦还需要我们自己创建一个线程这里有一个现成的解决方案那就是redisson是实现的分布式锁 redisson实现的分布式锁
redisson实现的锁是可重入的底层使用hash结构来完成锁的重入。 将锁名作为Key 将线程名和锁可重入的次数作为Value redisson实现的如何保证主从一致性
RedLOck红锁不能只在一个redis实例上创建锁应该是在多个redis实例上创建锁n/2 1避免在一个redis实例上上锁 获取锁时向多个 Redis 节点中获取锁只有每个节点都获取锁成功才算-获取锁成功。实现了只要有一个节点存活其他线程就不能获取锁锁不会失效。 当其中有节点宕机时其他节点仍然含有锁信息其他节点仍然有效
Redis的集群方案
1.主从复制
搭建主从集群实现读写分离 主从数据的同步原理
全量同步
主从全量同步 Replication Id 简称replid是数据集的标记id一致说明是同一个数据集每一个master都有唯一的replidslave则会继承master节点的replid offset 偏移量随着记录在repl_baklog中的数据增多而逐渐增大slave完成同步时也会记录当前同步的offset如果slave的ofset小于master的offset说明slave数据落后于master需要更新 从节点请求主节点同步数据replication idoffset主节点判断是否是第一次请求是的话就同步版本信息replication id 和 offset主节点执行bgsave生成RDB文件发送给从节点执行在RDB执行期间主节点会以命令的形式记录到缓冲区日志文件把生成的日志文件发送给从节点同步
增量同步
主从增量同步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取余余数为插槽寻找插槽所在的实例
