Redis应用学习（六）——主从复制

1. 认识主从复制

    1. 单机部署Redis的问题：首先是若是机器故障（忽然断电或者机器宕机），那么数据就会大量丢失；其次就是单机Redis的容量会有瓶颈，受限于机器的内存空间；每秒的请求处理数也会受到单机Redis的限制，尽管Redis每秒的请求处理数能够很高，但在大型应用中仍然是远远不够的。为了解决这些问题，实现高可用，Redis提供了一个主从复制的功能，来实现集群式部署Redis

    2. 简单了解主从复制的模型：主从复制，会有一个主节点和多个从节点，每个节点都是一个Redis，并且每个Redis节点都能给客户端提供Redis的服务，主从复制就是从主Redis节点中复制数据到从Redis节点，若是主节点进行一个数据更新操做，那么从节点也会进行一个相同的操做。主从复制经过RDB文件来实现。

    3. 主从复制的做用：

• 数据副本：避免单机部署中机器故障形成的数据丢失，并且若是主节点宕机，从节点就会提供支援代替主节点向客户端提供服务。
• 扩展性能：读写操做分离，大量的对主节点进行读写操做会形成很大的性能负担，能够将读操做分流到多个从节点中，这样就能够极大的提高读操做的性能。

    4. 主从复制的特色：

• 只能一个主节点对于多个从节点，一对多的关系
• 数据只能从主节点复制到从节点，数据流是单向的

2. 主从复制的实现配置

    1. 有两种实现方式：分别是经过运行命令来实现，另外一种是经过redis的启动配置文件来实现

• slaveof命令：
  • 变为从节点：使用形式为slaveof  masterip masterport，须要指定当前从节点Redis的主节点Redis的ip地址masterip和端口号masterport，执行该命令后，就会经过网络链接到指定的主节点，并经过网络传输进行数据复制，数据复制是异步操做；另外，若是从节点中以前存储有数据，那么在变成从节点以后就会清空以前保存的数据
  • 变为主节点：使用形式为slaveof  no one，会取消本身与主节点的主从关系，但不会删除以前复制的数据
• 经过从节点Redis的启动配置文件修改配置参数：
  • slaveof  masterip masterport：须要指定主节点Redis所在机器的IP地址masterip 和运行时占用的端口号masterport
  • slave-read-only yes：该配置参数表示当前从节点是否只容许进行读操做，默认yes表示只能进行读操做（不建议修改），该配置参数保证了当前Redis节点被配置为从节点以后，不会执行写操做，防止主从节点之间的数据不一样步

3. 主从复制的实现方式——全量复制功能

    1. run_id：Redis每次启动时，都会生成一个不一样的id来标示当前运行的Redis。从节点中会保存主节点的run_id标示，若是主节点的Redis发生了重启，那么从节点依据ip和端口号链接到主节点时，就会发现主节点的run_id标示的改变（这种改变意味着主节点中的数据可能发生的大量的改动），因此此时就会引发全量复制，也就是将主节点中的全部数据所有复制过来。

    2. 偏移量：每当主节点增删改一个数据时，主节点中就会有一个数值来记录这种变化，偏移量就是记录Redis中数据改变的一个标示，当主节点更改一个数据时，偏移量也会发生对应的改变，并且主节点在将数据更改命令同步给从节点时，也会将该偏移量发送给从节点，这样就能够对比主从节点的偏移量，来观察是否出现主从不一致的问题。下图中master_repl_offset就表示主节点的偏移量，高亮处就表示从节点中的偏移量，使用 ./redis-cli -p 6379 info replication 该命令便可在主节点中查看主从节点的偏移量

    3. 全量复制：全量复制指的是不只仅复制主节点发送过来的RDB文件中的数据，还要将主节点在生成RDB文件期间主节点后续执行的数据更改命令所更改的数据一并复制过来，在这期间，主节点执行的数据更改命令会被记录在一个缓冲区repl_back_buffer中，当从节点RDB加载完毕后，就会将这一部分被更改的数据同步到从节点中，具体过程以下

• 当从节点执行slaveof命令时，就会自动向主节点发送一条命令(psync ? -1)，第一个参数表示主节点的run_id，第二个参数表示当前从节点的偏移量为-1，而后从节点就会接收到主节点返回的主节点的run_id和偏移量等信息并保存
• 主节点自动执行bgsave命令生成RDB文件，在此期间会记录后续执行的数据更改命令所更改的数据，直到主节点将生成的RDB文件传输到从节点为止
• 主节点发送RDB文件，从节点接收完毕后，主节点会将缓冲区中记录的新更改的数据发送给从节点，从节点再接收
• 从节点清空此前的全部数据，加载RDB文件恢复数据并存入新更改的数据

    4. 全量复制的性能开销：主要消耗在主节点RDB文件的生成须要的时间，其次是RDB文件在网络间的传输时间，还须要从节点的数据清空时间、加载RDB文件的时间

    5. 数据更改命令缓冲区repl_back_buffer用于：当Redis经过Linux中的fork()函数开辟一个子进程处理其余事务（好比主进程执行bgsave生成一个RDB文件时，或者主进程执行bgrewriteaof生成一个AOF文件时），而主进程（即处理客户端命令的进程）后续执行的一些数据更改命令会被暂时保存在该区域，并且该区域空间有限（配置文件中repl-backlog-size 1mb便可配置该处空间大小）

