昨晚上被redis坑了一把，在挂掉重启后我足足等了半小时才启动成功，，通过发现原来是aof文件太大了，以前不知道这个文件是可以通过BGREWRITEAOF来优化的。
参考手册如下：
BGREWRITEAOF
执行一个重写操作。重写会创建一个当前 AOF 文件的体积优化版本。
即使执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在成功之前不会被修改。
重写操作只会在没有其他持久化工作在后台执行时被触发，也就是说：
如果 Redis 的子进程正在执行快照的保存工作，那么 AOF 重写的操作会被预定(scheduled)，等到保存工作完成之后再执行 AOF 重写。在这种情况下，的返回值仍然是OK，但还会加上一条额外的信息，说明要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本，可以使用命令查看是否被预定。如果已经有别的 AOF 文件重写在执行，那么返回一个错误，并且这个新的请求也不会被预定到下次执行。
从 Redis 2.4 开始， AOF 重写由 Redis 自行触发，仅仅用于手动触发重写操作。
又或者是后天的，我们不断学习，努力进取的路途中辛苦寻到的武器。
