redis搭建主从复制读写分离

准备

关闭RDB持久化修改持久化文件的保存位置

启动Redis

redis-server /etc/redis.conf  

使用客户端连接Redis

redis-cli  

连接成功,接下来就可以愉快的玩耍啦~~~

主从复制(读写分离)

Redis的主从复制功能非常强大，一个master可以拥有多个slave,而一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构. 可以避免Redis单点故障,构建读写分离架构,满足读多写少的应用场景.

Redis复制功能的几个重要方面

1. 一个Master可以有多个Slave；

2. Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度；

3. 不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构；

4. 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务；

5. 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示；

6. 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）；

7. 复制功能可以单纯地用于数据冗余（dataredundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）：比如说，繁重的 SORT 命令可以交给附属节点去运行。

8. 可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。

主从架构

准备3个配置文件端口分别为

6379 (Master)

6380 (Slave)

6381 (Slave)

  

修改原来的redis.conf文件 ,拷贝出2个redis.conf文件

1. mv /etc/redis.conf /etc/redis.6379.conf  
2. cp /etc/redis.6379.conf /etc/redis.6380.conf  
3. cp /etc/redis.6379.conf /etc/redis.6381.conf  

通过vi修改6380 和 6381 配置文件

1. vi /etc/redis.6380.conf  

通过命令替换 6379 为 6380

:%s/6379/6380/g  

最底下出现

 表示修改成功, wq退出并保存

 

用一样的方式修改6381 的配置文件

 

注意: 配置文件在前面已经修改pidfile 参数,如果没有修改一定要修改该参数为不同的值

 

通过配置文件启动3个Redis实例

如果看不到，就去看redis.log错误文件

通过ps 命令查看Redis进程

主从的配置有2种方法:

第一种：在redis.conf中设置 slaveof

第二种：使用redis-cli客户端连接到Redis服务中,执行slaveof命令

这种方式在重启之后就会失去主从复制关系

修改6381的配置文件 ,然后重启6381 .

通过redis-cli进入6379这个服务

 

查看主从信息：INFO replication

从库显示的信息

测试主从关系

在主库写入数据 ,然后在从库读取数据

主从从结构

主从从架构就是

Master下面有个 Slave , 而Slave下面还有一个Slave

我们吧 6381 重启一下

此时的主从信息

只剩下一主一从了

 

然后使用redis-cli客户端连接到Redis服务,执行slaveof命令

查看此时的主从信息

 

6379:

6379只有一个从库 6380

6380:

6380有一个主库 6379 还有一个从库 6381

6381:

6381只有一个主库 6380

 

这样主从从架构就搭建好了

 

测试 , 先清空key

在主库中设置数据

在从库中获取数据

6380 和 6381都已经获取到数据了

 

好了,主从从架构搭建完成!

从库只读

默认情况下redis数据库充当slave角色时是只读的不能进行写操作。

如果进行写操作就会报错

我们可以修改Redis的配置文件的配置参数slave-read-only, 修改为no

数据同步的过程

①  当从库和主库建立MS关系后，会向主数据库发送SYNC命令(同步命令);

 

②  主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来;所以就算关掉了RDB持久化方式,在他们同步的时候也会产生RDB文件

以上主库只做了2件事情

           将接收的命令进行RDB持久化

           在RDB持久化中,将接收的命令缓存起来

①  当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis;

 

②  从Redis接收到后，会载入快照文件并且执行收到的缓存的命令;

 

③  之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致;

 

在这个过程中主从同步是通过RDB来同步数据, 即使禁用了RDB也没有用,那么就会产生IO问题,在这个复制过程可能就会出现瓶颈. Redis在2.8.18版本开始实现了无磁盘复制功能

 

Redis在与从库进行复制初始化时将不会吧快照储存到磁盘,而是直接通过网络发送给从库,避免了IO性能问题.

 

修改repl-diskless-sync 为 yes

宕机处理

在主从架构中出现了宕机的情况

 

①  Slave 宕机

在Redis中,从库重新启动会自动加入到主从架构中,自动完成同步数据

Redis 2.8之后,在从库有做持久化的前提下,如果从库在断开的期间,主库的变化不大,从库再次启动后,主库不会将或有的数据进行RDB操作,而是进行增量复制

②  Master 宕机

一 : 在Slave中执行SLAVEOF NO ONE 命令,断开主从关系并且提升为主库继续服务;

二 : 将主库重新启动后,执行 SLAVEOF命令,将其设置为其他Redis的从库,这个时候数据就同步回来了;

 

 

这样通过人工的方式来处理Redis的宕机情况步骤虽然少,但是还是容易出现异常的,下面我们通过Redis的哨兵(sentinel)功能来实现高可用的架构

详解看笔记http://note.youdao.com/noteshare?id=e7a7fb3506012f331c0c0aaa6ddee99c&sub=6DD42153CA0E407CBD51ABFC32B77769