² 相关说明

  1.    此处搭建的Redis架构为“一主两从三哨兵”，其工作原理：主节点（Master）可读可写，从节点（Slave，推荐2个以上）实时同步主节点的数据，只能读，不能写。哨兵（Sentinel，推荐3或5个）用于监测节点状态，一旦主节点挂掉，哨兵会进行投票，从剩下的Slave中选取一个作为Master，从而组成新的集群。若原主节点恢复，它会被自动的加入到这个新的集群中，成为一个Slave。哨兵至少需要两个才能实现该功能。
  3.    Redis节点部署如下表所示：
主机名 IP 端口 暴露地址
master 192.169.0.31 6379 N.A
slave1 192.169.0.32 6379 N.A
slave2 192.169.0.33 6379 N.A
Sentinel1 192.169.0.41 26379 192.168.0.101:26379
Sentinel2 192.169.0.42 26379 192.168.0.101:26380
Sentinel3 192.169.0.43 26379 192.168.0.101: 26381

² 获取镜像

| # _查看可用的稳定版本
$ sudo docker search redis
$ sudo** docker pull redis:3.2.12 | | —- |

² 集群构建

| # 通过docker-compose搭建mysql
$ cd /share
$ vi docker-compose.yml
__
# _构建集群
$ sudo_ docker-compose -f docker-compose.yml build —no-cache # _不带缓存构建
$ sudo_ docker-compose -f docker-compose.yml up -d —scale sentinel=3 # _构建后运行
$ sudo_ docker-compose -f docker-compose.yml up —build # _跟踪方式构建，可用于调试
**# 扩展哨兵节点（单独扩展，推荐哨兵节点数量为3或者5_个）
**$ sudo** docker-compose scale sentinel=3_ | | —- |

² 验证集群

| # _查看进程
$ sudo docker-compose -f docker-compose.yml ps
# __进入redis-master
$ sudo docker exec -it redis-master redis-cli
$ sudo docker exec -it redis-master bash
$ redis-cli -p 6379
# __验证密码
**_redis> auth “lonton”
# __存取数据
redis> set a 2
OK
redis> get a
“2”
# __暂停master
$ sudo docker pause redis-master
# __停止
**$ sudo** docker-compose -f docker-compose.yml stop
**# 移除
$ sudo** docker-compose -f docker-compose.yml down
**# 停止并清除所有容器
$ sudo docker stop $(sudo docker ps -q) & sudo docker rm $(sudo docker ps -aq) | | —- |

² HA测试

  1.    测试案例规划：
案例 描述 预期
test_case_001 Master节点宕机（1个节点），检测集群是否可以提供缓存读写服务 Master宕机将触发集群重新选举，新选举出来的Master节点将提供写服务，Master及所有Slave节点提供读服务
test_case_002 Slave节点宕机（1个节点），检测集群是否可以提供缓存读写服务 Master节点继续提供写服务，Master及剩余Slave节点提供读服务
test_case_003 Sentinel节点宕机（1个节点），检测集群是否可以提供缓存读写服务 Sentinel宕机（存活哨兵数量大于1）集群维持原状，正常提供读写服务
test_case_004 节点恢复（Master节点宕机后恢复） 集群维持原状，节点恢复后成为Slave节点，Master节点继续提供写服务，Master及Slave节点（包含由Master恢复的Slave节点）提供读服务

ü test_case_001

| # __停止redis-master
$ sudo docker pause redis-master

# __进入redis-slave2（slave2被成为主节点（也可能为slave1被选举为Master），以slave2选举成功为例）
$ sudo docker exec -it redis-slave2 redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication

# __进入其他slave节点
$ sudo docker exec -it redis-slave1 redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication
| | —- |

  1.    测试结果：redis-master节点停止服务后，由于redis-slave2补位为主节点，可提供读写功能，所以redis-slave1还是从节点，只具备读取功能。

ü test_case_002

| # __停止redis-slave1
$ sudo docker pause redis-slave1

# __进入redis-master
$ sudo docker exec -it redis-master redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication

# __进入redis-slave2
$ sudo docker exec -it redis-slave2 redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication
| | —- |

  1.    测试结果：redis-slave1节点停止服务后，redis-master仍为主节点，可提供读写功能， redis-slave2还是从节点，只具备读取功能。

ü test_case_003

| # __停止redis-sentinel1
$ sudo docker pause share_sentinel_1

# __进入redis-master/redis-slave1/redis-slave2，节点角色未发生改变（此处以Master为例）
$ sudo docker exec -it redis-master redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication
| | —- |

  1.    测试结果：redis-sentinel节点停止服务后，Redis集群维持原状，redis-master仍为主节点，可提供读写功能，redis-slave1/redis-slave2还是从节点，只具备读取功能。

ü test_case_004

| # __恢复redis-master（重启或者恢复pause状态）
$ sudo docker unpause redis-master

# __进入redis-master，发现其现在成为Slave
$ sudo docker exec -it redis-master redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication

# __进入redis-slave2，发现其依然还是Master
$ sudo docker exec -it redis-slave2 redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication

# __进入其他slave节点，发现其依然还是Slave
$ sudo docker exec -it redis-slave1 redis-cli
# __查看当前redis节点角色（Master/Slave）
redis> info replication
| | —- |

  1.    测试结果：redis-master节点恢复运行后，其成为Slave节点，只具备读取功能。由于redis-slave1之前升级为主节点，依然保持为Master，可提供读写功能，redis-slave2依然还是从节点，只具备读取功能。