redis的持久化机制分为两种，rtb和aof。
其默认灾备模式为rtb,是一种快照式的备份。
aof机制，需要配置appendonly yes。
昨天开发环境的主机，意外断电。
集群重启后，redis群集首先得现象是数据丢失。
猜测是运维启动集群的时候，与之前的方式并不一致。
因为是开发环境，里面的数据是测试数据，数据丢失并没有太重视。
调用api发现，redis集群报错。数据已经无法正确写入。
报错信息如下：
Jedis Cluster Exception: CLUSTERDOWN Hash slot not served
经过查阅资料，对redis每个节点的进行了slot修复。
其检查slot错误与修复的命令如下：
检查：redis-trib.rb check 127.0.0.1:7000
修复：redis-trib.rb fix 127.0.0.1:7000其运行过程中：部分执行过程截图如下：
恢复slot之后，redis集群可以插入数据。
开始考虑数据恢复的问题。
在客户端文件夹内，找到了aof文件，准备恢复试试看。
执行命令：
redis-cli -h localhost -p 7003 --pipe < /usr/local/appendonly_7003.aof其中-h参数后，为redis的节点ip。。-p后的参数为端口号。
–pipe后面的参数为aof地址。
数据顺利恢复，节点恢复正常使用。
后记，以后数据恢复之后，环境也ok了，准备开始开发。
结果发现redis可以单节点插入数据，集群模式则出现报错。
报错信息：
redis.clients.jedis.exceptions.JedisException: Could not get a resource from the pool
java.net.ConnectException: Connection refused: connect
这两个报错信息是毫无头绪的。
在检索第二个报错信息的过程中发现， Connection refused: connect常发现于端口、ip、防火墙等设置，导致无法联通。故猜测几个redis节点之间，并没有主从关系信息。
调取了运维重启redis的命令，发现启动的时候，没有载入节点数据。
启动redis命令：
redis-server /usr/local/cluster/7005/redis.conf --cluster-config-file /usr/local/nodes-7005.conf后天就是deadline，一场停电引发的问题终于结束了。
