共计 2031 个字符，预计需要花费 6 分钟才能阅读完成。
1 Redis 集群实现
1.1 Redis 集群
1.1.1 为什么要搭建集群
通常，为了进步网站响应速度，总是把热点数据保留在内存中而不是间接从后端数据库中读取。
Redis 是一个很好的 Cache 工具。大型网站利用，热点数据量往往微小，几十 G 上百 G 是很失常的事儿。
因为内存大小的限度，应用一台 Redis 实例显然无奈满足需要，这时就须要应用多台 Redis 作为缓存数据库。然而如何保证数据存储的一致性呢, 这时就须要搭建 redis 集群. 采纳正当的机制, 保障用户的失常的拜访需要.
采纳 redis 集群, 能够保证数据扩散存储, 同时保证数据存储的一致性. 并且在外部实现高可用的机制. 实现了服务故障的主动迁徙.
1.1.2 集群搭建打算
主从划分:
3 台主机 3 台从机共 6 台 端口划分 7000-7005
1.2 集群搭建
1.2.1 筹备集群文件夹
1. 筹备集群文件夹
Mkdir cluster
2. 在 cluster 文件夹中别离创立 7000-7005 文件夹
1.2.2 复制配置文件
阐明:
将 redis 根目录中的 redis.conf 文件复制到 cluster/7000/ 并以原名保留
cp redis.conf cluster/7000/
1.2.3 编辑配置文件
- 正文本地绑定 IP 地址
- 敞开保护模式
- 批改端口号
- 启动后盾启动
- 批改 pid 文件
- 批改长久化文件门路。7000 目录下
- 设定内存优化策略
- 敞开 AOF 模式，这个能够关，也能够开着
- 开启集群配置
- 开启集群配置文件
- 批改集群超时工夫
1.2.4 复制批改后的配置文件
阐明: 将 7000 文件夹下的 redis.conf 文件别离复制到 7001-7005 中
[root@localhost cluster]# cp 7000/redis.conf 7001/
[root@localhost cluster]# cp 7000/redis.conf 7002/
[root@localhost cluster]# cp 7000/redis.conf 7003/
[root@localhost cluster]# cp 7000/redis.conf 7004/
[root@localhost cluster]# cp 7000/redis.conf 7005/
1.2.5 批量批改
阐明: 别离将 7001-7005 文件中的 7000 改为对应的端口号的名称,
批改时留神方向键的应用
在 cluster 目录下：vim 7001/redis.conf，进入编辑页面，留神不要按 i，间接输出：
:%s/7000/7001/g。输出完后回车，而后:wq。保留退出
7000 是要替换的数据，7001 是查找的数据。
1.2.6 通过脚本编辑启动 / 敞开指令
- 创立启动脚本 vim start.sh
- 编辑敞开的脚本 vim shutdown.sh
- 启动 redis 节点
sh start.sh
- 查看 redis 节点启动是否失常
1.2.7 创立 redis 集群
5.0 版本执行 应用 C 语言外部治理集群
redis-cli –cluster create –cluster-replicas 1 192.168.35.130:7000 192.168.35.130:7001 192.168.35.130:7002 192.168.35.130:7003 192.168.35.130:7004 192.168.35.130:7005
1.2.8 Redis 集群高可用测试
- 敞开 redis 主机. 查看是否主动实现故障迁徙.
- 再次启动敞开的主机. 查看是否可能实现主动的挂载.
个别状况下 可能实现主从挂载
个别情况: 宕机后的节点重启, 可能挂载到其余主节点中(7001-7002) 正确的
1.3 Redis 集群原理
1.3.1 Redis 集群高可用推选原理
如图 -24 所示
图 - 24
原理阐明:
Redis 的所有节点都会保留以后 redis 集群中的全副主从状态信息. 并且每个节点都可能互相通信. 当一个节点产生宕机景象. 则集群中的其余节点通过 PING-PONG 检测机制查看 Redis 节点是否宕机. 当有半数以上的节点认为宕机. 则认为主节点宕机. 同时由 Redis 残余的主节点 进入选举机制. 投票选举链接宕机的主节点的从机. 实现故障迁徙.
1.3.2 Redis 集群宕机条件
特点: 集群中如果主机宕机, 那么从机能够持续提供服务,
当主机中没有从机时, 则向其它主机借用多余的从机. 持续提供服务. 如果主机宕机时没有从机可用, 则集群解体.
答案:9 个 redis 节点, 节点宕机 5 - 7 次时集群才解体.
如图 -25 所示:
图 - 25
1.3.3 Redis hash 槽存储数据原理
阐明: RedisCluster 采纳此分区，所有的键依据哈希函数 (CRC16[key]%16384) 映射到 0-16383 槽内，共 16384 个槽位，每个节点保护局部槽及槽所映射的键值数据. 依据主节点的个数, 平衡划分区间.
算法: 哈希函数: Hash()=CRC16[key]%16384
如图 -26 所示
图 - 26
当向 redis 集群中插入数据时, 首先将 key 进行计算. 之后将计算结果匹配到具体的某一个槽的区间内, 之后再将数据 set 到治理该槽的节点中.
如图 -27 所示
图 - 27
