Redis核心技术-高可靠-集群（cluster）

  如果我们的业务需要32GRedis实例，我们创建一个32GRedis实例还是有其他的解决方案呢？

  Redis Cluster 从Redis 3.0开始支持使用，用于实现切片集群。
  Redis Cluster 保证CAP中的可用性和一致性。

  为了支持大容量Redis提出的方案，多个Redis实例存储不同的key和value。Redis 官方提供的解决方案是Redis Cluster，哈希槽便是用来处理数据和实例之间的关系。

  为什么不使用更大的内存的Redis？
  内存更大，持久化和恢复时间越长；需要更大内存和更强CPU支持。

  Redis Cluster 不使用一致性散列，而是一种不同形式的分片，其中每个key在概念上都是我们所谓的散列槽的一部分。

  Redis 集群中有 16384 个哈希槽（2的14次方），要计算key的哈希槽是多少，我们只需计算CRC16(key) % 16384。

  分配方式：
1.cluster create命令创建集群时，Redis把哈希槽平均分配给Redis实例，每个Redis实例分配哈希槽数量=16384/N(N为Redis实例数量);

2.cluster meet命令手动建立Redis实例间的连接，形成集群，再通过cluster addslots命令指定每个Redis实例哈希槽个数（如果Redis实例内存、硬件配置不同比较适用）；

  client与cluster连接后，Redis实例会把哈希槽信息发送给client。

  cluster建立后Redis实例间相互连接，可以指定彼此分配到的哈希槽信息，所有client与一个Redis实例连接时可以知道所有Redis实例的哈希槽信息。

  client请求key时，先在本地计算key对应的哈希槽，再给对应的Redis实例发送key请求。

  添加Redis实例、添加Redis实例、手动修改Redis实例与哈希槽的映射都会重新分配哈希槽，Redis实例可以相互连接通信指定彼此的哈希槽信息，但是client不知道Redis与哈希槽信息发送变更。

  cluster 提供重定向机制，client发送key操作到Redis实例，并且key对应的哈希槽不属于当前Redis实例，那么便会返回MOVED命令响应client。

GET testKey1
(error) MOVED 13320 172.16.19.5:6379

  client 重新向172.16.19.5:6379 发送key操作，并且重新更新Redis实例与哈希槽映射关系。

  cluster添加新Redis实例时，cluster重新分配哈希槽、属于新Redis实例的key从原来的Redis实例迁移过去。

  迁移过程中，client需要操作key，会出现什么情况呢？

GET testKey1
(error) ASK 13320 172.16.19.5:6379

  ASK命令表示key对应的哈希槽为13320，172.16.19.5:6379 Redis实例上，但是当前正在迁移。

  client需要向172.16.19.5:6379实例发送ASKING命令，让实例允许client接下来的key操作，client再向172.16.19.5:6379实例发送GET testKey1 操作。

  ASK命令和MOVED命令不同，ASK命令client不会更新本地Redis实例与哈希槽的映射缓存，ASK命令让client把key操作重新请求一次返回去的Redis实例。

  MULTI/EXEC事务命令、mget、mset等多key操作时，Redis是否支持？如支持同一个Redis节点处理还是离散到其他Redis节点处理？

  Redis Cluster 支持多键操作，只要涉及到单个命令执行（或整个事务，或 Lua 脚本执行）的所有key都属于同一个哈希槽。用户可以使用称为散列标签的概念强制多个key成为同一个散列槽的一部分。

参考：
https://redis.io/topics/cluster-tutorial