redis安装教程和redis集群搭建--主从复制（读写分离）、中间人模式（主仆兼具、去中心化）、反客为主、哨兵模式，从实战出发的保姆级别教程

1、redis安装

1.1、下载reids.tar.gz

下载地址：http://download.redis.io/releases/，可以在这里下载你所需要的linux系统下的redis版本，本次教程使用的是redis-5.0.0

1.2、上传redis到linux服务器的/opt目录下，并赋予相应权限并解压。

文件授权命令：chmod 755 redis-5.0.0.tar.gz
授权是为了可以让文件解压。
解压命令：tar -zvxf redis-5.0.0.tar.gz
解压之后可见文件 redis-5.0.0

1.3、安装redis

进入解压出来的redis文件夹
命令： cd /opt/redis-5.0.0
使用redis安装命令
命令：make
make命令执行完，再执行一条安装命令。
命令：make install
出现一推install，说明安装成功。

1.4、在根目录下创建文件夹myredis

此文件创建在哪都行，为了方便就直接创建在根目录下
命令：mkdir myredis
将reids-5.0.0下的redis.conf复制一份到myredis
命令：cp /opt/redis-5.0.0/redis.conf /myredis

1.5、修改myredis中的redis.conf配置文件

在myredis目录下编辑reids.conf
命令： vi redis.conf
需将darmonize 的 no 改为 yes

1.6、进入/usr/local/bin目录下运行redis

进入/usr/local/bin可以看到许多redis安装过的组件
命令：cd /usr/local/bin
利用自己的配置文件进行redis的启动
执行启动命令：redis-server /myredis/redis.conf
reids启动后会占据本次linux连接使用，从新开启一个linux连接，可看到启动后默认端口为6379，可以记作（63=7*9）。
这里主要是给大家看一下redis安装之后会将自己的各个启动组件都放在/usr/local/bin目录下，在linux中该目录下的程序是可以在任意目录下使用的。

1.7、redis客户端连接测试

先看服务器是否已启动redis
命令：ps -ef|grep redis
在/usr/local/bin下使用客户端连接命令
命令：redis-cli -h 127.0.0.1 -p 6379
连接成功，提示会变为127.0.0.1:6379>
这时向redis发送 ping 就会得到 pong 回应
设值test
命令：set k1 xxx
获值test
命令: get k1

完成以上步骤说明redis已经在你的服务器上跑起来了，下面就开冲。

2、模拟三台redis服务器

2.1、在myredis文件夹下复制三个redis.conf

命令：
cp redis.conf redis6379.conf
cp redis.conf redis6380.conf
cp redis.conf redis6381.conf

2.2、修改三个复制出来的reids配置文件(以redis6379.conf为例)

2.2.1、daemonize修改

daemonize no -> daemonize yes

2.2.2、pid文件修改

pidfile /var/run/redis.pid -> pidfile /var/run/redis6379.pid

2.2.3、指定端口

port xxxx -> port 6379

2.2.4、log文件名字

logfile “” -> logfile “6379.log”

2.2.5、dump.rdb名字

dbfilename dump.rdb -> dbfilename dump6379.rdb

以上对配置的修改以redis6379.conf为例，其中redis6380.conf、redis6381.conf的修改依照reids6379.conf的修改，只需将 “6379”->“6380"或"6381”。

2.3、启动三台reids服务器

本次是一台服务器模仿的三台服务器，所以实质上是三个redis进程在一台linux上运行。
先查看后台是否有关于redis的服务进程。
命令：ps -ef|grep redis
若是有关于reids的进程，先将其关闭
命令：kill 9 进程号（本次实验中为9763，所以使用 kill 9 9763 可以杀死该reids进程）

依次启动三个redis服务器(任意目录下输入下面命令，即可启动)
命令：
redis-server /myredis/redis6379.conf
redis-server /myredis/redis6380.conf
redis-server /myredis/redis6381.conf
启动后查看redis进程，可以看到后台有三个redis进程。

3、主从复制

3.1、什么是主从复制？

主从复制是Redis是redis自带的功能特性，这个特性在其他数据库也有，比如关系型数据库mysql，主机是master，从机是slave，若是两台主机形成主从关系，则主机负责对客户端请求写操作，从机一直在监听着主机的变化，将主机的数据同步到自己的数据库上，若是客户端请求读，可以请求从机，不用去主机读。

3.2、有什么用？

实现主从的读写分离，提高了系统的并发性能。
提高容灾性。

3.3、 怎么实现主从复制呢？

总的来说可以有三种一主二仆、中间人模式、反客为主

3.3.1、 一主二仆

3.3.1.1、首先启动三台linux服务器客户端，目的是启动三台redis客户端。

依次在三个redis客户端打命令：
redis-cli -p 6379
redis-cli -p 6380
reids-cli -p 6381

3.3.1.2、建立连接后查看各自的身份

依次打命令：info replication
可以看到三台redis都是独立的，自己的身份都是master，连接master的slave都是 0

3.3.1.3、使其中两台reids服务器作为一台的从服务器

