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.