1、起因，一个flushdb命令
因为误操作，
输入了一个flushdb命令，
导到redis里0号库里的数据全部清空，OMG，这里有不少重要信息，如果被领导知道，必开除
2、appendonly留有生机
仔细想想，当时数据备份是有设置日志备份的，找到Redis的配置文件redis.conf
appendonly yes
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"
于是将appendonly.aof文件导出，自己在线下又搭了个redis，开始尝试将数据恢复出来
3、编辑日志文件
我最开始用的EditPlus，拉开文件，拉到最底下，看到了flushdb的操作记录，呵呵，心情大好
但是无论你怎么改appendonly.aof,都无法通过redis-check-aof的检验，会一直报数据有错，使用fix方法反而会将所有记录清空，反正是不能用EditPlus这种普通的文本编辑器了，
要用个十六进制进制编辑器，于是download了一个Hex Editor。
多找几个aof文件用来进行对比，分析它的数据格式(这个需要点耐心，反正我是用猜的)，分析得出其flushdb在其中对应的字符是"*1..$7..flushdb.."，删除这一段后保存。
将保存好的appendonly.aof上传到Redis的服务器，重启Redis，顺利启动，
用redis-cli查看数据，输入
keys *
有数据了，长吁一口气
这事太丢人了，要引以为戒，想办法抹掉能抹的痕迹。事了拂衣去，早早洗了睡，不想再掺和运维的事了，太吓人了。
