Redis分布式存储的3种常见方案与Redis集群切片的几种常见方式

Redis支持的数据类型要丰富得多，常用的数据类型主要有五种：String、List、Hash、Set和Sorted Set（ZSet）

redis分布式存储的常见方案：

主从（Master/Slave）模式：

从服务器初始化完成后，Redis主服务器每执行一个写命令就会向Redis从服务器发送相同的写命令，Redis从服务器接收并执行收到的写命令（需要从服务器初始化完成后的操作）
主从（Master/Slave）模式是常见的集群架构，搭建简单，主要实现读写分离和备份，可以由Master负责读写，Slave负责备份。但存在故障恢复复杂、水平拓展难、写能力受限等问题

哨兵（Sentinel）模式：

Redis SenTInel是社区版本推出的原生高可用解决方案。由一或多个哨兵实例监视任意个主从服务器，且在Master宕机时，自动将宕机服务器属下的Slave服务器升级为主服务器，从而保证系统的可用性。哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。哨兵模式使主从可以自动切换，系统更健壮，可用性更高。

集群(Cluster)模式：

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。
在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

Redis集群切片的几种常见方式：

客户端实现分片

分区逻辑在客户端实现，客户端采用一致性哈希决定redis节点。在集群刚刚创建的时候，每个实例只知道自己被分配了哪些哈希槽，是不知道其他实例拥有的哈希槽信息的。但是，Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散。

所以当客户端和集群实例连接后，就可以知道所有的哈希槽的映射，客户端会把哈希槽的映射保存在本地，这样如果客户端响应一个 KEY ，计算出哈希槽，然后就可以向对应的实例发送请求了。

中间件实现分片

在应用软件和redis之间，例如Twemproxy、Codis等，由中间件实现服务到后台redis节点的路由分派。由proxy负责分片，然后客户端与proxy交互，proxy计算key所在的节点，并把请求发送到对应的节点

客户端服务端协作分片

redis cluster集群模式，客户端采用一致性哈希，服务端提供错误节点的重定向服务。
客户端可以发起请求到集群中的任意一个节点。节点收到请求，若key存在于自身节点，则直接返回结果，若key不存在则告诉客户端key不存在，通过计算映射规则确定查询的key所在的节点，然后去这个节点查询，也就是一个重定向的过程。（Redis官方支持）