这里我们选用6379端口作为主服务，6380、6381端口作为从服务器。
在6380、6381连接客户端输入连接reids-master命令：slaveof ip port
命令：slaveof 127.0.0.1 6379
这里我使用ip地址为回环地址127.0.0.1，是因为是一个linux服务器三个redis进程模拟三台redis服务器。

之后再次查看三台redis服务器的地址
可见6379端口号的redis服务器身份仍然为master，但此时连接的slave为2
6380、6381端口号的redis服务器身份为slave，且连接master的套接字为127.0.0.1:6379

3.3.1.4、读写分离与同步test

小结论：master可读可写，slave只能读不能写。
刚开始主从无值，master开始写，slave机在默默的同步
之后slave尝试写，但失败。

3.3.2、中间人模式

为了防止master的资源被过多占用,中间人模式出现了，将革命的精神薪火相传，也就说，其中一台slave直接同步别的slave的数据，不再同步master了。

3.3.2.1、设置中间人

这里我们选择6380端口号的slave作为中间人，使6381端口号的slave直接同步6380端口的slave。
在6381端口号的reids客户端输入命令：slave 127.0.0.1 6380

身份分析：
之后再查看各个redis服务器的身份状态。
可见6379身份仍然为master，6380、6381身份仍然为slave。
6379只剩下6380一个slave。
6380虽然为slave，但是也有一个slave连接了它，而且就是6381。
6381连接的master是6380

3.3.2.1、中间人模式test

从测试结果来看，中间人模式中也是只有master才能写，slave只能读；而且充当中间人的slave也不能写，它会将自己同步到master的数据同步到连接到它的slave。

3.3.3、反客为主

有这一个机制是为防止master宕机，redis集群处于不可使用状态–只能读旧值，不能写入新值。
这样就需要从新独立出一个master。
（以下实验前，将redis的集群，配置成主从复制最初模式）

3.3.3.1、模拟master宕机了

在6379端口redis连接客户端中使用 shutdown ，关闭当前redis服务端。
此次实验中用6379端口是master，此时相当与redis的主从关系中，已经没有master了。
这时，从机slave不做任何操作，我们将6379的master重新启动会怎么样呢？
没错（？？？ 怎么就没错了，你啥也没说啊）！！！ 这时我们在对master写入，可以看到，slave仍然能同步master的最新信息。这也说明， 是slave在监视master，而不是master进行推送。

3.3.3.2、模拟slave宕机了

slave宕机之后，再令其重启，再查看它的身份已经是master了，而且改重启的reids服务器，不会再将它之前在master上同步得到的数据再次放回内存。
而且这时对6379这台master进行设值，可以看到重启的6380端口的redis是不会同步6379端口的redis的数据更新的。
小结论：slave重启之后，默认变回master，自己玩去了，不在之前的圈子混了。
若想解决slave重启仍然在redis分布系统里面，可以将配置写在redis.conf里面。

3.3.3.2、slave如何上位？

说到 slave上位，也就是一个命令。
在一个slave客户端输入命令：slaveof no one
当前环境为一主二仆，master为6379，slave为6380和6381。

6380的slave使用命令：slaveof no one
最后再看大家的身份变化，可见6380成为一个独立的中心点了，也就是相当于它宕机后再回来了。

3.3.4、哨兵模式

是不是很多小伙伴直接跳到这里，但还是要看下一主二仆配置，master为6379，slave为6380、6381的结构。

3.3.4.1、新建哨兵配置文件

• 在/myredis文件夹下，直接命令: vi sentinel.conf
• 进入编辑页面，填入这一段文本：sentinel monitor master6379 127.0.0.1 6379 1
• 保存并退出。

3.3.4.2、启动哨兵

任意目录下使用命令：redis-sentinel /myredis/sentinel.conf
这时哨兵已经在监控着6379这台master和其所在的主从系统。

3.3.4.3、查看现在redis的主从系统。

3.3.4.4、模拟6379master宕机

• 在6379的客户端使用 shutdown ，表示当前6379这台master宕机了。
• 等一小会之后，在此查看主从系统中各个redis服务器的状态，可见此时6381这台slave变成了master；6380仍然是slave，但是它的master变成了6381。
• 在6381这台master赋值，再查看系统的所存值，可知，系统之前的值保留，新加的值同步了。
  
  

3.3.4.4、模拟之前6379master宕机之后重启

总结一句：老领导过气了。
重启6379这台redis服务器之后，查看其状态，可以看到，它自动成了salve，而且它的master就是哨兵系统选出来的6381master。

3.3.4.4、哨兵模式总结

让系统有了自动化，提高了系统的可用性和可靠性。

4、总结

• redis安装很简单，使用也很简单，但是实质的系统不会是单机的redis，肯定是集群发布的，所以我们需掌握其集群搭建。
• 主从复制的读写分离中，对于数据的同步：slave连接master时，第一次是全量复制master
  数据，往后就是增量复制master数据。
• 现在一般使用的技术就是哨兵模式。
• 若是跟着本文一步步走不能复现操作，欢迎大家一起交流解决问题哦！！！