4. 主从复制的实现方式——部分复制功能

    1. 部分复制解决的问题：在实际环境中，主节点与从节点之间可能会发生一些网络波动等状况，致使从节点与主节点之间的网络链接断开（主从节点的Redis均未关闭），若是从新链接上后，可使用全量复制来从新进行一次主从节点数据同步，可是全量复制会带来一个性能开销的问题，并且从节点中可能有大量数据是主节点中没有更该过的，也就是不须要进行再次同步的数据，若是使用全量复制确定是带来了一些没必要要的浪费。因此，部分复制功能就是为了解决该问题的。

    2. 部分复制的发生过程：

• 主从节点直接链接断开，此时主节点继续执行的数据更改命令会被记录在一个缓冲区repl_back_buffer中
• 当从节点从新链接主节点时，就会自动发出一条命令(psync offset runid)，将从节点中存储的主节点的Redis运行时id和从节点中保存的偏移量发送给主节点
• 主节点接收从节点发送的偏移量和id，对比此时主节点的偏移量和接收的偏移量，若是两个偏移量之差大于repl_back_buffer中的数据，那么就表示在断开链接期间从节点已经丢失了超出规定数量的数据，此时就须要进行全量复制了，不然就进行部分复制
• 将主节点缓冲区中的数据同步更新到从节点中，这样就实现了部分数据的复制同步，下降了性能开销

5. 主从节点之间的故障维护

    1. 故障发生时服务自动转移（自动故障转移）：即当某个节点发生故障致使中止服务时，该节点提供的服务会有另外一个节点自动代替提供，这样就实现了一个高可用的效果

    2. 从节点故障：即若是某个从节点发生了故障，致使没法向在该节点上的客户端提供读服务，解决办法就是使该客户端转移到另外一个可用从节点上，可是在转移时，应该考虑该从节点能承受几个客户端的压力

    3. 主节点故障：若是主节点发生故障，在使用主节点进行读写操做的客户端就没法使用了，而使用从节点只进行读操做的客户端仍是能够继续使用的，解决办法就是从从节点中选一个节点更改成主节点，而且将原主节点的客户端链接到新的主节点上，而后经过该客户端将其余从节点链接到新的主节点中

    4. 主从复制确实能够解决故障问题，可是主从复制不能实现自动故障转移，其必需要经过一些手动操做，并且很是麻烦，因此要实现自动故障转移还须要另外一个功能，Redis中提供了sentinel功能来实现自动故障转移。

6. 主从复制常见问题

    1. 读写分离：即客户端发来的读写命令分开，写命令交给主节点执行，读命令交给从节点执行，不只减小了主节点的压力，并且加强了读操做的能力；但也会形成一些问题

• 可是主从节点之间数据复制形成的阻塞延迟也可能会致使主从不一致的状况，也就是主节点先进行了写操做，但可能由于数据复制形成的阻塞延迟，致使在从节点上进行的读操做获取的数据与主节点不一致
• 读取过时数据：主从复制会将带有过时时间的数据一并复制到从节点中，可是从节点是没有删除数据的能力的，即便是过时数据，因此主节点中的已经删除了过时数据，可是由于主从复制的阻塞延迟问题致使从节点中的过时数据没有删除，此时客户端就会读到一个过时数据

    2. 主从配置不一致：形成的问题有

• 好比配置中的maxmemory参数若是配置不一致，好比主节点2Gb，从节点1Gb，那么就可能会致使数据丢失；以及一些其余配置问题

    3. 规避全量复制：全量复制的性能开销较大，因此要尽可能避免全量复制，

• 在第一次创建主从节点关系式必定会发生全量复制；能够适当减少Redis的maxmemory参数，这样可使得RDB更快，或者选择在客户端操做低峰期进行，好比深夜
• 从节点中保存的主节点运行id不一致时也必定会发生全量复制（好比主节点的重启）；能够经过故障转移来尽可能避免
• 当主从节点的偏移量之差大于命令缓冲区repl_back_buffer中对应数据的偏移差时，也会发生全量复制，也就是上面的部分复制的复制过程当中所说的；能够增大配置文件中repl-backlog-size即数据缓冲区可尽可能避免

    4. 规避复制风暴：

• 单主节点致使的复制风暴，即当主节点重启后，要向其全部的从节点都进行一次全量复制，这很是消耗性能；能够更换主从节点的结果，更换为相似树形的结构，一个主节点只与少许的从节点创建主从关系，而而这些主节点又与其余从节点构成主从关系，以下图所示
• 单主节点机器复制风暴：即若是过一台机器专门用来部署多个主节点，而后其余机器部署从节点，那么一旦主节点机器宕机重启，就会引发全部的主从节点之间的全量复制，形成很是大的性能开销；能够采用多台机器，分散部署主节点，或者使用自动故障转移来将某个从节点变为主节点实现一个高可用