codis的主从同步及RDB备份

redis的主从同步过程

• 主从同步是全量的还是增量的？

slave在刚初始化时全量，后续都是增量

• slave多久从master同步一次？

master上每执行一次写命令，都会向slave发送一次

• 全量同步过程

1）从机向主机发起一个同步指令sync
2）主机redis收到该指令后会执行BGSAVE命令，该命令类似于RDB持久化，会生成一个快照文件并使用缓冲区记录此后执行的所有写命令（具体也是参照RDB方式，fork中一个子进程，用于生成快照文件）
3）主redis执行BGSAVE完毕后，向所有从redis发送RDB文件，并在发送期间继续记录被执行的写命令；
4）从redis收到RDB快照文件后丢弃所有旧数据，载入收到的快照；
5）主redis发送快照完毕后开始向从redis发送缓冲区的写命令；
6）从服务器完成对快照的载入后，开始接收写命令，并执行这些写命令

• 增量同步过程

增量同步就是Slave初始化后开始正常工作或，主服务器发生的写操作会同步到从服务器的过程。它是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

以上的内容参见博文《Redis的主从复制同步过程》

redis主从同步失败的原因

最近生产环境的codis集群出现了主从不能复制的情况，而且主从的rdb文件超级大，有8G多。最后解决办法直接删除了rdb文件，然后重启了集群。这样数据就都丢失了，万幸数据可以在十几分钟内又全部刷新了一遍写入了redis。以下搜集了一些主从同步失败的原因。绝大数人在遇到主从同步失败的解决办法都是调大了slave的repl-timeout参数（默认为60s）,可我调大了参数依然没能解决问题。最终只能清空了集群，一切从头再来了。（个人猜想原因为rdb文件太大，当时系统资源不足，导致文件复制很慢，主从之间的复制也非常慢，60s不能满足需求。）

1. 复制时间超时
   默认60，如果60s内master还没有把需要复制的命令传给slave,那么就断开链接
2. 复制缓冲区溢出
   master把要传给slave的指令先放在复制缓冲，而复制缓冲区是有大小限制的。如果超过了这个限制，master就直接断掉和slave的链接，slave再次去同步又被断掉，形成一个往复循环。要注意的是增量同步环节压力还要小一些，在全量同步阶段可就不是那么小的数据量了。例如master的rdb有500M,而复制缓冲区只有280M,那么全量同步阶段就会因为复制缓冲区大小的限制而失败。

下面是修改复制时间和复制缓冲区大小的命令。

#redis-cli
>config get repl-timeout #查看repl-timeout大小
>config set repl-timeout 180 #修改repl-timeout大小
>config set client-output-buffer-limit # hard limit , soft limit,soft seconds
><hard limit>：若output buffer大小超过该值，Redis会立即关闭与对应client的连接
><soft limit> <soft seconds>：若output buffer大小超过soft limit且这种情况的持续时间超过soft seconds，则Redis会关闭与对应client的连接。
>config set client-output-buffer-limit 'slave 536870912 134217728 120' #设置复制缓冲区大小

《redis错误配置详解》

redis的BGSAVE生成RDB文件

• BGSAVE生成RDB是否消耗资源？
  非常消耗系统资源，且BGSAVE在运行中，如果有新的BGSAVE命令执行会报错。虽然RDB文件是fork的新进程，不会影响到master的响应，但是会消耗系统的资源（我们的系统中RDB文件约600M,完成一次BGDSAVE约半分钟。有一台服务器上codis节点的RDB文件达到8G,BGSAVE一次要1个小时，造成了比较严重的问题）。
  看到有些人在关闭了BGSAVE后响应时间有很大的提升。redis 关闭 bgsave 后整个 web 响应时间提升 5 倍，这是个坑么？
• redis.conf中的save频率如何设置合适？

redis 分 cache 和 nosql 用的，cache 的可以丢，nosql 的不可以丢
cache 的不开 bgsave
nosql 的开，然后 slave 上备份 dump.rdb 文件

如果对数据的丢失并不是非常在意，可以把save的频率适当降低
在非常繁忙的 Redis 服务器上，大家的 SAVE 参数一般是怎么配置的呢？

客户端缓冲区

上面提到了主从复制的缓冲区，除此之外redis作为server端与client也是有缓冲区的。

• redis server和client之间为什么有缓冲？

You probably already know that Redis is an in-memory database, which means that all data is managed and served directly from RAM. This allows Redis to deliver unparalleled performance, serving tens and hundreds of thousands of requests at sub-millisecond latencies. RAM is by far the fastest means of storage that technology offers today – to get a sense of latency numbers, have a look at the following:
Redis, by name and design, is a remote server and that means that clients (usually) connect to it over a network. That being the case, a client’s request will take significantly more time to return to the client than the actual fetching of data from RAM by Redis’ CPU. The direct implication of this order of magnitude difference is that Redis would have been tied up serving the request for the duration of that time, had it not been for client buffers.

简而言之，server内部用RAM,速度非常快，而server和client之间用网络通信，这明显慢于RAM响应速度，为了防止server 被client的慢网络通信所捆绑住，所以要有缓冲区。

server: client大爷,你要的数据我都给你放缓冲了，你腿脚不好，慢慢取不着急。我去干别的了！
client: Ok！
然后client开始狂吃狂吃读数据。server事了拂衣去。

• 因为客户端缓冲的存在要注意什么问题？

生产环境中不要用keys,hgetall等批量匹配的命令，如果返回数据过多，达到maxmemory，可能会造正数据驱逐。
关于什么是数据驱逐，见《redis的淘汰机制》

codis dashboard页面几个键的功能

页面上的slaveof没事不能乱点，好像会执行主从之间的全量复制，如果RDB文件很大，会造成很大的开销。