redis点滴（六）redis主从复制

一般来说，要将redis应用于一台服务器是万万不能的，原因如下：

1.从结构上，单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大

2.从容量上看，单个redis服务器内存容量有限，就算一台redis服务器内容容量为256G，也不能所有内容用作redis存储内存，一般来说，单台redis最大使用内存不应该超过20G

主从复制

考虑如下一种场景：

电子商务网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是”多读少写”。

对于这种场景，我们可以使如下这种架构：

如图中所示，我们将一台Redis服务器作主库，其他三台作为从库，主库只负责写数据，每次有数据更新都会将更新的数据同步到它所有的从库，而从库只负责读数据，这样一来，就有了2个好处：

1.读写分离，不仅可以提高服务器的负载能力，并且可以根据读请求的规模自由增加或减少从库的数量；

2.数据被赋值了好几份，就算有一台机器出现故障，也可以使用其他的机器的数据快速恢复

需要注意的是：在Redis主从模式中，一台主库可以拥有多台从服务器，而从从服务器只能属于一台主服务器

配置：

在redis中，要实现主从配置非常简单，只需要在从服务器配置中把salveof 主库地址 主库端口  就行，主服务器不需要修改。

例：

下面将演示怎么实现一个简单的复制系统。我们在一台机器上起两个Redis实例，监听不同的端口，其中一个作为主库，另外一个作为从库。首先不加任何参数来启动一个Redis实例作为主数据库：

可以看到，主库监听的是6379端口。

然后加上slaveof参数启动另一个Redis实例作为从库，并且监听6380端口：

接下里验证一把

首先在主服务器上设置一个键值

set a 1;

现在到从服务器检查该值是否同步到了了从库：

get a;

可以看到主库同步到了从库。

原理：

上面说了配置主从复制系统的方法，并且举例详细说明，本节将介绍redi主从复制的原理：

当一个从数据库启动时，会向主服务器发送sync命令，主数据收到命令之后会开始在后台保存快照（即RDB持久化过程）。并将保存快照期间接受到的命令缓存起来，当快照完成后，redis会将快照文件和缓存命令发给从服务器，从服务器接收到数据后，会载入快照文件并执行缓存命令，以上过程称为复制初始化，复制初始化之结束后，主数据库每收到写命令时就会将命令同步到从服务器，从服务器保证主从数据一致，这一过程称为复制同步过程。

有2点需要注意：

1.当主从服务器之间的连接断开后，redis2.8之前的版本会重新进行复制初始化过程，这样就使主从服务器断开连接之后数据恢复过程很低，redis2.8后，当从服务器再次连接主服务器的时候，主服务器只需要将断线期间执行的命令发给从服务器即可，大大提高了redis主从复制的实用性;

2.复制同步阶段贯穿了整个主从复制过程，直到主从关系终止。在复制过程中，即时把rdb持久化关闭，依旧会执行快照操作。

乐观复制：

Redis采用了复制的策略，容忍一段时间内主从数据库的内容是不同的，但是2个数据最终还是保持一致的，具体来说，redis主从复制之间的复制数据的过程本身就是异步的，这意味着，主数据库执行完客户端写请求之后立即会把执行的结果告诉给客户端，而不会等到从服务器收到该命令后再返回给客户端，这一特性保证了复制后主从服务器性能不能受影响的。但另一方面也会产生主从数据不一样的情况，当主服务器执行一条命令之后，主服务器的数据已经发生了变化，然而在主服务器将该命令传送给从服务器的之前，如果2个服务器之间连接断开了，此时二者间的数据不一致的。从这个角度看，从这个角度看，主服务器无法得知最终同步了几个从服务器，不过redis提供了2个配置选项来限定只有至少同步到了指定数量的从服务器，主服务器才会操作

min-salve-to-write 3

min-salve2-max-lag 10

第一个参数表示，至少只有3个或者3个以上的从服务器连接到了主服务器，主服务器才会写操作，否则返回出错

第二个参数表示允许从服务器失去连接的最长时间，该选项默认是关闭的，在分布式中，打开并合理的配置该选项可以降低主从架构因为网络分区导致数据不一致问题。

图结构

从数据库不仅可以接收主数据库的数据，同时也可以作为主数据库存在，形成类似图的结构，如下图：

A中的数据会同步到B,C中，C中的数据会同步到D,E中。