Redis主从架构（读写分离）

如果redis需要支持10万+并发，那应该怎么做？

单击redis几乎不太可能QPS超过10万+，除非一些特殊情况，比如说你的机器性能特别好，配置特别高，物理机，维护做的非常好，而且你的整体操作不是太复杂才有可能达到。

一般来说，对缓存一般都是用来支撑读高并发的，写的请求是比较少的，写请求可能1秒钟也就几千，甚至一两千，大量的请求都是读，一秒钟二十万次。

我们使用redis的读写分离来支持10万+并发，一个master+多个slave节点架构方式来支撑。

redis replication的核心机制

• 一个master node是可以配置多个slave node
• slave node 也可以连接其他的slave node。
• redis采用异步方式复制数据到slave节点，在redis2.8后，slave node会周期性地确认自己每次复制的数据量。
• master默认每隔10秒会发送一次heartbeat，slave每隔一秒发送一个
• master每次接受到写命令之后，先在内部写入数据，然后异步发送给slave
• slave node在做复制的时候，是不会影响 master node的正常工作。
• slave node在做复制的时候，也不会影响对自己的查询操作，它会用旧的数据来提供服务，但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务。
• slave node 主要用来进行横向扩容，做读写分离，扩容可以提高读的吞吐量
  
  

主从架构的核心原理

• salve node启动，会保存master node信息（host和ip），这些信息来自redis.conf中slaveof的配置。
• 如果master设置了requirepass，那么slave node必须发送masterauth进行口令认证
• 认证通过salve node发送一个psync (同步)命令给master node
  
  
  • 如果salve node是第一次连接master node，就会触发一次full resynchronization（全量复制）
  • 如果slave node是重新连接master node，那么master node只会复制给slave缺少的数据（增量复制）
    
    
• 开始全量复制的时候，master会启动一个后台线程，开始生产一份RDB快照文件
  
  
  • 同时master会继续工作，将客户端所有新的写命令缓存到内存中
  • RDB文件生产完毕之后，master会将这个RDB发送 给slave
  • slave会先将RDB文件写入本地磁盘，再从磁盘加载到内存中
  • slave加载结束后master会将内存中缓存的写命令发送给slave，slave同步这些数据
    
    
• slave node如果跟master node有网络故障，断开连接，会自动重连（触发增量复制）。
• master如果发现有多个slave node重新来连接，只会启动一个rdb save操作，用一份数据发送给所有slave
  
  

数据同步核心机制

• master node在内存中创建一个baklog，默认大小1MB
• master和slave都会维护一个replica offset，offset保存在baklog中
  
  
  • master和slave自身会不断累加offerset，slave每秒会上报offset给master，master保存每个slave的offset
    
    
• master node和slave node 会保存一个master run id，slave node重新连接会和master node 比对 run id
  
  
  • 如果run id 不同，触发一次全量复制
  • 如果run id 相同，触发一次增量复制，slave会让master从上次replica offset记录的位置开始继续复制
  • 如果run id 相同，没有找到对应的offset，也会执行一次全量复制
    
    
  
  

全量复制

• master执行bgsave，在本地生成一份rdb快照文件
• master将rdb快照文件发送给salve，如果复制时间超过60秒（repl-timeout），那么salve就会认为复制失败
  千兆网卡的机器，一般每秒传输100MB，6G文件，很有可能超过60秒，我们可以适当调整这个参数
• master生成rdb时，会将所有新的写命令缓存到内存缓冲区中
• client-output-buffer-limit slave 256MB 64MB 60
  如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么复制失败，停止复制。
• salve保存rdb结束后，master再把新的写命令复制给salve
• slave 接受rdb文件结束后，停止对外服务，清空自己旧数据，然后重新加载RDB到自己内存中
• 如果slave 开启AOF，那么会离职执行bgrewriteAOF，重写AOF日志文件
  
  

全量复制数据在4G-6G直接，消耗时间可能在1分半到2分钟。

增量复制

• 如果全量复制过程中，master和slave网络连接中断，那么slave重新连接的时候回触发增量复制
• master直接从自己的backlog中获取部分丢失的数据，发送给slave
• master根据slave发送的psync中的offset来从backlog中获取数据
  
  

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

  repl-diskless-sync no，是否开启无磁盘化复制
  repl-diskless-sync-delay 5，等待一定时长再开始复制（单位秒），因为要等更多slave重新连接过来过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

master持久化对于主从架构的意义

如果采用了主从架构，那么建议必须开启master node 的持久化，不建议用slave node作为master node的数据热备。

master关闭持久化后，master宕机，重启没有本地数据可以恢复，然后就会认为自己的数据是空的，master就会将空的数据集同步到slave上去，导致所有的slave的数据全部清空。

master节点，必须使用持久化机制。

                                           Redis主从架构（读写分离）

如果redis需要支持10万+并发，那应该怎么做？

