前边的Redis持久化解决了，单机故障能够重启恢复备份数据的功能。而在分布式系统中，为了解决单点问题，达到高可用的目的，需要进行redis数据分布式，进行多台机器实时备份，从而满足更高效的故障恢复和负载均衡等需求。好，这篇我们来看一下Redis的复制功能。复制功能也是Redis哨兵模式，集群模式的基础。
参与复制的Redis节点分为主节点（master）和从节点（slave），默认情况下都为master，每个slave只能有一个master，而master可以同时有多个slave，复制的数据流是单向的，只能从master——>slave。
接下来我们从使用方式、支持的相关拓扑结构、相关原理、常见问题四个方面学习总结Redis的复制。
一，使用方式：
1，建立复制：a，通过在配置文件中加入：slaveof {masterHost} {masterPort}岁Redis启动生效；b，在redis-server启动命令后加入 --slaveof {masterHost} {masterPort}生效；c，直接使用命令：slaveof {masterHost} {masterPort}生效。通过使用info replication查看复制的相关状态。
2，断开复制：slaveof命令不但可以建立复制，还可以在从节点执行slaveof no one来断开与主节点的复制关系。其流程a，断开与主节点复制关系；b，从节点晋升为主节点。
3，安全性：对于数据比较重要的节点，主节点通过设置requirepass参数进行密码验证。client必须使用auth命令实行校验，从节点需要配置masterauth参数与主节点一致。
4，只读：默认情况下，从节点使用slave-read-only=yes配置为只读模式。修改只在主节点实现。
5，传输延迟：Redis提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY。默认关闭。当开启时，主节点会合并较小的TCP数据包，从而节省带宽。一般为发送间隔40毫秒。如果要求低延迟，例如读写分离等，就关闭此功能；如果考虑容灾性，做备份，建议打开。
二，拓扑结构：
| 拓扑结构 | 说明 |
|---|---|
| 1.一主一从 | 最简单的，master可以做业务操作，保持高性能，slave做备份，并开启AOF持久化，保持数据安全。 |
| 2.一主多从 | 对于读多写少的场景，可以进行读写分离，利用从节点分担主节点的压力。对于写并发量较高的场景，如果从节点过多，会加大网络带宽，同时加速主节点的负载。 |
| 3.树状主从结构 | 从节点不但复制主节点的数据，还充当其它从节点的主节点继续向下层复制。可以减小多个从节点给主节点带来过高负载，干扰主节点性能。
|
三，流程原理：
1，复制流程：
| 流程节点 | 说明 |
|---|---|
| 1.保存主节点信息 | 执行salveof命令后slave节点首选保存master的相关信息，方便后期通讯。 |
| 2.主从建立socket连接 | slave内部通过每秒运行的定时任务维护复制相关逻辑，发现新的主节点，会尝试与其建立网络连接。 |
| 3.发送ping命令 | 连接建立成功后，发送ping请求进行首次通讯，检测主从之间的网络套接字是否可用、检测主节点当前是否可接受处理命令。主节点会pong回复。 |
| 4.权限验证 | 如果master设置了requirepass参数，则进行密码验证。 |
| 5.同步数据集 | 首次建立复制的场景，master会把数据全量发送给slave。 |
| 6.命令持续复制 | 随着master的写入操作，master会持续把写命令发送给slave，保持数据一致性。 |
2，数据同步：
psync复制命令，需要主从节点各自复制偏移量、主节点复制积压缓冲区、主节点运行id支持完成。从节点可以使用此命令完成部分复制和全量复制功能，命令格式：psync{runId}{offset}。
| 1.复制偏移量offset | master会维护自己的偏移量，slave每秒上报自身复制偏移量，slave接受到主节点发送命令后，会累加自己的复制偏移量。这样通过复制偏移量就能很清楚知道两者数据的一致性了。 |
| 2.复制积压缓冲区 | master上一个固定长度的队列，默认大小1MB，当master有写命令时，不仅同步salve，还有写入一份缓冲区，用于各种异常的补救。 |
| 3.主节点运行id | 每个redis启动后都会分配一个40位的十六进制字符串为运行id，为其唯一标示。 |
看下示意图：
3，全量复制流程：
说明：第6步，由于在传输RDB以及加载的时候，master任然有写操作，这是就放到前边说到的复制缓冲区中，等加载完RDB后，主节点将缓冲区的数据发送给从节点从而保持数据一致。
其中时间开销主要出现在：1，master的bgsave操作；2，RDB文件的网络传输；3，slave清空旧数据；4slave加载RDB文件；5，如果开启AOF，AOF的重写时间。这些需要我们多考虑的。
4，部分复制流程：
当slave和master短时间断开后，重新连接后，master会将复制缓冲区中的数据，增量发送给slave。避免全量同步的巨大开销。
5，心跳：主从节点彼此都有心跳检测机制：master默认10秒发送ping命令，判断从节点的存活性和连接状态；slave每个1秒发送replconf ack {offset}，上报自己的复制偏移量。从而达到彼此的及时了解。
6，异步复制：master节点不仅负责数据读写，还负责把写命令同步给slave，写命令的发送过程是异步完成，在处理完业务直接返回client，不等待从节点的复制完成。从而达到主从复制基本上不影响master处理正常业务逻辑的性能。
四，常见问题：
| 1-读写分离 | a，复制数据延迟：业务能否容忍；通过偏移量进行监控 b，读到过期数据：惰性删除、定时删除。3.2版本后解决此问题。 c，从节点故障问题：考虑Redis Cluster集群方案 |
| 2-主从配置不一致 | 对于内存等，主从机器的配置，Redis参数配置最好一样，防止出现一个能用，另一个down掉的情况。 |
| 3-规避全量复制 | a，第一次建立复制，无法避免，低峰操作，考虑影响； b，节点运行ID不匹配，利用后边的哨兵模式、集群模式进行解决； c，复制积压缓冲区不足，分析合理的缓冲区大小。 |
| 4-规避复制风暴 | 从节点不要太多，必要可以使用树状拓扑结构，来保护主节点。 |
好，这篇小结了一下Redis的复制功能，这也是Redis后边哨兵模式和集群模式的基础。学习设计思想。加油。
