说明:最近公司在自己搭建了一套redis主从读写分离+sentinel哨兵集群主备切换，通过手工去搭建replication复制+主从架构+读写分离+哨兵集群+高可用redis集群架构
公司的已经搭建好了，接下来我会慢慢的整理资料，写到文章里
很多小规模公司用的redis都是单机的，上一家公司也是单机，然后主备切换，容灾都没有，redis有时候出故障，宕机了，然后就会导致网站瘫痪无法访问
单机模式
redis主从集群+sentinel主备切换，下面这张图是，已经搭好的经典sentinel三节点哨兵集群
如何搭建redis架构，每秒钟几十万的访问量QPS，99.99%的高可用性，TB级的海量的数据，备份和恢复？
备份和恢复
先说下这个，因为这个也是很重要好的
在redis存储数据的时候，redis数据是存储在内存中，如果redis出现了灾难性的故障时，那内存中的数据也会丢失，这时候就需要将redis数据持久到磁盘中；
然后redis备份数据的方式有两种，一种是RDB，还有一个就是AOF
两种方式有什么区别了？
RDB持久化机制，对redis中的数据执行周期性的持久化，简单来说就是隔一段时间生成快照方式
AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集
RDB和AOF优缺点？
RDB优点：
（1）、RDB会生成多个数据文件，每个数据文件都代表了一个时刻中的redis数据，这种多数据文件方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程服务器安全存储
（2）、RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可
（3）、相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速
RDB缺点：
（1）、RDB数据快照文件，都是每个几分钟或者更长时间生成一次的，这个时候redis宕机了，就有可能会丢失这几分钟的数据，这个问题也是RDB最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。
（2）、RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供服务暂停数毫秒，或者甚至数秒，一般不要让RDB的间隔太长，否则每次生成RDB文件太大，对redis本身性能可能会有影响。
AOF优点：
（1）、AOF可以更好的保护数据不丢失，一般AOF会每个1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据；每个1秒钟，就会执行一次fsync操作，保证os cache的数据写入磁盘中。
（2）、AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复。
（3）、AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写，因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来，再创建新日志文件的时候，老日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
（4）、AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删除了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。
AOF缺点
（1）、对于一份数据来说，AOF日志通常比RDB数据快照文件更大。
（2）、AOF开启后，支持写的QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的。
（3）、唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适。
RDB和AOF到底该如何选择？
（1）、不要仅仅使用RDB，因为那样会导致你丢失很多数据。
（2）、也不要仅仅使用AOF，因为那样有两个问题，第一、你通过AOF做冷备，也没有RDB做冷备，来恢复速度更快；第二、RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制bug
（3）、综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可修复的时候，还可以使用RDB来进行快速的数据恢复。
如何使用RDB和AOF备份恢复？
下面先简单说明下，以生产环境方式部署我们的redis
准备一台服务器：
（1）、关闭防火墙：
systemctl stop firewalld
systemctl disable firewalld
vi /etc/selinux/config
SELINUX=disabled
（2）、配置yum
yum clean all
yum makecache
yum install wget
（3）、安装配置jdk
jdk下载地址 https://pan.baidu.com/s/1PsGpmjn9pMOOt4jvEdkzaA j265
也可以自己官网下载，自行配置jdk
cd /usr/local/
rm -rf * (新服务器，rm -rf 需谨慎)
将下载好的jdk包上传到/usr/local/
unzip jdk1.8.0_121.zip
ln -s jdk1.8.0_121 jdk8
配置jdk环境
vi /etc/profile
export JAVA_HOME=/usr/local/jdk8
export PATH=$PATH:$JAVA_HOME/bin
保存退出执行
source /etc/profile
验证
java -version
如果报错权限不足
cd /usr/local/jdk8/bin
chmod 755 *
（4）安装gcc、perl
为什么要装perl？我们整个大型电商网站的详情页系统，复杂。java+nginx+lua，需要perl。
perl，是一个基础的编程语言的安装，tomcat，跑java web应用
yum install -y gcc
wget http://www.cpan.org/src/5.0/perl-5.16.1.tar.gz
tar -zxvf perl-5.16.1.tar.gz
cd perl-5.16.1
./Configure -des -Dprefix=/usr/local/perl
make && make test && make install
perl -v
（5）、修改hosts
vi /etc/hosts
ip地址 redis-cache01
（6）、下面开始安装单机版redis
wget http://downloads.sourceforge.net/tcl/tcl8.6.1-src.tar.gz
tar -zxvf tcl8.6.1-src.tar.gz
cd /usr/local/tcl8.6.1/unix/
./configure --prefix=/usr/local/tcl
make && make install
配置环境变量
vi /etc/profile
export JAVA_HOME=/usr/local/jdk8
export TCL_HOME=/usr/local/tcl
export PATH=$PATH:$JAVA_HOME/bin:$TCL_HOME/bin
保存退出
source /etc/profile
（7）、下载redis
https://pan.baidu.com/s/1PsGpmjn9pMOOt4jvEdkzaA j265
为了大家搭建环境都一样哈，我把软件都放在上面网盘，大家可以直接下载
cd /usr/local
上传 redis-3.2.8.tar.gz 到 /usr/local
tar -zxvf redis-3.2.8.tar.gz
cd redis-3.2.8
make && make test && make install
（8）、下面以生产环境方式部署redis启动方案
首先创建文件夹
mkdir -p /var/redis/6379 (存放redis持久化文件RDB、AOF)
mkdir /etc/redis (存放redis配置文件)
cp /usr/local/redis-3.2.8/redis.conf /etc/redis/6379.conf
cp /usr/local/redis-3.2.8/utils/redis_init_script /etc/init.d/redis_6379
修改配置文件
vi 6379.conf
bind 本机ip地址(不是127.0.0.1，192的)
daemonize yes (让redis以daemon进程运行)
pidfile /var/run/redis_6379.pid (设置redis的pid文件位置)
port 6379 (设置redis监听端口)
dir /var/redis/6379 (设置redis持久化文件地址)
修改启动文件
vi redis_6379
#chkconfig: 2345 90 10
#description: Redis is a persistent key-value database
保存退出
chkconfig redis_6379 on (设置redis跟随系统启动)
启动redis
/etc/init.d/redis_6379 start
ps -ef|grep redis (查看redis是否启动成功)
测试redis
redis-cli -h 192.168.0.201(你自己的ip)
set mykey1 value1
get mykey1
以上就是单机生产环境redis部署方案
现在来配置RDB以及AOF持久化
RDB配置
其实RDB默认是开启的
save 60 10000 (保存策略每60秒有10000条数据发生变化)
AOF配置
appendonly yes
appendfsync everysec (生成策略默认选择everysec)
auto-aof-rewrite-percentage 100 (就是当前AOF大小膨胀到超过上次100%，上次的两倍)
auto-aof-rewrite-min-size 64mb (根据你的数据量来定，16mb，32mb)
修改完配置文件重启redis服务即可，然后可以到/var/redis/6379下看看文件
dump.rdb appendonly.aof
注意
如果同时开启RDB和AOF持久，启动恢复数据的时候，会默认优先使用AOF恢复数据，所以恢复数据前先确保appendonly.aof文件中是否有数据，如果appendonly.aof中没有数据，就要通过dump.rdb文件进行恢复了；
方案是：
（1）、先删除appendonly.aof文件
（2）、然后关闭appendonly on
（3）、再启动redis服务，这时候数据就会从dump.rdb中恢复
（4）、在热开启appendonly使用redis-cli -h ip连上服务器，使用命令修改config set appendonly yes，这个时候appendonly也已经被热开启，但真真的6379.conf配置文件中并没有修改，所以我们要先确认热开启之后，/var/redis/6379下appendonly.aof数据文件是否已经从新生成，数据如果已经生成，这时候需要停掉服务，
（5）、再次修改配置文件6379.conf ，appendonly on改成appendonly yes，再重启redis即可完成
至于具体怎么测试是否持久，自己可以尝试下
先不开启AOF，使用默认的RDB持久策略，写入几条数据，然后kill -9 redis_pid，模拟异常退出，然后再启动redis，这时候数据是没有持久到磁盘中的，因为RDB默认策略是60秒10000条数据的时候才会生成RDB快照文件
以上就是redis生产环境部署以及备份恢复
下面就写下如何部署redis主从读写分离集群
为什么要搭建redis集群？
单机redis
集群读写分离redis高并发
本讲主从复制数据是通过redis replication
redis replication核心机制
（1）redis采用异步方式复制数据到slave节点，不过redis 2.8开始，slave node会周期性地确认自己每次复制的数据量
（2）一个master node是可以配置多个slave node的
（3）slave node也可以连接其他的slave node
（4）slave node做复制的时候，是不会block master node的正常工作的
（5）slave node在做复制的时候，也不会block对自己的查询操作，它会用旧的数据集来提供服务; 但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务了
（6）slave node主要用来进行横向扩容，做读写分离，扩容的slave node可以提高读的吞吐量
redis replication图解
redis主从、断点续传原理图解
1、redis replication完整复制流程
（1）、slave node启动，仅仅保存master node的信息，包括master node的host和ip，但是复制流程没开始
master host和ip是从哪儿来的，redis.conf里面的slaveof配置的
（2）、slave node内部有个定时任务，每秒检查是否有新的master node要连接和复制，如果发现，就跟master node建立socket网络连接
（3）、slave node发送ping命令给master node
（4）、口令认证，如果master设置了requirepass，那么salve node必须发送masterauth的口令过去进行认证
（5）、master node第一次执行全量复制，将所有数据发给slave node
（6）、master node后续持续将写命令，异步复制给slave node
2、数据同步相关的核心机制
指的就是第一次slave连接msater的时候，执行的全量复制，那个过程里面你的一些细节的机制
（1）、master和slave都会维护一个offset
master会在自身不断累加offset，slave也会在自身不断累加offset
slave每秒都会上报自己的offset给master，同时master也会保存每个slave的offset
这个倒不是说特定就用在全量复制的，主要是master和slave都要知道各自的数据的offset，才能知道互相之间的数据不一致的情况
（2）、backlog
master node有一个backlog，默认是1MB大小
master node给slave node复制数据时，也会将数据在backlog中同步写一份
backlog主要是用来做全量复制中断候的增量复制的
（3）、master run id
info server，可以看到master run id
如果根据host+ip定位master node，是不靠谱的，如果master node重启或者数据出现了变化，那么slave node应该根据不同的run id区分，run id不同就做全量复制
如果需要不更改run id重启redis，可以使用redis-cli debug reload命令
run id图解
（4）、psync
从节点使用psync从master node进行复制，psync runid offset
master node会根据自身的情况返回响应信息，可能是FULLRESYNC runid offset触发全量复制，可能是CONTINUE触发增量复制
3、全量复制
（1）master执行bgsave，在本地生成一份rdb快照文件
（2）master node将rdb快照文件发送给salve node，如果rdb复制时间超过60秒（repl-timeout），那么slave node就会认为复制失败，可以适当调节大这个参数
（3）对于千兆网卡的机器，一般每秒传输100MB，6G文件，很可能超过60s
（4）master node在生成rdb时，会将所有新的写命令缓存在内存中，在salve node保存了rdb之后，再将新的写命令复制给salve node
（5）client-output-buffer-limit slave 256MB 64MB 60，如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么停止复制，复制失败
（6）slave node接收到rdb之后，清空自己的旧数据，然后重新加载rdb到自己的内存中，同时基于旧的数据版本对外提供服务
（7）如果slave node开启了AOF，那么会立即执行BGREWRITEAOF，重写AOF
rdb生成、rdb通过网络拷贝、slave旧数据的清理、slave aof rewrite，很耗费时间
如果复制的数据量在4G~6G之间，那么很可能全量复制时间消耗到1分半到2分钟
4、增量复制
（1）如果全量复制过程中，master-slave网络连接断掉，那么salve重新连接master时，会触发增量复制
（2）master直接从自己的backlog中获取部分丢失的数据，发送给slave node，默认backlog就是1MB
（3）msater就是根据slave发送的psync中的offset来从backlog中获取数据的
5、heartbeat
主从节点互相都会发送heartbeat信息
master默认每隔10秒发送一次heartbeat，salve node每隔1秒发送一个heartbeat
6、异步复制
master每次接收到写命令之后，现在内部写入数据，然后异步发送给slave node
复制原理图解
下面开始搭建我们的主从读写分离了
上面不是已经部署了一台redis吗，现在我们只需要在部署两台服务器就可以了
按照上面的步骤将jdk、perl、tcl、redis全部安装好
三台服务器修改 vi /etc/hosts
ip地址 redis-cache01
ip地址 redis-cache02
ip地址 redis-cache03 （这台服务器redis可以先不启动，只启动cache01,02一主一从）
这时候还需要做一件事，配置3台服务器秘钥登录
就是在三台服务器上执行ssh-keygen -t ras 一直回车就行
然后 cd /root/.ssh/目录下
cat id_rsa.pub >> authorized_keys
然后将另外两台服务器公钥钥放在authorized_keys，就是三台服务器上的authorized_keys都有三个公钥
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCySi6owY2PeMVrd6nysNmj4pLr5wZaQXKiQi+ISVvSXEXnNTlHwqf96VV2PdUPKp666IRi14+BeYX2SEzgPt1haFrLWzXqE+J9Cu+XXntY2u2ostzv4VKlqdl2qBbyvu/2qG2nIFIJC6MTd6m+lqCFp5ytZt4JOI6F/6vilQF0VnWDwF8U00yEob0qkCYm1g/YnDLBBflg7o3gGgdtHAPwa1Mi+LfRZdnM+21dqmQ+b5HopmUZKEeUVhpG7ybYPEcYgNxzXQh6cKwyrAD6b4oZgnbMrJxVF00gh23jRAdTr+0SHZmhmMq+nzmfhMhyryAKzxumB1g4gO28D1bnf/Gd root@redis-cache01
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDss+Xa1IuRgzBSAjwlITQZwp9ibDxSoCigYfTRMyU/sWcIjCm8ZOX26BqJR4ltNdXmMwbOgC1GT8P717Kd2AZ1pbxcCW+uxFisTvTqwqjdpfS6en3+eiXdklyHi3mrdCqvBMcN00mIk3UHEoGOAIzv0Ht6MgNFL2XWGl29uy+1bdskv9BGSLNvRvi5M4oEGV/DfKabZwkpIf8oFXXnZswmomjL2omyS52+W02G38Hn6BANFF7vDUtUU84WBsVC4uFvUHDdTsAmtecXBj0ppMFqPYnZQa+ILAFoZ7zxitHUYfGjPZPVh1Q6X1KmRm1AhBMWPeAAOiTXQUWRddVIPmbp root@redis-cache02
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYfnqP1c/a04VyQcGEovbtcKkJiotSqFxjKzG6WlxzUJfrHwDJFvkKL+QYn4sN74nzCrdBTE7nJJ/7rRdTyYK18LWDf370NEuy9MaZ/BqGsThqQoldXY2zp75trQqukpPav92kt8bGl1urpSPD13HHVozjzDbuESvPXp/J5iuBDRMmkC8H8nc6L+K7ATsldvghZsCcQo6RT3X1+9zgMwz6e2ZZGj9zJ3O+KyntRe4djkVHgwRfkleLo13nsOSg5lqghF5HRT0o5Q9DO/I1ZVe7YYlP1ETuAZTaBCoybJicHRUwXjHsYuWWy2g72NHQvPCSwdYxy4R/UsZhoeCmKJVF root@redis-cache03
下面配置redis-cache02上面的slave
修改6379.conf配置
slaveof redis-cache01服务器ip地址 6379
slave-read-only yes (强制只读)
因为我们master并没有配置认证密码，所有slave也不需要配置认证密码
这时候我们先启动主节点master redis-cache01
再启动从节点slave redis-cache02
启动成功没有报错的话
登录master redis-cli -h ipaddr
输入info replication 出现下图内容就是主从连接成功了
当然也可以登录slave节点
同样输入info replication 出现下图就是成功了
然后就可以试试在master节点上试试 set，然后在slave节点上get
压测及水平扩容支持更高QPS
你如果要对自己刚刚搭建好的redis做一个基准的压测，测一下你的redis的性能和QPS（query per second）
redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测
cd /usr/local/redis-3.2.8/src
./redis-benchmark -h redis-cache01ip地址
这是默认的
当然你也可以自己带上参数
-c <clients> Number of parallel connections (default 50)
-n <requests> Total number of requests (default 100000)
-d <size> Data size of SET/GET value in bytes (default 2)
根据你自己的高峰期的访问量，在高峰期，瞬时最大用户量会达到10万+，-c 100000，-n 10000000，-d 50
下面压测结果，可以自己看看
====== PING_INLINE ======
100000 requests completed in 1.28 seconds
50 parallel clients
3 bytes payload
keep alive: 1
99.78% <= 1 milliseconds
99.93% <= 2 milliseconds
99.97% <= 3 milliseconds
100.00% <= 3 milliseconds
78308.54 requests per second
====== PING_BULK ======
100000 requests completed in 1.30 seconds
50 parallel clients
3 bytes payload
keep alive: 1
99.87% <= 1 milliseconds
100.00% <= 1 milliseconds
76804.91 requests per second
====== SET ======
100000 requests completed in 2.50 seconds
50 parallel clients
3 bytes payload
keep alive: 1
5.95% <= 1 milliseconds
99.63% <= 2 milliseconds
99.93% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
40032.03 requests per second
====== GET ======
100000 requests completed in 1.30 seconds
50 parallel clients
3 bytes payload
keep alive: 1
99.73% <= 1 milliseconds
100.00% <= 2 milliseconds
100.00% <= 2 milliseconds
76628.35 requests per second
====== INCR ======
100000 requests completed in 1.90 seconds
50 parallel clients
3 bytes payload
keep alive: 1
80.92% <= 1 milliseconds
99.81% <= 2 milliseconds
99.95% <= 3 milliseconds
99.96% <= 4 milliseconds
99.97% <= 5 milliseconds
100.00% <= 6 milliseconds
52548.61 requests per second
上面讲了redis主从读写分离
那么redis下如何做到高可用
什么是99.99%高可用？
99.99%，公式，系统可用的时间 / 系统故障的时间，365天，在365天 * 99.99%的时间内，你的系统都是可以对外提供服务的，那就是高可用性
redis怎么才能做到高可用？
下面简单的讲下sentinel 中文名哨兵
1、哨兵是redis集群架构中非常重要的一个组件，主要功能如下
（1）集群监控，负责监控redis master和slave进程是否正常工作
（2）消息通知，如果某个redis实例有故障，那么哨兵负责发送消息作为报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上
（4）配置中心，如果故障转移发生了，通知client客户端新的master地址
哨兵本身也是分布式的，作为一个哨兵集群去运行，互相协同工作
（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（2）即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了
目前采用的是sentinal 2版本，sentinal 2相对于sentinal 1来说，重写了很多代码，主要是让故障转移的机制和算法变得更加健壮和简单
2、哨兵的核心知识
（1）哨兵至少需要3个实例，来保证自己的健壮性
（2）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
（3）对于哨兵 + redis主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练
3、为什么redis哨兵集群只有2个节点无法正常工作？如下图：
该图中详细的讲解了sentinel哨兵特点核心原理
下面我们就来配置sentinel
上面不是已经部署好了三台redis-cache吗，我们现在直接在这三台的基础上部署sentinel集群
redis-master地址也就是我们部署的主从redis-master服务器，也就是本篇文章中的redis-cache01
我们现在第一台机器上部署redis-cache01这台
新建目录
mkdir /etc/sentinel
mkdir -p /var/sentinel/5000
然后将redis目录下的sentinel配置文件拷贝到/etc/sentinel下
cp /usr/local/redis-3.2.8/sentinel.conf /etc/sentinel/5000.conf
然后修改配置文件内容
port 5000
bind 本机ip地址(不是127.0.0.1，192的)
dir /var/sentinal/5000
sentinel monitor mymaster redis-master地址 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
配置解释：
sentinel monitor master-group-name hostname port quorum
quorum：
（1）、至少多少个哨兵要一直同意，master进程挂掉了，或者slave进程挂掉了，或者要启动一个故障转移操作
（2）、quorum是来识别故障的，真正执行故障转移的时候还是要在哨兵集群中进行选举，选举出一个哨兵进程来执行故障转移操作
（3）、假设有5个哨兵，quorum设置了2，那么只要5个哨兵中有两个认为master进程挂掉了，两个哨兵中的一个就会做选举，选举出一个哨兵出来，执行故障转移；如果5个哨兵中有3个哨兵都是运行的，那么故障转移就会被允许执行
down-after-milliseconds：
（1）、超过多少毫秒跟一个redis实力断了连接，哨兵就可能认为这个redis实力挂了
parallel-syncs：
（1）、新的master切换之后，同时有多少个slave被切换到去连接新的master，重新做同步，数字越低，花费时间越多
（2）、假设你的redis是一个master，4个slave，然后master宕机了，4个slave中有一个切换成了master，剩下的slave就要挂到新到master上面去，这个时候如果parallel-syncs是1，那么3个slave，一个一个到挂到master上面去，1个挂完了，而且从新到master同步完数据，再接着挂下一个；如果parallel-syncs是3，那么一次性就会把所有到slave挂到新的master
failover-timeout：
（1）、执行故障转移的timeout超时时长
上面的redis-cache01已经部署完了
先不要启动sentinel，接下来我们接着部署redis-cache02、redis-cache03上面的sentienl
同样我们再redis-cache02上面新建目录
mkdir /etc/sentinel
mkdir -p /var/sentinel/5000
然后将redis目录下的sentinel配置文件拷贝到/etc/sentinel下
cp /usr/local/redis-3.2.8/sentinel.conf /etc/sentinel/5000.conf
修改配置文件5000.conf
port 5000
bind 本机ip地址(不是127.0.0.1，192的)
dir /var/sentinal/5000
sentinel monitor mymaster redis-master地址 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
然后是redis-cache03上面新建目录
mkdir /etc/sentinel
mkdir -p /var/sentinel/5000
然后将redis目录下的sentinel配置文件拷贝到/etc/sentinel下
cp /usr/local/redis-3.2.8/sentinel.conf /etc/sentinel/5000.conf
修改5000.conf配置文件
port 5000
bind 本机ip地址(不是127.0.0.1，192的)
dir /var/sentinal/5000
sentinel monitor mymaster redis-master地址 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
上面三台服务器已经部署好了，下面我们就来启动sentinel哨兵集群
依次启动redis-cache01、redis-cache02、redis-cache03上面的sentinel
redis-sentinel /etc/sentinel/5000.conf
接下来观察日志
首先我们看下redis-cache01上面的日志
30351:X 04 Sep 22:20:30.989 * Increased maximum number of open files to 10032 (it was originally set to 1024).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.2.8 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 5000
| `-._ `._ / _.-' | PID: 30351
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
30351:X 04 Sep 22:20:30.992 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
30351:X 04 Sep 22:20:30.992 # Sentinel ID is 59e8681da339dc4d907754d69acb7f763948f9ce
30351:X 04 Sep 22:20:30.992 # +monitor master mymaster 192.168.0.201 6379 quorum 2
上面是启动成功的日志
现在来测试下故障转移，主备切换
这时候我们尝试发生故障，就是停掉我们的master服务，kill
然后就会看到一些+sdown、-sdown的日志
30351:X 04 Sep 23:56:30.401 # +sdown master mymaster 192.168.0.201 6379
30351:X 04 Sep 23:56:30.510 # +new-epoch 3
30351:X 04 Sep 23:56:30.514 # +vote-for-leader 7b7d71b9ce097e8ed202d0e8db97b7412219bfc9 3
30351:X 04 Sep 23:56:31.524 # +odown master mymaster 192.168.0.201 6379 #quorum 3/2
30351:X 04 Sep 23:56:31.524 # Next failover delay: I will not start a failover before Thu Sep 5 00:02:30 2019
30351:X 04 Sep 23:56:31.768 # +config-update-from sentinel 7b7d71b9ce097e8ed202d0e8db97b7412219bfc9 192.168.0.202 5000 @ mymaster 192.168.0.201 6379
30351:X 04 Sep 23:56:31.768 # +switch-master mymaster 192.168.0.201 6379 192.168.0.202 6379
30351:X 04 Sep 23:56:31.769 * +slave slave 192.168.0.201:6379 192.168.0.201 6379 @ mymaster 192.168.0.202 6379
+sdown master mymaster 192.168.0.201 6379
这句就是监测到我们的redis master主观宕机了
+odown master mymaster 192.168.0.201 6379 #quorum 3/2
这句就是一共有多少个（quorum 3个哨兵）哨兵认为master宕机了，所以master主观宕机就会转换为odown客观宕机
然后会执行一系列选举算法
+switch-master mymaster 192.168.0.201 6379 192.168.0.202 6379
最终选举出最合适作为新的master机器也就是上面的192.168.0.202
其实就是redis-cache02这台服务
+slave slave 192.168.0.201:6379 192.168.0.201 6379 @ mymaster 192.168.0.202 6379
上面这句是当新的master选举出来之后，它会将其他的slave挂接的新的master上面去
这时候我们再将停掉的旧的master启动起来
/etc/init.d/redis_6379 start
然后再观察redis-cache01上面的sentinel日记，会看到下面
30351:X 05 Sep 00:07:10.208 # -sdown slave 192.168.0.201:6379 192.168.0.201 6379 @ mymaster 192.168.0.202 6379
30351:X 05 Sep 00:07:20.136 * +convert-to-slave slave 192.168.0.201:6379 192.168.0.201 6379 @ mymaster 192.168.0.202 6379
-sdown 就是相当于redis-cache01这台服务重新连接上了
+convert-to-slave 并且当作新的slave挂接到新到master服务上去
以上就是我们到sentinel故障转移
下面我们完善sentinel启动方式
修改每台服务器上的sentinel配置，5000.conf
新建目录
mkdir -p /var/log/sentinel/5000/
daemonize yes （设置后台启动）
logfile "/var/log/sentinel/5000/sentinel.log" （设置日志输出位置）
然后重新启动就完成了
redis-sentinel /etc/sentinel/5000.conf
所有到操作redis主从读写分离replication复制数据+sentienl哨兵集群主备切换基本上就已经完成了
733
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