单击redis几乎不太可能QPS超过10万+，除非一些特殊情况，比如说你的机器性能特别好，配置特别高，物理机，维护做的非常好，而且你的整体操作不是太复杂才有可能达到。

一般来说，对缓存一般都是用来支撑读高并发的，写的请求是比较少的，写请求可能1秒钟也就几千，甚至一两千，大量的请求都是读，一秒钟二十万次。

我们使用redis的读写分离来支持10万+并发，一个master+多个slave节点架构方式来支撑。

redis replication的核心机制

• 一个master node是可以配置多个slave node
• slave node 也可以连接其他的slave node。
• redis采用异步方式复制数据到slave节点，在redis2.8后，slave node会周期性地确认自己每次复制的数据量。
• master默认每隔10秒会发送一次heartbeat，slave每隔一秒发送一个
• master每次接受到写命令之后，先在内部写入数据，然后异步发送给slave
• slave node在做复制的时候，是不会影响 master node的正常工作。
• slave node在做复制的时候，也不会影响对自己的查询操作，它会用旧的数据来提供服务，但是复制完成的时候，需要删除旧数据集，加载新数据集，这个时候就会暂停对外服务。
• slave node 主要用来进行横向扩容，做读写分离，扩容可以提高读的吞吐量
  
  

主从架构的核心原理

• salve node启动，会保存master node信息（host和ip），这些信息来自redis.conf中slaveof的配置。
• 如果master设置了requirepass，那么slave node必须发送masterauth进行口令认证
• 认证通过salve node发送一个psync (同步)命令给master node
  
  
  • 如果salve node是第一次连接master node，就会触发一次full resynchronization（全量复制）
  • 如果slave node是重新连接master node，那么master node只会复制给slave缺少的数据（增量复制）
    
    
• 开始全量复制的时候，master会启动一个后台线程，开始生产一份RDB快照文件
  
  
  • 同时master会继续工作，将客户端所有新的写命令缓存到内存中
  • RDB文件生产完毕之后，master会将这个RDB发送 给slave
  • slave会先将RDB文件写入本地磁盘，再从磁盘加载到内存中
  • slave加载结束后master会将内存中缓存的写命令发送给slave，slave同步这些数据
    
    
• slave node如果跟master node有网络故障，断开连接，会自动重连（触发增量复制）。
• master如果发现有多个slave node重新来连接，只会启动一个rdb save操作，用一份数据发送给所有slave
  
  

数据同步核心机制

• master node在内存中创建一个baklog，默认大小1MB
• master和slave都会维护一个replica offset，offset保存在baklog中
  
  
  • master和slave自身会不断累加offerset，slave每秒会上报offset给master，master保存每个slave的offset
    
    
• master node和slave node 会保存一个master run id，slave node重新连接会和master node 比对 run id
  
  
  • 如果run id 不同，触发一次全量复制
  • 如果run id 相同，触发一次增量复制，slave会让master从上次replica offset记录的位置开始继续复制
  • 如果run id 相同，没有找到对应的offset，也会执行一次全量复制
    
    
  
  

全量复制

• master执行bgsave，在本地生成一份rdb快照文件
• master将rdb快照文件发送给salve，如果复制时间超过60秒（repl-timeout），那么salve就会认为复制失败
  千兆网卡的机器，一般每秒传输100MB，6G文件，很有可能超过60秒，我们可以适当调整这个参数
• master生成rdb时，会将所有新的写命令缓存到内存缓冲区中
• client-output-buffer-limit slave 256MB 64MB 60
  如果在复制期间，内存缓冲区持续消耗超过64MB，或者一次性超过256MB，那么复制失败，停止复制。
• salve保存rdb结束后，master再把新的写命令复制给salve
• slave 接受rdb文件结束后，停止对外服务，清空自己旧数据，然后重新加载RDB到自己内存中
• 如果slave 开启AOF，那么会离职执行bgrewriteAOF，重写AOF日志文件
  
  

全量复制数据在4G-6G直接，消耗时间可能在1分半到2分钟。

增量复制

• 如果全量复制过程中，master和slave网络连接中断，那么slave重新连接的时候回触发增量复制
• master直接从自己的backlog中获取部分丢失的数据，发送给slave
• master根据slave发送的psync中的offset来从backlog中获取数据
  
  

无磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

  repl-diskless-sync no，是否开启无磁盘化复制
  repl-diskless-sync-delay 5，等待一定时长再开始复制（单位秒），因为要等更多slave重新连接过来过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

master持久化对于主从架构的意义

如果采用了主从架构，那么建议必须开启master node 的持久化，不建议用slave node作为master node的数据热备。

master关闭持久化后，master宕机，重启没有本地数据可以恢复，然后就会认为自己的数据是空的，master就会将空的数据集同步到slave上去，导致所有的slave的数据全部清空。

master节点，必须使用持久化机制。