Redis是一個高性能的key-value數據庫。node
Redis支持數據的持久化,能夠將內存中的數據保存在磁盤中,重啓的時候能夠再次加載進行使用。
Redis不只僅支持簡單的key-value類型的數據,同時還提供list,set,zset,hash等數據結構的存儲。
Redis支持數據的備份,即master-slave模式的數據備份。redis
爲了更好的使用redis,咱們須要詳細的瞭解redis配置文件及相關參數做用。算法
include /path/to/local.conf
額外載入配置文件,若是有須要的話,能夠開啓此配置數據庫
bind 127.0.0.1 bind 192.168.1.100
綁定redis服務器網卡IP,默認爲127.0.0.1,即本地迴環地址。這樣的話,訪問redis服務只能經過本機的客戶端鏈接,而沒法經過遠程鏈接。若是bind選項爲空的話,那會接受全部來自於可用網絡接口的鏈接。如上配置,綁定一個127.0.0.1的本機地址和192.168.1.100的外網地址。安全
protected-mode yes
保護模式,默認是開啓狀態,只容許本地客戶端鏈接, 能夠設置密碼或添加bind來鏈接bash
port 6379
監聽端口號,默認爲6379,若是設爲0,redis將不在socket 上監放任何客戶端鏈接服務器
tcp-backlog 511
TCP監聽的最大容納數量,在高併發的環境下,你須要把這個值調高以免客戶端鏈接緩慢的問題。Linux 內核會把這個值縮小成 /proc/sys/net/core/somaxconn對應的值,要提高併發量須要修改這兩個值才能達到目的網絡
unixsocket /tmp/redis.sock unixsocketperm 700
指定redis監聽的unix socket路徑,默認不啓用,unixsocketper指定文件的權限數據結構
timeout 0
指定在一個 client 空閒多少秒以後關閉鏈接(0表示永不關閉)併發
tcp-keepalive 300
單位是秒,表示將週期性的使用SO_KEEPALIVE檢測客戶端是否還處於健康狀態,避免服務器一直阻塞,官方給出的建議值是300s,若是設置爲0,則不會週期性的檢測
daemonize yes
默認狀況下 redis 不是做爲守護進程運行的,若是你想讓它在後臺運行,你就把它改爲 yes。當redis做爲守護進程運行的時候,它會寫一個 pid 到 /var/run/redis.pid 文件裏面
supervised no
能夠經過upstart和systemd管理Redis守護進程
選項:
supervised no - 沒有監督互動
supervised upstart - 經過將Redis置於SIGSTOP模式來啓動信號
supervised systemd - signal systemd將READY = 1寫入$ NOTIFY_SOCKET
supervised auto - 檢測upstart或systemd方法基於 UPSTART_JOB或NOTIFY_SOCKET環境變量
pidfile /var/redis/run/redis_6379.pid
配置PID文件路徑,當redis做爲守護進程運行的時候,它會把 pid 默認寫到 /var/redis/run/redis_6379.pid 文件裏面
loglevel notice
定義日誌級別。
能夠是下面的這些值:
debug(記錄大量日誌信息,適用於開發、測試階段)
verbose(較多日誌信息)
notice(適量日誌信息,使用於生產環境)
warning(僅有部分重要、關鍵信息纔會被記錄)
logfile /var/redis/log/redis_6379.log
日誌文件的位置,當指定爲空字符串時,爲標準輸出,若是redis已守護進程模式運行,那麼日誌將會輸出到/dev/null
syslog-enabled no
要想把日誌記錄到系統日誌,就把它改爲 yes,也能夠可選擇性的更新其餘的syslog 參數以達到你的要求
syslog-ident redis
設置系統日誌的ID
syslog-facility local0
指定系統日誌設置,必須是 USER 或者是 LOCAL0-LOCAL7 之間的值
databases 16
設置數據庫的數目。默認的數據庫是DB 0 ,能夠在每一個鏈接上使用select <dbid> 命令選擇一個不一樣的數據庫,dbid是一個介於0到databases - 1 之間的數值。
save 900 1 save 300 10 save 60 10000
存 DB 到磁盤:
格式:save <間隔時間(秒)> <寫入次數>
根據給定的時間間隔和寫入次數將數據保存到磁盤
下面的例子的意思是:
900 秒內若是至少有 1 個 key 的值變化,則保存
300 秒內若是至少有 10 個 key 的值變化,則保存
60 秒內若是至少有 10000 個 key 的值變化,則保存
注意:你能夠註釋掉全部的 save 行來停用保存功能。
也能夠直接一個空字符串來實現停用:
save ""
stop-writes-on-bgsave-error yes
若是用戶開啓了RDB快照功能,那麼在redis持久化數據到磁盤時若是出現失敗,默認狀況下,redis會中止接受全部的寫請求。
這樣作的好處在於可讓用戶很明確的知道內存中的數據和磁盤上的數據已經存在不一致了。
若是redis不顧這種不一致,獨斷獨行的繼續接收寫請求,就可能會引發一些災難性的後果。
若是下一次RDB持久化成功,redis會自動恢復接受寫請求。
若是不在意這種數據不一致或者有其餘的手段發現和控制這種不一致的話,能夠關閉這個功能,
以便在快照寫入失敗時,也能確保redis繼續接受新的寫請求。
rdbcompression yes
對於存儲到磁盤中的快照,能夠設置是否進行壓縮存儲。
若是是的話,redis會採用LZF算法進行壓縮。若是你不想消耗CPU來進行壓縮的話,
能夠設置爲關閉此功能,可是存儲在磁盤上的快照會比較大。
rdbchecksum yes
在存儲快照後,咱們還可讓redis使用CRC64算法來進行數據校驗,可是這樣作會增長大約10%的性能消耗,
若是但願獲取到最大的性能提高,能夠關閉此功能。
dbfilename dump.rdb
設置快照的文件名
dir /var/redis/6379
設置快照文件的存放路徑,這個配置項必定是個目錄,而不能是文件名
slaveof <masterip> <masterport>
主從複製,使用 slaveof 來讓一個 redis 實例成爲另外一個reids 實例的副本,默認關閉
注意這個只須要在 slave 上配置
masterauth <master-password>
若是 master 須要密碼認證,就在這裏設置,默認不設置
slave-serve-stale-data yes
當一個 slave 與 master 失去聯繫,或者複製正在進行的時候,
slave 可能會有兩種表現:
1) 若是爲 yes ,slave 仍然會應答客戶端請求,但返回的數據多是過期,
或者數據多是空的在第一次同步的時候
2) 若是爲 no ,在你執行除了 info he salveof 以外的其餘命令時,
slave 都將返回一個 "SYNC with master in progress" 的錯誤
slave-read-only yes
你能夠配置一個 slave 實體是否接受寫入操做。
經過寫入操做來存儲一些短暫的數據對於一個 slave 實例來講多是有用的,
由於相對從 master 從新同步數而言,據數據寫入到 slave 會更容易被刪除。
可是若是客戶端由於一個錯誤的配置寫入,也可能會致使一些問題。
從 redis 2.6 版起,默認 slaves 都是隻讀的。
repl-diskless-sync no
主從數據複製是否使用無硬盤複製功能。
新的從站和重連後不能繼續備份的從站,須要作所謂的「徹底備份」,即將一個RDB文件從主站傳送到從站。
這個傳送有如下兩種方式:
1)硬盤備份:redis主站建立一個新的進程,用於把RDB文件寫到硬盤上。過一下子,其父進程遞增地將文件傳送給從站。
2)無硬盤備份:redis主站建立一個新的進程,子進程直接把RDB文件寫到從站的套接字,不須要用到硬盤。
在硬盤備份的狀況下,主站的子進程生成RDB文件。一旦生成,多個從站能夠當即排成隊列使用主站的RDB文件。
在無硬盤備份的狀況下,一次RDB傳送開始,新的從站到達後,須要等待如今的傳送結束,才能開啓新的傳送。
若是使用無硬盤備份,主站會在開始傳送之間等待一段時間(可配置,以秒爲單位),但願等待多個子站到達後並行傳送。
在硬盤低速而網絡高速(高帶寬)狀況下,無硬盤備份更好。
repl-diskless-sync-delay 5
當啓用無硬盤備份,服務器等待一段時間後纔會經過套接字向從站傳送RDB文件,這個等待時間是可配置的。
這一點很重要,由於一旦傳送開始,就不可能再爲一個新到達的從站服務。從站則要排隊等待下一次RDB傳送。所以服務器等待一段
時間以期更多的從站到達。
延遲時間以秒爲單位,默認爲5秒。要關掉這一功能,只需將它設置爲0秒,傳送會當即啓動。
repl-ping-slave-period 10
從redis會週期性的向主redis發出PING包,你能夠經過repl_ping_slave_period指令來控制其週期,默認是10秒。
repl-timeout 60
接下來的選項爲如下內容設置備份的超時時間:
1)從從站的角度,同步期間的批量傳輸的I/O
2)從站角度認爲的主站超時(數據,ping)
3)主站角度認爲的從站超時(REPLCONF ACK pings)
確認這些值比定義的repl-ping-slave-period要大,不然每次主站和從站之間通訊低速時都會被檢測爲超時。
repl-disable-tcp-nodelay no
同步以後是否禁用從站上的TCP_NODELAY
若是你選擇yes,redis會使用較少許的TCP包和帶寬向從站發送數據。但這會致使在從站增長一點數據的延時。
Linux內核默認配置狀況下最多40毫秒的延時。
若是選擇no,從站的數據延時不會那麼多,但備份須要的帶寬相對較多。
默認狀況下咱們將潛在因素優化,但在高負載狀況下或者在主從站都跳的狀況下,把它切換爲yes是個好主意。
repl-backlog-size 1mb
設置備份的工做儲備大小。工做儲備是一個緩衝區,當從站斷開一段時間的狀況時,它替從站接收存儲數據,
所以當從站重連時,一般不須要徹底備份,只須要一個部分同步就能夠,即把從站斷開時錯過的一部分數據接收。
工做儲備越大,從站能夠斷開並稍後執行部分同步的斷開時間就越長。
只要有一個從站鏈接,就會馬上分配一個工做儲備。
repl-backlog-ttl 3600
主站有一段時間沒有與從站鏈接,對應的工做儲備就會自動釋放。
這個選項用於配置釋放前等待的秒數,秒數從斷開的那一刻開始計算,值爲0表示不釋放。
slave-priority 100
從站優先級是能夠從redis的INFO命令輸出中查到的一個整數。當主站不能正常工做時
redis sentinel使用它來選擇一個從站並將它提高爲主站。
低優先級的從站被認爲更適合於提高,所以若是有三個從站優先級分別是10,
100,25,sentinel會選擇優先級爲10的從站,由於它的優先級最低。
然而優先級值爲0的從站不能執行主站的角色,所以優先級爲0的從站永遠不會被redis sentinel提高。
默認優先級是100
min-slaves-to-write 3 min-slaves-max-lag 10
主站能夠中止接受寫請求,當與它鏈接的從站少於N個,滯後少於M秒,N個從站必須是在線狀態。
延遲的秒數必須<=所定義的值,延遲秒數是從最後一次收到的來自從站的ping開始計算。ping一般是每秒一次。
這一選項並不保證N個備份都會接受寫請求,可是會限制在指定秒數內因爲從站數量不夠致使的寫操做丟失的狀況。
若是想要至少3個從站且延遲少於10秒,如上配置便可
slave-announce-ip 5.5.5.5 slave-announce-port 1234
Redis master可以以不一樣的方式列出所鏈接slave的地址和端口。
例如,「INFO replication」部分提供此信息,除了其餘工具以外,Redis Sentinel還使用該信息來發現slave實例。
此信息可用的另外一個地方在masterser的「ROLE」命令的輸出中。
一般由slave報告的列出的IP和地址,經過如下方式得到:
IP:經過檢查slave與master鏈接使用的套接字的對等體地址自動檢測地址。
端口:端口在複製握手期間由slavet通訊,而且一般是slave正在使用列出鏈接的端口。
然而,當使用端口轉發或網絡地址轉換(NAT)時,slave實際上能夠經過(不一樣的IP和端口對)來到達。 slave可使用如下兩個選項,以便向master報告一組特定的IP和端口,
以便INFO和ROLE將報告這些值。
若是你須要僅覆蓋端口或IP地址,則不必使用這兩個選項。
requirepass foobared
設置redis鏈接密碼
rename-command CONFIG ""
將命令重命名,爲了安全考慮,能夠將某些重要的、危險的命令重命名。
當你把某個命令重命名成空字符串的時候就等於取消了這個命令。
maxclients 10000
設置客戶端最大併發鏈接數,默認無限制,Redis能夠同時打開的客戶端鏈接數爲Redis進程能夠打開的最大文件
描述符數-32(redis server自身會使用一些),若是設置 maxclients爲0
表示不做限制。當客戶端鏈接數到達限制時,Redis會關閉新的鏈接並向客戶端返回max number of clients reached錯誤信息
maxmemory <bytes>
指定Redis最大內存限制,Redis在啓動時會把數據加載到內存中,達到最大內存後,Redis會先嚐試清除已到期或即將到期的Key
當此方法處理 後,仍然到達最大內存設置,將沒法再進行寫入操做,但仍然能夠進行讀取操做。Redis新的vm機制,
會把Key存放內存,Value會存放在swap區,格式:maxmemory <bytes>
maxmemory-policy noeviction
當內存使用達到最大值時,redis使用的清楚策略。有如下幾種能夠選擇:
1)volatile-lru 利用LRU算法移除設置過過時時間的key (LRU:最近使用 Least Recently Used )
2)allkeys-lru 利用LRU算法移除任何key
3)volatile-random 移除設置過過時時間的隨機key
4)allkeys-random 移除隨機ke
5)volatile-ttl 移除即將過時的key(minor TTL)
6)noeviction noeviction 不移除任何key,只是返回一個寫錯誤 ,默認選項
maxmemory-samples 5
LRU 和 minimal TTL 算法都不是精準的算法,可是相對精確的算法(爲了節省內存)
隨意你能夠選擇樣本大小進行檢,redis默認選擇3個樣本進行檢測,你能夠經過maxmemory-samples進行設置樣本數
appendonly no
默認redis使用的是rdb方式持久化,這種方式在許多應用中已經足夠用了。可是redis若是中途宕機,
會致使可能有幾分鐘的數據丟失,根據save來策略進行持久化,Append Only File是另外一種持久化方式,
能夠提供更好的持久化特性。Redis會把每次寫入的數據在接收後都寫入appendonly.aof文件,
每次啓動時Redis都會先把這個文件的數據讀入內存裏,先忽略RDB文件。
appendfilename "appendonly.aof"
aof文件名
appendfsync always
appendfsync everysec
appendfsync no
aof持久化策略的配置
no表示不執行fsync,由操做系統保證數據同步到磁盤,速度最快。
always表示每次寫入都執行fsync,以保證數據同步到磁盤。
everysec表示每秒執行一次fsync,可能會致使丟失這1s數據
no-appendfsync-on-rewrite no
在aof重寫或者寫入rdb文件的時候,會執行大量IO,此時對於everysec和always的aof模式來講,
執行fsync會形成阻塞過長時間,no-appendfsync-on-rewrite字段設置爲默認設置爲no。
若是對延遲要求很高的應用,這個字段能夠設置爲yes,不然仍是設置爲no,這樣對持久化特性來講這是更安全的選擇。
設置爲yes表示rewrite期間對新寫操做不fsync,暫時存在內存中,等rewrite完成後再寫入,默認爲no,建議yes。
Linux的默認fsync策略是30秒。可能丟失30秒數據。
auto-aof-rewrite-percentage 100
aof自動重寫配置,當目前aof文件大小超過上一次重寫的aof文件大小的百分之多少進行重寫,
即當aof文件增加到必定大小的時候,Redis可以調用bgrewriteaof對日誌文件進行重寫。
當前AOF文件大小是上第二天志重寫獲得AOF文件大小的二倍(設置爲100)時,自動啓動新的日誌重寫過程。
auto-aof-rewrite-min-size 64mb
設置容許重寫的最小aof文件大小,避免了達到約定百分比但尺寸仍然很小的狀況還要重寫
aof-load-truncated yes
aof文件可能在尾部是不完整的,當redis啓動的時候,aof文件的數據被載入內存。
重啓可能發生在redis所在的主機操做系統宕機後,尤爲在ext4文件系統沒有加上data=ordered選項,出現這種現象
redis宕機或者異常終止不會形成尾部不完整現象,能夠選擇讓redis退出,或者導入儘量多的數據。
若是選擇的是yes,當截斷的aof文件被導入的時候,會自動發佈一個log給客戶端而後load。
若是是no,用戶必須手動redis-check-aof修復AOF文件才能夠。
lua-time-limit 5000
若是達到最大時間限制(毫秒),redis會記個log,而後返回error。當一個腳本超過了最大時限。
只有SCRIPT KILL和SHUTDOWN NOSAVE能夠用。第一個能夠殺沒有調write命令的東西。
要是已經調用了write,只能用第二個命令殺
cluster-enabled yes
集羣開關,默認是不開啓集羣模式
cluster-config-file nodes-6379.conf
集羣配置文件的名稱,每一個節點都有一個集羣相關的配置文件,持久化保存集羣的信息。
這個文件並不須要手動配置,這個配置文件有Redis生成並更新,每一個Redis集羣節點須要一個單獨的配置文件
請確保與實例運行的系統中配置文件名稱不衝突
cluster-node-timeout 15000
節點互連超時的閥值,集羣節點超時毫秒數
cluster-slave-validity-factor 10
在進行故障轉移的時候,所有slave都會請求申請爲master,可是有些slave可能與master斷開鏈接一段時間了,
致使數據過於陳舊,這樣的slave不該該被提高爲master。該參數就是用來判斷slave節點與master斷線的時間是否過長。
判斷方法是:
比較slave斷開鏈接的時間和(node-timeout * slave-validity-factor) + repl-ping-slave-period
若是節點超時時間爲三十秒, 而且slave-validity-factor爲10,
假設默認的repl-ping-slave-period是10秒,即若是超過310秒slave將不會嘗試進行故障轉移
cluster-migration-barrier 1
master的slave數量大於該值,slave才能遷移到其餘孤立master上,如這個參數若被設爲2,
那麼只有當一個主節點擁有2 個可工做的從節點時,它的一個從節點會嘗試遷移。
cluster-require-full-coverage yes
默認狀況下,集羣所有的slot有節點負責,集羣狀態才爲ok,才能提供服務。
設置爲no,能夠在slot沒有所有分配的時候提供服務。
不建議打開該配置,這樣會形成分區的時候,小分區的master一直在接受寫請求,而形成很長時間數據不一致
slowlog-log-slower-than 10000
slog log是用來記錄redis運行中執行比較慢的命令耗時。
當命令的執行超過了指定時間,就記錄在slow log中,slog log保存在內存中,因此沒有IO操做。
執行時間比slowlog-log-slower-than大的請求記錄到slowlog裏面,單位是微秒,因此1000000就是1秒。
注意,負數時間會禁用慢查詢日誌,而0則會強制記錄全部命令。
slowlog-max-len 128
慢查詢日誌長度。當一個新的命令被寫進日誌的時候,最老的那個記錄會被刪掉,這個長度沒有限制。
只要有足夠的內存就行,你能夠經過 SLOWLOG RESET 來釋放內存
latency-monitor-threshold 0
延遲監控功能是用來監控redis中執行比較緩慢的一些操做,用LATENCY打印redis實例在跑命令時的耗時圖表。
只記錄大於等於下邊設置的值的操做,0的話,就是關閉監視。
默認延遲監控功能是關閉的,若是你須要打開,也能夠經過CONFIG SET命令動態設置。
notify-keyspace-events ""
鍵空間通知使得客戶端能夠經過訂閱頻道或模式,來接收那些以某種方式改動了 Redis 數據集的事件。由於開啓鍵空間通知功能須要消耗一些 CPU ,因此在默認配置下,該功能處於關閉狀態。
notify-keyspace-events 的參數能夠是如下字符的任意組合,它指定了服務器該發送哪些類型的通知:
K 鍵空間通知,全部通知以 __keyspace@__ 爲前綴
E 鍵事件通知,全部通知以 __keyevent@__ 爲前綴
g DEL 、 EXPIRE 、 RENAME 等類型無關的通用命令的通知
$ 字符串命令的通知
l 列表命令的通知
s 集合命令的通知
h 哈希命令的通知
z 有序集合命令的通知
x 過時事件:每當有過時鍵被刪除時發送
e 驅逐(evict)事件:每當有鍵由於 maxmemory 政策而被刪除時發送
A 參數 g$lshzxe 的別名
輸入的參數中至少要有一個 K 或者 E,不然的話,無論其他的參數是什麼,都不會有任何 通知被分發。
hash-max-ziplist-entries 512
hash類型的數據結構在編碼上可使用ziplist和hashtable。
ziplist的特色就是文件存儲(以及內存存儲)所需的空間較小,在內容較小時,性能和hashtable幾乎同樣。
所以redis對hash類型默認採起ziplist。若是hash中條目的條目個數或者value長度達到閥值,將會被重構爲hashtable。
這個參數指的是ziplist中容許存儲的最大條目個數,,默認爲512,建議爲128
hash-max-ziplist-value 64
ziplist中容許條目value值最大字節數,默認爲64,建議爲1024
list-max-ziplist-size -2
當取正值的時候,表示按照數據項個數來限定每一個quicklist節點上的ziplist長度。好比,當這個參數配置成5的時候,表示每一個quicklist節點的ziplist最多包含5個數據項。
當取負值的時候,表示按照佔用字節數來限定每一個quicklist節點上的ziplist長度。這時,它只能取-1到-5這五個值,每一個值含義以下:
-5: 每一個quicklist節點上的ziplist大小不能超過64 Kb。(注:1kb => 1024 bytes)
-4: 每一個quicklist節點上的ziplist大小不能超過32 Kb。
-3: 每一個quicklist節點上的ziplist大小不能超過16 Kb。
-2: 每一個quicklist節點上的ziplist大小不能超過8 Kb。(-2是Redis給出的默認值)
-1: 每一個quicklist節點上的ziplist大小不能超過4 Kb。
list-compress-depth 0
這個參數表示一個quicklist兩端不被壓縮的節點個數。
注:這裏的節點個數是指quicklist雙向鏈表的節點個數,而不是指ziplist裏面的數據項個數。
實際上,一個quicklist節點上的ziplist,若是被壓縮,就是總體被壓縮的。
參數list-compress-depth的取值含義以下:
0: 是個特殊值,表示都不壓縮。這是Redis的默認值。
1: 表示quicklist兩端各有1個節點不壓縮,中間的節點壓縮。
2: 表示quicklist兩端各有2個節點不壓縮,中間的節點壓縮。
3: 表示quicklist兩端各有3個節點不壓縮,中間的節點壓縮。
依此類推…
因爲0是個特殊值,很容易看出quicklist的頭節點和尾節點老是不被壓縮的,以便於在表的兩端進行快速存取。
set-max-intset-entries 512
數據量小於等於set-max-intset-entries用intset,大於set-max-intset-entries用set
zset-max-ziplist-entries 128 zset-max-ziplist-value 64
數據量小於等於zset-max-ziplist-entries用ziplist,大於zset-max-ziplist-entries用zset
hll-sparse-max-bytes 3000
value大小小於等於hll-sparse-max-bytes使用稀疏數據結構(sparse)
大於hll-sparse-max-bytes使用稠密的數據結構(dense),一個比16000大的value是幾乎沒用的,
建議的value大概爲3000。若是對CPU要求不高,對空間要求較高的,建議設置到10000左右
activerehashing yes
Redis將在每100毫秒時使用1毫秒的CPU時間來對redis的hash表進行從新hash,能夠下降內存的使用。
當你的使用場景中,有很是嚴格的實時性須要,不可以接受Redis時不時的對請求有2毫秒的延遲的話,把這項配置爲no。
若是沒有這麼嚴格的實時性要求,能夠設置爲yes,以便可以儘量快的釋放內存
client-output-buffer-limit normal 0 0 0
對客戶端輸出緩衝進行限制能夠強迫那些不從服務器讀取數據的客戶端斷開鏈接,用來強制關閉傳輸緩慢的客戶端。
對於normal client,第一個0表示取消hard limit,第二個0和第三個0表示取消soft limit,normal client默認取消限制,由於若是沒有尋問,他們是不會接收數據的
client-output-buffer-limit slave 256mb 64mb 60
對於slave client和MONITER client,若是client-output-buffer一旦超過256mb,又或者超過64mb持續60秒,那麼服務器就會當即斷開客戶端鏈接。
client-output-buffer-limit pubsub 32mb 8mb 60
對於pubsub client,若是client-output-buffer一旦超過32mb,又或者超過8mb持續60秒,那麼服務器就會當即斷開客戶端鏈接。
hz 10
redis執行任務的頻率爲1s除以hz
aof-rewrite-incremental-fsync yes
在aof重寫的時候,若是打開了aof-rewrite-incremental-fsync開關,系統會每32MB執行一次fsync。 這對於把文件寫入磁盤是有幫助的,能夠避免過大的延遲峯值