Redis集群与扩展知识点分析

这篇文章主要讲解了“Redis集群与扩展知识点分析”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Redis集群与扩展知识点分析”吧！防止单点故障，造成整个集群不可用实现高可用通常的做法是将数据库复制多个副本以部署在不同的服务器上，其中一台挂了也可以继续提供服务Redis实现高可用有三种部署模式：主从模式，哨兵模式，集群模式主节点负责读写操作从节点只负责读操作从节点的数据来自主节点，实现原理就是主从复制机制主从复制包括全量复制，增量复制两种当slave第一次启动连接master，或者认为是第一次连接就采用全量复制
slave与master全量同步之后，master上的数据如果再次发生更新，就会触发增量复制
主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址,显然多数业务场景都不能接受这种故障处理方式,Redis从2.8开始正式提供了Redis Sentinel(哨兵)架构来解决这个问题哨兵模式是由一个或多个Sentinel实例组成的Sentinel系统，可以监视所有的Redis主节点和从节点，并在被监视的主节点进入下线状态时自动将下线主服务器属下的某个从节点升级为新的主节点但是一个哨兵进程对Redis节点进行监控，就可能会出现问题(单点)，因此可以使用多个哨兵来进行监控Redis节点，并且各个哨兵之间还会进行监控
简单来说，哨兵模式就三个作用故障切换过程如下哨兵的工作模式哨兵模式基于主从模式，实现读写分离，还可以自动切换，系统可用性更高，但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容，因此Cluster集群应运而生，它在Redis3.0加入的Cluster集群实现Redis的分布式存储，对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题，并且它也提供复制和故障转移的功能Redis Cluster集群通过Gossip协议进行通信，节点之间不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等，常用的Gossip消息分别是ping、pong、meet、failHash Slot插槽算法主观下线： 某个节点认为另一个节点不可用，即下线状态，这个状态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况
客观下线： 标记一个节点真正的下线，集群内多个节点都认为该节点不可用，从而达成共识的结果，如果是持有槽的主节点故障，需要为该节点进行故障转移
故障恢复：故障发现后，如果下线节点的是主节点，则需要在它的从节点中选一个替换它，以保证集群的高可用
分布式锁可能存在锁过期释放，业务没执行完的问题能不能将锁的过期时间设置得长点来解决此问题呢？显然是不太好的，业务的执行时间是不确定的Redisson解决该问题，给获得锁得线程开启定时守护线程，每隔一段时间检查锁是否存在，存在则延长锁的过期时间，防止锁过期提前释放
线程一在Redis的master节点上拿到了锁，但是加锁的key还没同步到slave节点，恰好这时master节点发生故障，一个slave节点就会升级为master节点，线程二就可以获取同个key的锁啦，但线程一也已经拿到锁了，锁的安全性就没了
Redlock解决这个问题，即部署多个Redis master以保证它们不会同时宕掉，并且这些master节点是免费云主机域名完全相互独立的，相互之间不存在数据同步，实现步骤如下
更新数据库后延迟休眠一会再删除缓存这种方案还可以，只有休眠那一会可能有脏数据，一般业务也会接受的但是如果第二次删除缓存失败呢？缓存和数据库的数据还是可能不一致给Key设置一个自然的expire过期时间，让它自动过期怎样？业务在该过期时间内接受的数据的不一致怎么办？还是有其他更佳方案
延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题删除失败就多删除几次呀，保证删除缓存成功就可以了呀，所以可以引入删除缓存重试机制
重试删除缓存机制会造成好多业务代码入侵，所以引入读取biglog异步删除缓存
感谢各位的阅读，以上就是“Redis集群与扩展知识点分析”的内容了，经过本文的学习后，相信大家对Redis集群与扩展知识点分析这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是百云，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: Oracle如何查看表空间的大小及使用情况

这篇文章主要介绍Oracle如何查看表空间的大小及使用情况，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！ –1、查看表空间的名称及大小 SELECT t.tablespace_name, round(SUM(bytes / (1024…