切片集群 (分片集群) : 启动多个 Redis 实例组成一个集群，再按一定的规则，把收到的数据划分成多份，每份用一个实例来保存
切片集群架构图 :
- 25G 实例 , 生成 RDB , fork 子进程阻塞较长
- 5GB 的实例 , 生成 RDB 时，fork 子进程不会较影响主线程
查看最近一次 fork 耗时 :
- 越高，fork 越慢
info latest_fork_usec
Redis 扩展方案 :
- 纵向扩展 (scale up) : 升级 Redis 的资源配置
- 横向扩展 (scale out) : 增加 Redis 数
纵向扩展的优缺点 :
- 优点 : 扩展简单，直接
- 缺点 : RDB 持久化，容易阻塞主线程
- 受硬件和成本的限制
横向扩展的优缺点 :
- 优点 : 支持千万的用户量
- 不受硬件和成本的限制
数据切片
Redis 3.0 后，提供 Redis Cluster 方案，实现切片集群
映射过程 :
- 先对 key，按 CRC16 算法计算
16 bit值 - 再对
16bit值进行 16384 取模，得到 0~16383 内的哈希槽
数据、哈希槽、实例的分布情况 :
手动分配哈希槽 :
- 16384 个槽都要分配完，不然 Redis 集群无法工作
- 实例 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
数据定位
实例和哈希槽的对应关系的变化的两个：
- 实例有新增或删除，Redis 要重新分配哈希槽
- 为了负载均衡，把哈希槽重新分布下
Redis Cluster 利用重定向机制，解决缓存的分配信息和最新的分配信息不一致问题
- 重定向 : 客户端对该实例进行读写操作时，但该实例没有相应的数据，客户端再对新实例进行操作
MOVED 重定向例子 :
- 客户端请求的哈希槽 13320，在 172.16.19.5 上。客户端会和 172.16.19.5 连接
GET hello:key
(error) MOVED 13320 172.16.19.5:6379
客户端 MOVED 重定向 :
- Slot 2 的数据都从实例 2 移到实例 3
- 客户端缓存还记录 Slot 2 在实例 2上
- 客户端访问 Slat2 时, 会返回 MOVED ，把 Slot 2 的最新位置 (实例 3) 给客户端
- 客户端再向实例 3 发送请求，并更新客户端缓存
ASK例子 :
Slot 2 的数据还有部分数据没有迁移，客户端向实例 2 发送请求 , 会返回 ASK 报错信息
- ASK : 客户端请求的哈希槽 13320，在 172.16.19.5 上，但该哈希槽正在迁移
GET hello:key
(error) ASK 13320 172.16.19.5:6379
客户端 ASK 重定向 :文章来源：https://www.toymoban.com/news/detail-434012.html
- Slot 2 正从实例 2 往实例 3 迁移，key1 , key2 已迁移过去，但 key3 , key4 还在实例 2
- ASK 的含义 : Slot 数据还在迁移中；把 Slot 的最新实例给客户端
- 不会更新客户端缓存的哈希槽分配信息
文章来源地址https://www.toymoban.com/news/detail-434012.html
到了这里，关于Redis 切片集群的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
