分布式系统中的几种Redis部署方式
为了解决一个程序只部署在一个服务器上的单点问题：
可用性问题，如果这个机器挂了，就意味着服务就中断了
一个程序只部署在一台机器上，它的性能/支持的并发量也是有限的
所以，就引入了分布式系统。在分布式系统中，往往希望有多个服务器来部署Redis服务，从而构成一个Redis集群，这样就可以让这个集群给整个分布式系统中的其他服务，提供更稳定/更高效的数据存储功能。
主从模式
在一个集群中，有的是主节点，有的是从节点。从节点的数据要跟随主节点变化，从节点的数据要和主节点保持一致。
本来，在主节点上保存的所有数据，在引入从节点之后，就要把主节点上的数据复制出来，放在从节点中，后续，主节点对于数据有任何的修改，都会把这样的修改同步到从节点上。
从节点就是主节点的副本。
Redis主从模式中，从节点上的数据，不允许修改，只能读取！
对于客户端发来的读取数据的操作，可以在主从节点中的任意一个节点中获取数据；对于写操作，则需要从主节点操作，或者从节点告知主节点进行操作，这样也就提高了性能和并发量。
对于之前的单个Redis服务器节点，如果机器挂了，整个Redis就挂了。但现在可以有多个节点，也可以把这些节点放在不同的机房中，这样就不会出现所有节点同时挂掉的情况。如果挂掉的是某一个从节点，不影响读写操作，如果挂掉的是主节点，则只能进行读操作。一定程度上提高了可用性。
更准确的说，主从模式，主要是针对读操作进行并发量和可用性的提高；对于写操作，无论是可用性还是并发，都非常依赖主节点，而且主节点只能有一个。好在实际业务场景中，读操作往往比写操作更频繁。
主节点上会收到源源不断的修改数据的请求，从节点需要从主节点这里同步这些修改请求。但是，从节点和主节点之间的数据同步，不是瞬间完成的。
每一个从节点中都会有一个offset字段，用来记录同步数据的进度
主从复制中的拓扑结构（若干节点之间，按照什么样的方式进行组织连接）：
一主一从
一个主节点连接一个从节点，主节点和从节点都可以处理读数据请求，只有主节点可以处理写数据请求。
如果写数据请求太多，也会给主节点造成压力，这时可以关闭主节点的AOF，只在从节点上开启AOF，让主节点只操作内存中的数据，减少IO操作。
缺点在于，这种模式下，主节点一旦挂了，就不能让他自动重启，因为没有AOF文件，如果自动重启，就会丢失数据，进一步的主从同步，会把从节点的数据也删除掉。
改进办法：主节点挂了之后，让其从从节点获取到AOF文件，再启动。
一主多从
因为实际的开发中，读请求往往远远超过写请求，所以应该适量增加从节点的数量以提高效率
主节点上的数据发生改变，会把改变的数据同时同步给所有从节点。
但是，随着从节点的数量增多，主节点要同步一条数据就需要传输多次，所以往往需要增加主节点的网络带宽，增大了成本。
树形结构
这种结构，不要求主节点有太高的网络带宽，从节点也可以帮助数据同步，但是进行数据修改时，同步的延时更长了。
主从复制流程
数据同步的方法
Redis提供了psync命令，可以完成数据同步的过程。
这个命令不需要手动执行，Redis服务器会在建立好主从同步关系之后，自动执行psync（从节点执行psync，从节点从主节点拉取数据）。
进行数据复制，需要从节点在与主节点建立好复制关系之后，从主节点获取到replication id（复制ID）。这个ID是主节点启动时自动生成的，每个主节点每次重启得到的ID都是不同的。根据这个ID就可以知道当前从节点是从哪个主节点复制的数据（在集群中会有多个主节点）。
每一个节点中都还会有一个offset值，对于主节点，每次有新的修改数据的操作时，都会在这个值原来的基础上增加；对于从节点，每同步一部分主节点中的数据，这个值也会增加，当从节点中的offset值跟主节点中的offset值相等时，就证明数据同步完成。
replication id 和 offset 共同描述了一个“数据集合”
如果有两个机器，replication id 一样，offset 也一样，就可以认为这两个 redis 机器上存储的数据是完全一样的。
psync运行流程：
从节点发送 psync 命令给主节点，replid 和 offset 的默认值分别是？和-1.
主节点根据 psync 参数和自身数据情况决定响应结果：
如果回复 +FULLRESYNC replid offset，则从节点需要进行全量复制流程
如果回复 +CONTINUE，从节点进行部分复制流程
如果回复 -ERR，说明Redis主节点版本过低，不支持 psync 命令，从节点可以使用 sync 命令进行全量复制
psync 可以从主节点获取全量数据，也可以获取一部分数据，具体区别于 offset 的进度。
如果 offset 为-1，则获取全量数据；如果是具体的整数，则从当前偏移量位置进行获取部分数据。
复制全量数据会有比较大的消耗，所以一般还是部分数据复制更好，但是如果主节点本身并不适合部分复制，就会仍然给从节点进行全量复制。
较老的版本的Redis不支持psync，可以用sync代替，不过后者会阻塞其他操作，所以不建议使用。
一般什么时候会进行部分复制？
从节点之前已经从主节点上复制过数据了，但因为网络抖动导致从节点重启了，这时需要重新行主节点同步数据，在大部分数据已经同步的情况下，希望只同步一小部分未复制的数据。
全量复制流程
从节点发送 psync 命令给主节点进行数据同步，由于是第一次进行复制，从节点没有主节点的运行 ID 和复制偏移量，所以发送 psync ? -1。
主节点根据命令，解析出要进行全量复制，回复 +FULLRESYNC 响应。
从节点接收主节点的运行信息进行保存。
主节点执行 bgsave 进行 RDB 文件的持久化。
主节点发送 RDB 文件给从节点，从节点保存 RDB 数据到本地硬盘。
主节点将从生成 RDB 到接收完成期间执行的写命令，写入缓冲区中，等从节点保存完 RDB 文件后，主节点再将缓冲区内的数据补发给从节点，补发的数据仍然按照 RDB 的二进制格式追加写入到收到的 RDB 文件中，保持主从一致性。
从节点清空自身原有数据。
从节点加载 RDB 文件得到与主节点一致的数据。
如果从节点加载 RDB 完成之后，并且开启了 AOF 持久化功能，它会进行 bgrewrite 操作，得到最近的 AOF 文件。
第四步中，使用 RDB 是因为二进制节省空间，不能使用已有的 RDB 文件，而要重新生成，是因为已有的文件和当前的最新数据可能存在较大差异。
上述由主节点向从节点传送数据使用的是 RDB 文件，要写入文件就要有IO操作，效率就会降低。所以，为了保证效率，Redis 主节点进行全量复制的时候，也支持“无硬盘模式”（diskless），也就是主节点生成的 RDB 的二进制数据，不再直接保存到文件中，而是直接进行网络传输。同样的，从节点也不需要先把接收到的数据写入硬盘，然后再加载，而是直接把收到的数据写入内存。
但是，即使引入了无硬盘模式，整个操作仍然是比较重量级的，比较耗时的，网络传输是无法省去的，所以效率也并没有提升很多。
关于 replication id 和 runid
具有主从关系的节点之间的 replication id 是相同的，但是每个节点的 runid 都是不同的。
runid 主要用于支撑实现 Redis 哨兵的功能，和主从复制没什么关系。而 replication id 在上文中也表明，它主要是用于主从复制。
部分复制流程
当主从节点之间出现网络中断时，如果超过 repl-timeout 时间，主节点会认为从节点故障并中断复制连接。
主从连接中断期间主节点依然响应命令，但这些复制命令都因网络中断无法及时发送给从节点，所以暂时将这些命令滞留在复制积压缓冲区（一个基于数组实现的环形队列）中。
当主从节点网络恢复后，从节点再次连接上主节点。
从节点将之前保存的 replication 和 offset 作为 psync 的参数发送给主节点，请求进行部分复制。
主节点接到 psync 请求后，进行必要的验证，随后根据 offset 去复制积压缓冲区查找合适的数据，并响应 +CONTINUE 给从节点。
主节点将需要从节点同步的数据发送给从节点，最终完成一致性。
上文中提到的“主节点有时候会判定适不适合进行部分复制，不适合的话就进行全量复制”，其实指的是，从节点虽然之前进行过数据复制，但是后续需要复制的数据已经超出积压缓冲区中的数据了，这时只把积压缓冲区中的数据发送给从节点是不够的，所以只能进行全量复制。
实时复制
全量复制：从节点刚连上主节点之后，进行的数据初始化工作。
部分复制：全量复制的特殊情况，优化手段，目的和全量复制一样。
实时复制：从节点已经和主节点同步好了数据，但是之后主节点会源源不断地收到新的修改数据的请求，主节点上的数据就会随之改变，这些数据也同样需要同步给从节点。
实时复制需要主从节点之间建立 TCP 长连接，随后主节点把自己收到的修改数据的请求发送给从节点，从节点再根据这些修改请求修改内存中的数据。
在进行实时复制时，需要保证连接处于可用状态，所采用的是“心跳包”机制。
主节点：默认每隔10秒给从节点发送一个 ping 命令，从节点收到就返回 pong
从节点：默认每隔1秒给主节点发起一个特定的请求，上报当前从节点复制数据的进度（offset）
