最近新安裝了一台redis,版本為redis-3.2.5
數據盤用的是固態硬盤。
之前用的是普通硬盤，redis日志天天報
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
換了固態硬盤，就沒報了。
用了3天，發現aof文件越來越大。
-rw-r--r-- 1 root root 136672283898 Dec 9 08:50 appendonly_6379.aof
-rw-r--r-- 1 root root 5200941168 Dec 7 18:09 temp-rewriteaof-26452.aof
本身redis用了19G內存，但是aof文件達到了128G
每天早上起床都要把磁盤擴容一次才行，不然磁盤就滿了，煩死了。
可是這樣下去，不能解決問題，畢竟是雲服務器，每天加錢擴容也不好。
后來在網上，發現有一個命令BGREWRITEAOF，可以優化aof文件
步驟如下:
先進入redis
redis-cli -p 6379 -h 127.0.0.1
127.0.0.1:6379>BGREWRITEAOF
再去查看aof文件的目錄，發現多了一個文件
-rw-r--r-- 1 root root 136672283898 Dec 9 08:51 appendonly_6379.aof
-rw-r--r-- 1 root root 5851018456 Dec 9 08:51 temp-rewriteaof-1927.aof
-rw-r--r-- 1 root root 5200941168 Dec 7 18:09 temp-rewriteaof-26452.aof
等待幾分鍾
再次查看aof文件
-rw-r--r-- 1 root root 22477825463 Dec 9 09:11 appendonly_6380.aof
-rw-r--r-- 1 root root 5200941168 Dec 7 18:09 temp-rewriteaof-26452.aof
已經明顯減少了
再把temp-rewriteaof-26452.aof文件刪除，它已經沒有用了
我突然發現一個問題
執行了BGREWRITEAOF之后，temp-rewriteaof之類的文件，就再也沒有產生了，好神奇。
引用相關解釋:
BGREWRITEAOF
執行一個 AOF文件 重寫操作。重寫會創建一個當前 AOF 文件的體積優化版本。
即使 BGREWRITEAOF 執行失敗，也不會有任何數據丟失，因為舊的 AOF 文件在 BGREWRITEAOF 成功之前不會被修改。
重寫操作只會在沒有其他持久化工作在后台執行時被觸發，也就是說：
如果 Redis 的子進程正在執行快照的保存工作，那么 AOF 重寫的操作會被預定(scheduled)，等到保存工作完成之后再執行 AOF 重寫。在這種情況下， BGREWRITEAOF 的返回值仍然是 OK ，但還會加上一條額外的信息，說明 BGREWRITEAOF 要等到保存操作完成之后才能執行。在 Redis 2.6 或以上的版本，可以使用 INFO 命令查看 BGREWRITEAOF 是否被預定。
如果已經有別的 AOF 文件重寫在執行，那么 BGREWRITEAOF 返回一個錯誤，並且這個新的 BGREWRITEAOF 請求也不會被預定到下次執行。
從 Redis 2.4 開始， AOF 重寫由 Redis 自行觸發， BGREWRITEAOF 僅僅用於手動觸發重寫操作。
我都已經3.2.5，貌似redis沒有自動觸發BGREWRITEAOF
算了，還是每天定期的去執行一次
寫了一個腳本
brgewriteaof.sh
內容如下:
#!/bin/bash
/usr/local/redis/redis-cli -p 6379 -h 127.0.0.1 BGREWRITEAOF
添加權限
chmod 755 brgewriteaof.sh
設定任務計划，每天凌晨2點跑一次
0 2 * * * /opt/brgewriteaof.sh
經過幾個月之后，發現還是存在aof文件過大的問題。所以，用定時任務來跑，不能解決根本問題。
因為aof是記錄了很多操作日志,就像Mysql的bin_log日志一樣，體積比rdb方式持久化文件要大的多。
理想情況下，aof的大小和當前內存使用的大小是一樣的。
更改配置文件
/kuaibao/server/redis/conf/redis.conf
auto-aof-rewrite-percentage 50
然后重啟redis
這段配置，是指當aof文件增值率達到50%時，優化一次aof，也就是執行BGREWRITEAOF命令
默認是100，因為線上寫入比較頻率，所以增長率要調低一點。
之前100多個G的aof，重寫一次之后，降至30G。
最后發現，因為磁盤I/O，導致aof重寫失敗
產生多個臨時文件，把磁盤占滿了。
沒辦法，還是改回rdb方式了。確實比aof空間要小一點。