Redis问题集锦
持续更新... ...
BGSAVE causes master to become unresponsive
现象：当slave突然跟master断开，然后再次连接上master的时候，slave向master请求一次full resync，而full resync导致了master夯住，无法响应客户端当前请求（bgsave的原因）。集群中的其它节点由于master响应超时，就会认为master down掉，从而发生failover，将slave提升为master。而当master完成bgsave之后，重新响应客户端的请求，此时它发现自己不再是master，而是一个slave，因此它就会向当前的master请求一次full resync。
解决办法：
- 一般情况下，bgsave命令不会使得redis instance夯住，因此首先需要解决为什么bgsave命令把redis instance夯住。
-
node-timeout参数可能设置小了，导致redis cluster节点超时，可设置一个更大的值。 - replication backlog可能设置小了，导致slave短时间的掉线都需要进行一次full resync，可以考虑把replication backlog的值设置得更大些。
FLUSHALL doesn't really work on cluster with big nodes
问题描述：当节点很大时（指有很多的key），在master上执行flushall命令，由于flushall命令是个阻塞命令，并且执行时间很长，导致节点超时下线。
解决办法：未来版本中的lazy命令可以解决这个问题。
相关issue：2902
Speedup Redis Cluster config propagation
问题描述：Redis使用了gossip协议进行集群管理集群，因此当添加一个新的节点的时候（新节点像集群中的节点发送cluster meet命令），由于gossip消息的传播延时，会导致当你发送了cluster meet命令之后，仍然会收到unknown node错误。
解决办法：
- Send Cluster MEET.
- Check if all the nodes know the new node not in handshake state but just "master".
- If not, wait a second and GOTO 2.
