蓝盟IT小贴士，来喽！
独立的Redis说性能很好，也有完全的持久化机制，如果你的商务量真的很大，超过了独立能搭载的上限怎么办？ 什么都不做Redis挂了怎么办？ 带着这个问题开始我们今天的主题“-「Redis高可用性”。 为了篇幅方便，本章只说明主从复制。
为什么首先要从主从复制开始，因为“主从复制”可以说是Redis整体高可用性实现的基础，所以首先可以有这样的概念。 具体为什么是基础，接下来谈谈Sentinel和Redis集群。
首先，我们需要知道为什么开发人员需要“主从架构”。 Redis实例不行吗？
其实开头提到的负荷不仅超过了Redis单体能够处理的上限，有时Redis也无法保证自身的高可用性。 即使Redis能承载所有的流量，如果这个Redis进程所在的机器挂起了呢？ 要求直接转动枪口，大量流量瞬间挂起你的DB，然后你可以背P0，打包回家。
另外，如果对Redis的需求真的超过了单体的容量，该怎么办？ 是否要创建多个独立的Redis实例？ 那么，如果用户缓存的数据这次存在于实例1中，下次用户访问实例2，是否要再次去DB？ 除非用户和Redis实例保持对应关系(但这样的逻辑通常很复杂)，否则部署多个Redis实例将失去意义，不能横向扩展。
如果改成主从架构可以解决这个问题吗？
我们可以从一张图中直观地知道。
在主从同步中，节点的角色分为master和slave形成“一主多从”。 slave向外部提供读取操作，但master负责写入操作，形成读写分离的体系结构，从而可以托管更多的业务请求。
在许多业务场景中，对Redis的“读取操作”比“写入操作”多，因此在读取请求量特别大的情况下，可以通过增加slave节点使Redis承担更多的通信量。
你不行啊，弟弟，你把数据写给master。 那么，连接从站后，就不能取得以前的数据了吗？
我这个标题不是写的吗？ “主从复制”，从站根据某种策略从主站同步数据。 在Redis中，可以使用slaveof命令将另一个Redis的状态复制(复制)到一个Redis实例。 复制的Redis实例是master节点，执行slaveof命令的计算机是slave节点。Redis的主从复制分为两个步骤：“同步”和“命令传播”。
“同步操作”用于将Master节点的内存状态复制到Slave节点，而“命令传播”在同步时客户端执行一些“写入”操作来更改服务器的状态。 在这种情况下，Master节点的状态与执行同步操作时不一致，因此需要命令来传播Master和Slave。

文/上海蓝盟  IT外包专家

• 上一篇: 蓝盟IT外包，元宇宙：四梁八柱是什么
  下一篇: 蓝盟IT外包，人工智能开放平台的建设很热，AI发展未来的可能性。

• 分享到：