Redis主从复制
2018-03-15 13:44
218 查看
概述
一般来说,要将Redis运用于工程项目中,只使用一台Redis是万万不能的,原因如下:从结构上,单个Redis服务器会发生单点故障,并且一台服务器需要处理所有的请求负载,压力较大;从容量上,单个Redis服务器内存容量有限,就算一台Redis服务器内容容量为256G,也不能将所有内容用作Redis存储内存,一般来说,单台Redis最大使用内存不应该超过20G。
本文先讨论第一点的解决方案:Redis主从复制,第二点可以使用Redis集群解决,下一篇文章将介绍Redis集群。
主从复制
考虑如下一种场景:电子商务网站上的商品,一般都是一次上传,无数次浏览的,说专业点也就是”多读少写”。对于这种场景,我们可以使如下这种架构:如图中所示,我们将一台Redis服务器作主库(Matser),其他三台作为从库(Slave),主库只负责写数据,每次有数据更新都将更新的数据同步到它所有的从库,而从库只负责读数据。这样一来,就有了两个好处:读写分离,不仅可以提高服务器的负载能力,并且可以根据读请求的规模自由增加或者减少从库的数量,棒极了;
数据被复制成了了好几份,就算有一台机器出现故障,也可以使用其他机器的数据快速恢复。
需要注意的是:在Redis主从模式中,一台主库可以拥有多个从库,但是一个从库只能隶属于一个主库。
配置
在Redis中,要实现主从复制架构非常简单,只需要在从数据库的配置文件中加上如下命令即可:1 | slaveof 主数据库地址 主数据库端口 |
示例
下面将演示怎么实现一个简单的复制系统。我们在一台机器上起两个Redis实例,监听不同的端口,其中一个作为主库,另外一个作为从库。首先不加任何参数来启动一个Redis实例作为主数据库:可以看到,主库监听的是6379端口。然后加上slaveof参数启动另一个Redis实例作为从库,并且监听6380端口:
从控制台输出中可以看到,从库已经连接到主库:126.0.0.1:6379了,看样子主从复制系统配置成功。我们可以分别在主库和从库中使用如下命令看一看当前实例在复制系统中的相关信息:
接下来验证一把。首先在主库中设置一个键值:
12 | [qifuguang@Mac~]$ /opt/soft/redis-3.0.4/src/redis-cli -p 6379 127.0.0.1:6379> set test-sync winwill2012 OK 127.0.0.1:6379> |
12 | [qifuguang@Mac~]$ /opt/soft/redis-3.0.4/src/redis-cli -p 6380 127.0.0.1:6380> get test-sync "winwill2012" 127.0.0.1:6380> |
12 | [qifuguang@Mac~]$ /opt/soft/redis-3.0.4/src/redis-cli -p 6380 127.0.0.1:6380> set x y (error) READONLY You can't write against a read only slave. 127.0.0.1:6380> |
1 | slave-read-only no |
1 | SLAVEOF 新主库地址 新主库端口 |
1 | SLAVEOF NO ONE |
原理
上面说了配置主从复制系统的方法,并且举例例子详细说明,本节将介绍Redis主从复制的实现原理。当一个从数据库启动时,会向主数据库发送SYNC命令,主数据库收到命令后会开始在后台保存快照(即RDB持久化过程),并将保存快照期间接收到的命令缓存起来。当快照完成后,Redis会将快照文件和缓存的命令发给从数据库,从数据库收到数据后,会载入快照文件并执行缓存的命令。以上过程称为复制初始化。复制初始化之结束后,主数据库每收到写命令时就会将命令同步给从数据库,从而保证主从数据库数据一致,这一过程称为复制同步阶段。有两点需要注意:当主从数据库之间的连接断开后,Redis2.8之前的版本会重新进行复制初始化过程,这样就使得主从数据库断开连接后数据恢复的过程的效率很低下。Redis2.8版本的一个重要改进就是断线支持有条件的增量数据传输,当从数据库再次连接到主数据库时,主数据库只需要将断线期间执行的命令发给从数据库即可,大大提高了Redis主从复制的实用性。复制同步阶段贯穿整个主从同步过程的始终,直到主从关系终止为止。在复制过程中,即使关闭了RDB方式的持久化(删除所有save参数),依旧会执行快照操作。
乐观复制
Redis采用了复制的策略。容忍在一定时间内主从数据库的内容是不同的,但是两者的数据最终会保持一致。具体来说,Redis主从数据库之间的复制数据的过程本身是异步的,这意味着,主数据库执行完客户端的写请求后会立即将命令在主数据库的执行结果返回给客户端,而不会等待从数据库收到该命令后再返回给客户端。这一特性保证了复制后主从数据库的性能不会受到影响,但另一方面也会产生一个主从数据库数据不一致的时间窗口,当主数据库执行一条写命令之后,主数据库的数据已经发生变动,然而在主数据库将该命令传送给从数据库之前,如果两个数据库之间的连接断开了,此时二者间的数据就不一致了。从这个角度看,主数据库无法得知命令最终同步给了几个从数据库,不过Redis提供了两个配置选项来限制只有至少同步给指定数量的数据库时,主数据库才是可写的:12 | min-slaves-to-write 3 min-slave2-max-lag 10 |
第二个参数表示允许从数据库失去连接的最长时间,该选项默认是关闭的,在分布式系统中,打开并合理配置该选项可以降低主从架构因为网络分区导致的数据不一致问题。
图结构
从数据库不仅可以接收主数据库的数据,同时也可以作为主数据库存在,形成类似图的结构,如下图:A中的数据会同步到B,C中,C中的数据会同步到D,E中。
相关文章推荐
- redis 主从复制,读写分离
- Redis探索之旅(12)- Redis主从架构复制原理
- Redis主从复制和集群配置
- Redis的主从复制
- redis主从复制
- Ubuntu 12.10下Redis主从复制配置
- redis之主从复制
- Linux下Redis主从复制的配置方法(测试方法)
- Redis高级实用特性(安全性、主从复制、事务处理)
- redis的主从复制配置
- ASP Redis主从复制配置,数据快照、AOF配置
- Redis学习手册(主从复制)
- NoSQL初探之人人都爱Redis:(4)Redis主从复制架构初步探索
- redis主从复制
- Redis实现主从复制(master-slave)
- Linux+Windows环境下Redis安装详细教程(主从复制+哨兵机制配置)
- Redis 主从复制
- redis 实现主从复制
- Linux环境搭建nginx+2个tomcat+2个redis(主从复制)
- Redis主从复制和集群配置