Redis集群（主从模式）

主从模型

  在Redis的集群当中，每个节点（实例）都有一个身份：Master或者Slave，Master：主要负责数据写入，Slave一般提供数据读取，Master与Slave之间是一对多关系，Master对应的Slave是其数据副本（replication），因此每次Master数据更新时同时要更新Slave中的内容。

  但是在Master下属的Slave过多时，给对应的Slave分发数据更新请求会占用Master很多的带宽资源，因此在此基础上，需要一个Master-slave，其作为Master的下属Slave，功能除了和其他Slave一样提供数据读取服务之外，需要接纳一部分的Slave，为Master分担发送数据更新通知任务，减轻Master信息发送负担。

缺陷

• 一旦Master宕机失效，需要手动将Slave角色提升为Master，否则这个子集群将不可用。从自动性可用性角度来看，这个效果非常不尽人意。而在下一篇中将介绍Redis解决这个问题使用的哨兵（sentinel）机制。

  
  

• Redis Cluster不保证强一致性（Strong Consistency），设想这样一个场景：
  • 1.Master A从Client获取写请求WRITE_INFO并写入
  • 2.Master A返回OK
  • 3.Master A将写入（或者是更新）请求传播给Slave A1，A2，A3
    其中2,3是异步执行的，由于这个原因，即使Slave没有写入或者更新数据（请求丢失或者I/O错误等），2中还是返回OK。当然也可以如果强制2,3同步执行，等待Slave写入成功后再返回OK，但这样会造成效率低下。

参考文献

  [1]redisLab.[EB/OL]. https://redis.io/topics/cluster-tutorial. 2019.01-2019.03.