redis主从复制（读写分离）

1、主从复制服务器架构图

2、主从复制的作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
• 高可用基石：主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

3、主从复制同步流程

通常来讲，一次全量同步主服务器需要在磁盘上创建一个RDB文件，然后从服务器复制一份这个RDB文件到从服务器磁盘，复制完毕则读取RDB文件，将数据加载到内存。

如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。
使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。
无磁盘同步一般用于网络带宽较好而磁盘读取速度较差的情况下。

4、redis主从同步的实现

• 全量同步： master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件，与此同时，服务器会缓存生产rbd文件期间所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该rdb文件传递给slave服务器，而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后master服务器会将在此期间缓存的命令通过redis传输协议发送给slave服务器，然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。
• 部分同步： redis 2.8版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master服务器和slave服务器之间都是再次进行全量数据同步，但是从redis 2.8开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了一份同步日志和同步标识，每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave服务器隔断时间（默认1s）主动尝试和master服务器进行连接，如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中，那么就从slave发送的偏移量开始继续上次的同步操作，如果slave发送的偏移量已经不再master的同步备份日志中（可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作），则必须进行一次全量更新。在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

5、主从同步的特点

• 采取异步复制；
• 一个master可以含有多个slave；
• 每个slave可以接收来自其他slave服务器的连接（级联）；
• 主从复制对于主redis服务器来说是非阻塞的，这意味着当从服务器在进行主从复制同步过程中，主redis仍然可以处理外界的访问请求；
• 主从复制对于从redis服务器来说也是非阻塞的，这意味着，即使slave在进行主从复制过程中也可以接受外界的查询请求，只不过这时候slave返回的是老的数据，如果你不想这样，那么在启动redis时，可以在配置文件中进行设置，那么slave在复制同步过程中来自外界的查询请求都会返回错误给客户端；（虽然说主从复制过程中对于slave是非阻塞的，但是当slave从master同步过来最新的数据后还需要将新数据加载到内存中，在加载到内存的过程中是阻塞的，在这段时间内的请求将会被阻，如果对于大数据集，加载到内存的时间也是比较多的）；

6、主从复制相关配置（redis5.0.10）

################################# REPLICATION（主从复制） #################################
# 复制选项，slave复制对应的master。
# replicaof  

#如果master设置了requirepass，那么slave要连上master，需要有master的密码才行。masterauth就是用来
#配置master的密码，这样可以在连上master后进行认证。
# masterauth 

#当slave同master失去连接 或者 复制正在进行，slave有两种运行方式：
#1) 如果slave-serve-stale-data设置为yes(默认设置)，slave会继续响应客户端的请求。
#2) 如果slave-serve-stale-data设置为no，除INFO,replicaOF, AUTH, PING, SHUTDOWN, REPLCONF, ROLE, CONFIG,SUBSCRIBE, UNSUBSCRIBE,
#PSUBSCRIBE, PUNSUBSCRIBE, PUBLISH, PUBSUB,COMMAND, POST, HOST: and LATENCY命令之外的任何请求都会返回一个错误”SYNC with master in progress”。
replica-serve-stale-data yes

#作为从服务器，默认情况下是只读的（yes），可以修改成NO，用于写（不建议）
replica-read-only yes

# 是否使用无磁盘复制（即使用socket方式复制数据），默认是使用disk方式复制数据
repl-diskless-sync no

#diskless复制的延迟时间，防止设置为0。一旦复制开始，节点不会再接收新slave的复制请求直到下一个rdb传输。所以最好等待一段时间，等更多的slave连上来
repl-diskless-sync-delay 5

#slave根据指定的时间间隔向master发送ping请求。时间间隔可以通过 repl_ping_slave_period 来设置，默认10秒。
# repl-ping-replica-period 10

# 复制连接超时时间。master和slave都有超时时间的设置。master检测到slave上次发送的时间超过repl-timeout，即认为slave离线，清除该slave信息。
#slave检测到上次和master交互的时间超过repl-timeout，则认为master离线。需要注意的是repl-timeout需要设置一个比repl-ping-slave-period更大的值，不然会经常检测到超时
# repl-timeout 60

#是否禁止 主从复制tcp连接的 tcp nodelay参数（结尾有解释）。默认是no，即使用tcp nodelay。
#如果master设置了yes来禁止tcp nodelay设置，在把数据复制给slave的时候，会减少包的数量并且更小的网络带宽。
#但是这也可能带来数据的延迟。默认我们推荐更小的延迟，但是在数据量传输很大的场景下，建议选择yes
repl-disable-tcp-nodelay no

#复制缓冲区大小，这是一个环形复制缓冲区，用来保存最新写命令。这样在slave离线的时候，不需要完
#全复制master的数据，如果可以执行部分同步，只需要把缓冲区的部分数据复制给slave，就能恢复正常复制状
#态。缓冲区的大小越大，slave离线的时间可以更长，复制缓冲区只有在有slave连接的时候才分配内存。没有
#slave的一段时间，内存会被释放出来，默认1m
# repl-backlog-size 1mb

# master没有slave一段时间会释放复制缓冲区的内存，repl-backlog-ttl用来设置该时间长度。单位为秒。
# repl-backlog-ttl 3600

# 当master不可用，Sentinel会根据slave的优先级选举一个master。最低的优先级的slave，当选master。而配置成0，永远不会被选举
replica-priority 100

#redis提供了可以让master停止写入的方式，如果配置了min-replicas-to-write，健康的slave的个数小于N，
#mater就禁止写入。master最少得有多少个健康的slave存活才能执行写命令。这个配置虽然不能保证N个slave都一
#定能接收到master的写操作，但是能避免没有足够健康的slave的时候，master不能写入来避免数据丢失。设置为0是关闭该功能
# min-replicas-to-write 3
 
# 延迟小于min-replicas-max-lag秒的slave才认为是健康的slave
# min-replicas-max-lag 10

Nagle算法： TCP/IP协议中针对TCP默认开启了Nagle算法。Nagle算法通过减少需要传输的数据包，来优化网络。在内核实现中，数据包的发送和接受会先做缓存，分别对应于写缓存和读缓存。
启动TCP_NODELAY，就意味着禁用了Nagle算法，允许小包的发送。对于延时敏感型，同时数据传输量比较小的应用，开启TCP_NODELAY选项无疑是一个正确的选择。