Final
Docker
keepalived
sonarqube
Varnish
Openstack集群
Redis Cluster
Redis 分布式部署方案
- 客户端分区：由客户端程序决定 key 写分配和写入的 redis node，但是需要客户端自己处理写入分配、高可用管理和故障转移等
- 代理方案：基于三方软件实现 redis proxy，客户端先连接之代理层，由代理层实现 key 的写入分配，对客户端来说是有比较简单，但是对于集群管节点增减相对比较麻烦，而且代理本身也是单点和性能瓶颈
在哨兵 sentinel 机制中，可以解决 redis 高可用的问题，即当 master 故障后可以自动将 slave 提升为master 从而可以保证 redis 服务的正常使用，但是无法解决 redis 单机写入的瓶颈问题，即单机的 redis写入性能受限于单机的内存大小、并发数量、网卡速率等因素，因此 redis 官方在 redis 3.0 版本之后推出了无中心架构的 redis cluster 机制，在无中心的 redis 集群汇中，其每个节点保存当前节点数据和整个集群状态,每个节点都和其他所有节点连接，特点如下
1：所有 Redis 节点使用(PING 机制)互联
2：集群中某个节点的失效，是整个集群中超过半数的节点监测都失效才算真正的失效
3：客户端不需要 proxy 即可直接连接 redis，应用程序需要写全部的 redis 服务器 IP。
4：redis cluster 把所有的 redis node 映射到 0-16383 个槽位(slot)上，读写需要到指定的 redis node 上进行操作，因此有多少个 reids node 相当于 redis 并发扩展了多少倍。
5：Redis cluster 预先分配 16384 个(slot)槽位，当需要在 redis 集群中写入一个 key -value 的时候，会使用 CRC16(key) mod 16384 之后的值，决定将 key 写入值哪一个槽位从而决定写入哪一个 Redis 节点上，从而有效解决单机瓶颈
Redis cluster 基本架构
加入三个主节点分别是：A, B, C 三个节点，采用哈希槽 (hash slot)的方式来分配 16384 个 slot 的话
它们三个节点分别承担的 slot 区间是：
节点 A 覆盖 0－5460 规则CRC16(‘KEY’)%16384=5103
节点 B 覆盖 5461－10922 规则CRC16(‘KEY’)%16384=9981
节点 C 覆盖 10923－16383 规则CRC16(‘KEY’)%16384=15509
Redis cluster 主从架构
Redis cluster 的架构虽然解决了并发的问题，但是又引入了一个新的问题，每个 Redis master 的高可用如何解决
每个节点都有主从
节点A主从
节点B主从
节点C主从
部署 redis 集群
创建 redis cluster 集群的前提
1.每个 redis node 节点采用相同的硬件配置、相同的密码
2.每个节点必须开启的参数
cluster-enabled yes #必须开启集群状态，开启后 redis 进程会有 cluster 显示
cluster-config-file nodes-6380.conf #此文件有 redis cluster 集群自动创建和维护，不需要任何手动操作
3.所有 redis 服务器必须没有任何数据
4.先启动为单机 redis 且没有任何 key value
创建集群
redis 3 和 4 版本：
需要使用到集群管理工具 redis-trib.rb，这个工具是 redis 官方推出的管理 redis 集群的工具，集成在redis 的源码 src 目录下，是基于 redis 提供的集群命令封装成简单、便捷、实用的操作工具，redis-trib.rb是 redis 作者用 ruby 完成的，centos 系统 yum 安装的 ruby 存在版本较低问题
源码编译 src目录有此文件 redis-trib.rb，redis 3 和 4 版本使用此命令创建集群
redis5版本以上可以使用redis-cli创建集群
检查状态
由于未设置 masterauth 认证密码，所以主从未建立起来，但是集群已经运行，所以需要在每个 slave控制台使用 config set 设置 masterauth 密码，或者写在每个 redis 配置文件中，最好是在控制点设置密码之后再写入配置文件当中
查看集群node对应关系
分别设置 masterauth 密码
验证集群的状态
验证集群写入 key
集群状态监控
Redis cluster 集群节点维护
集群运行时间长久之后，难免由于硬件故障、网络规划、业务增长等原因对已有集群进行相应的调整，比如增加 Redis node 节点、减少节点、节点迁移、更换服务器等。
增加节点和删除节点会涉及到已有的槽位重新分配及数据迁移
集群维护之动态添加节点
增加 Redis node 节点，需要与之前的 Redis node 版本相同、配置一致，然后分别启动两台 Redis node，因为一主一从
添加节点
添加主机之后需要对添加至集群种的新主机重新分片否则其没有分片
验证当前状态
验证重新分配槽位之后的集群状态
重新分配槽位是自动从每个 Redis node 上移动一些槽位到新的 master 上
为新的 master 添加 slave 节点
更改新节点更改状态为 slave
集群维护之动态删除节点
添加节点的时候是先添加 node 节点到集群，然后分配槽位，删除节点的操作与添加节点的操作正好相反，是先将被删除的 Redis node 上的槽位迁移到集群中的其他 Redis node 节点上，然后再将其删除。如果一个 Redis node 节点上的槽位没有被完全迁移，删除该 node 的时候会提升有数据且无法删除
迁移 master 的槽位之其他 master被迁移 Redis 服务器必须保证没有数据
从集群删除服务器
虽然槽位已经迁移完成，但是服务器 IP 信息还在集群当中，因此还需要将 IP 信息从集群删除
验证集群 Master 与 Slave 对应关系
Redis Slave 节点一定不能个 master 在一个服务器，必须为跨主机交叉备份模式，避免主机故障后主备全部挂掉，如果出现 Redis Slave 与 Redis master 在同一台 Redis node 的情况，则需要安装以上步骤重新进行 slave 分配，直到不相互交叉备份为止
集群维护之模拟 Master 宕机
目前的架构为三主三从，互为跨主机 master slave 模式，测试 master 宕机之后是否会自动切换至 slave
测试数据写入
set k1 v2
slave 验证数据
slave 不提供读写，只提供数据备份即 master 选举
停止 master 并验证故障转移
Redis Master 服务停止之后，其对应的 slave 会被选举为 master 继续处理数据的读写操作
日志验证
验证数据读写
注：服务恢复之后重新验证各 master 的 slave
启动master后
查看下日志及应用的状态
CONFIG SET masterauth 123456
验证下数据
集群维护之导入现有 Redis 数据
导入数据需要 redis cluster 不能与被导入的数据有重复的 key 名称，否则导入不成功或中断
导入数据之前需要关闭各 redis 服务器的密码，包括集群中的各 node 和源 Redis server，避免认证带来的环境不一致从而无法导入，可以加参数–cluster-replace 强制替换 Redis cluster 已有的 key
CONFIG SET requirepass “”
执行数据导入
将源 Redis server 的数据直接导入之 redis cluster
redis-cli –cluster import 集群服务器 IP:PORT –cluster-from 外部 Redis node-IP:PORT –cluster-copy –cluster-replace
redis-cli –cluster import 192.168.10.2:6379 –cluster-from 192.168.10.8:6379 –cluster-copy
小结
1、redis主写数据，从同步，从不可写和读，只有切换成才可读写
2、cluster有槽位，类似于分布式存储，不同的数据放在不同的地方，3个节点分别存储不同的数据，当一个A主节点挂了，A从节点代替工作，若A主从都挂了，则数据丢失
3、cluster 日志 密码 添加节点、删除节点、修改槽位、迁移数据、导入数据等
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 438803792@qq.com
Loading...