之前学习了 Redis 哨兵机制和 Redis 哨兵集群建立过程，当主库发生故障时，Redis 哨兵可以将合适的从库切换成主库，这样就可以保证 Redis 的高可用了，但如果 Redis 数据量变大了就会面临扩容的问题，集群的实例增减，或为了实现负载均衡进行数据重新分布，会导致哈希槽和实例的映射关系发生变化，客户端发送请求时，会收到命令执行报错信息,如果了解 MOVED 和 ASK 命令，遇到类似报错信息就很容易理解了，这篇文章就来学习下 Redis Cluster 集群。
1.笔记图
2.Redis 扩容方式
- 纵向扩展：升级单个 Redis 实例的资源配置，包括增加内存容量、增加磁盘容量、使用更高配置的 CPU，其特点就是实施简单、直接，但会受到硬件和成本的限制
- 横向扩展：增加与当前 Redis 实例配置相同的实例，在面向百万、千万级别的用户规模时，横向扩展的 Redis 切片集群会是一个非常好的选择
3.切片集群需要思考
- 数据切片后，在多个实例之间如何分布？
- 客户端怎么确定想要访问的数据在哪个实例上？
4.哈希槽（Hash Slot）
- 一个切片集群共有 16384 个哈希槽，这些哈希槽类似于数据分区，每个键值对都会根据它的 key，被映射到一个哈希槽中
- 首先根据键值对的 key，按照 CRC16 算法计算一个 16 bit 的值
- 用这个 16bit 值对 16384 取模，得到 0~16383 范围内的模数，每个模数代表一个相应编号的哈希槽
5.相关命令
- cluster create 命令：Redis 会自动把这些槽平均分布在集群实例上，如 N 个实例，每个实例槽的个数 16384/N 个
- cluster meet 命令：手动建立实例间的连接，形成集群
- cluster addslots 命令：
- 指定每个实例上的哈希槽个数，如各个实例配置不一样，需要手动分配哈希槽
- 如上图所示一共有 3 个实例，同时假设有 5 个哈希槽，实例 1 保存哈希槽 0 和 1，实例 2 保存哈希槽 2 和 3，实例 3 保存哈希槽 4
redis-cli -h 172.16.19.3 –p 6379 cluster addslots 0,1 redis-cli -h 172.16.19.4 –p 6379 cluster addslots 2,3 redis-cli -h 172.16.19.5 –p 6379 cluster addslots 4
6.客户端定位数据
- 在定位键值对数据时，它所处的哈希槽是可以通过计算得到的，这个计算可以在客户端发送请求时来执行，
- 客户端和集群实例建立连接后，实例就会把哈希槽的分配信息发给客户端
- Redis 实例会把自己的哈希槽信息发给和它相连接的其它实例，来完成哈希槽分配信息的扩散
- 客户端收到哈希槽信息后，会把哈希槽信息缓存在本地
7.Redis Cluster重定向机制
- 哈希槽变化：如在集群中，实例有新增或删除，Redis 需要重新分配哈希槽，为了负载均衡，Redis 需要把哈希槽在所有实例上重新分布一遍
- 客户端给一个实例发送数据读写操作时，这个实例上并没有相应的数据，客户端要再给一个新实例发送操作命令
- MOVED 命令:
- 如果这个实例上并没有这个键值对映射的哈希槽，就会给客户端返回 MOVED 命令响应结果，包含了新实例的访问地址
# 13320 哈希槽 172.16.19.5 新地址 6379 新实例端口号 GET hello:key (error) MOVED 13320 172.16.19.5:6379
- 如Slot 2 中的数据已从实例 2 迁到实例 3，客户端仍然记录着原 Slot 2 信息，所以会给实例 2 发送命令
- 实例 2 给客户端返一条 MOVED 命令，把 Slot 2 的最新位置（实例 3 上）返给客户端，客户端会向实例 3 发送请求并更新本地缓存
- ASK 命令：
- 如果 Slot 2 中的数据只有一部分迁移到了实例 3，还有部分数据没有迁移，客户端就会收到一条 ASK 报错信息
GET hello:key (error) ASK 13320 172.16.19.5:6379
- ASK 命令并不会更新客户端缓存的哈希槽分配信息
