亚洲香蕉成人av网站在线观看_欧美精品成人91久久久久久久_久久久久久久久久久亚洲_热久久视久久精品18亚洲精品_国产精自产拍久久久久久_亚洲色图国产精品_91精品国产网站_中文字幕欧美日韩精品_国产精品久久久久久亚洲调教_国产精品久久一区_性夜试看影院91社区_97在线观看视频国产_68精品久久久久久欧美_欧美精品在线观看_国产精品一区二区久久精品_欧美老女人bb

首頁 > 數(shù)據(jù)庫 > Redis > 正文

redis2.8配置文件中文翻譯版

2020-10-28 21:40:58
字體:
供稿:網(wǎng)友
# Redis 配置案例#關(guān)于單位,當(dāng)你需要指定內(nèi)存的大小時,可以使用如下的單位來指定#(譯者注,為什么會存在1000為單位,我認為是考慮到硬盤的容量單位是以1000來進行計算而非程序中的1024)#(因此 使用 1000為單位可以進一步地精確估算出所需的實際硬盤容量)## 1k => 1000 bytes# 1kb => 1024 bytes# 1m => 1000000 bytes# 1mb => 1024*1024 bytes# 1g => 1000000000 bytes# 1gb => 1024*1024*1024 bytes## 單位是大小寫不敏感的 所以 1GB 1Gb 1gB 是一樣的################################## INCLUDES #####################################如果你擁有一個標準的配置模板,并且希望在該模板之上坐一些個性化的修改,你可以#使用include 指令來引入其他的配置文件。##注意:"include" 不會被 admin 或者 Redis Sentinel "CONFIG REWRITE" 命令覆蓋。#(譯者注:"CONFIG REWRITE" 是redis 2.8 引入的新命令,用來重寫配置)#由于redis以最終的配置作為實際配置,因此我們希望你將include命令放置在配置文件的最前面#以防配置被覆蓋#如果你打算使用另外的 conf文件來覆蓋當(dāng)前文件的配置,那么最好將include指令放置到該文件的末尾## 即最后生效原則,最后被解析的配置將作為最后的配置## include /path/to/local.conf# include /path/to/other.conf################################ GENERAL ###################################### redis 默認不是以一個守護進程來運行的,使用 yes,可以讓redis作為守護進程來運行# 注意:當(dāng)redis作為守護進程的時候 /var/run/redis.pid 作為 pid 文件#daemonize no# 當(dāng)redis以守護進程運行時,將會使用/var/run/redis.pid作為 pid文件的位置,也就是#上一個指令所說的默認,你可以根據(jù)自己的需要修改它#pidfile /var/run/redis.pid# 在指定的端口上進行監(jiān)聽,默認是 6379# 如果端口設(shè)置為0,那么redis就不會在TCP socket上進行監(jiān)聽# (譯者注:不在tcp socket上進行監(jiān)聽,不代表沒法連接,只是無法使用網(wǎng)絡(luò)連接而已)port 6379# TCP listen() backlog值#(譯者注:backlog值是指目前最大的連接隊列,因為TCP連接是三次握手)#(沒有完成三次握手和尚未被accept的connect都會處于連接隊列中,但是backlog的實際值與操作系統(tǒng)相關(guān))#(并非設(shè)置多少就是多少,只能說調(diào)整得大一些可以在同一時間應(yīng)對更多的連接請求)##在一個并發(fā)量高的環(huán)境中,你需要指定一個比較大的backlog值來避免慢連接(由于網(wǎng)絡(luò)原因握手速度慢)的情況#注意,linux內(nèi)核會默認 使用/proc/sys/net/core/somaxconn 的值來削減 backlog的實際值,#因此你需要確保提升 somaxconn 和 tcp_max_syn_backlog 這兩個值來確保此處的backlog生效#(譯者注:只有 當(dāng)每一個請求都重新發(fā)起一個連接的時候,backlog值的增大才能影響到并發(fā)量)#(在tcp穩(wěn)定連接的時候,或連接復(fù)用(連接池的使用),backlog值對并發(fā)沒有任何影響)#tcp-backlog 511##默認情況下redis會在所有的可用網(wǎng)絡(luò)接口中進行監(jiān)聽,如果你想讓redis在指定的網(wǎng)絡(luò)接口中#監(jiān)聽,那么可以使用bind 命令來指定redis的監(jiān)聽接口#(譯者科普:網(wǎng)絡(luò)的中的服務(wù)是通過 ip+進程 來進行區(qū)分的,當(dāng)一個服務(wù)器擁有兩個ip時 )#(自然就在網(wǎng)絡(luò)中擁有兩個人身份,如 內(nèi)網(wǎng),外網(wǎng),當(dāng)你只想讓redis在一個網(wǎng)絡(luò)上監(jiān)聽時,就可以使用如下的配置)# (127.0.0.1 就是指定只能本機進行網(wǎng)絡(luò)訪問)# 例如:## bind 192.168.1.100 10.0.0.1# bind 127.0.0.1##指定unix sock的路徑來進行連接監(jiān)聽,默認是不指定,因此redis不會在unix socket上進行監(jiān)聽#(譯者注:這個是用來進行進程間通信的時候指定的)# unixsocket /tmp/redis.sock# unixsocketperm 755# 關(guān)閉掉空閑N秒的連接(0則是不處理空閑連接)timeout 0# TCP keepalive.###如果該值不為0,將使用 SO_KEEPALIVE 這一默認的做法來向客戶端連接發(fā)送TCP ACKs ##這樣的好處有以下兩個原因# 1)檢測已經(jīng)死亡的對端(譯者注:TCP的關(guān)閉會存在無法完成4次握手的情況,如斷電,斷網(wǎng),數(shù)據(jù)丟失等等)# 2)保持連接在網(wǎng)絡(luò)環(huán)境中的存活##tcp-keepalive 0# 指定日志的記錄級別的# 可以是如下的幾個值之一# debug (盡可能多的日志信息,用于開發(fā)和測試之中)# verbose (少但是有用的信息, 沒有debug級別那么混亂)# notice (適量的信息,用于生產(chǎn)環(huán)境)# warning (只有非常重要和關(guān)鍵的信息會被記錄)loglevel notice# 指定日志文件的位置. 為空時將輸出到標準輸出設(shè)備# 如果你在demo模式下使用標準輸出的日志,日志將會輸出到 /dev/nulllogfile ""# 當(dāng)設(shè)置 'syslog-enabled'為 yes時, 允許記錄日志到系統(tǒng)日志中。# 以及你可以使用更多的日志參數(shù)來滿足你的要求# syslog-enabled no# 指定在系統(tǒng)日志中的身份# syslog-ident redis# 指定系統(tǒng)日志的能力. 必須是 LOCAL0 到 LOCAL7 之間(閉區(qū)間).# syslog-facility local0#設(shè)置數(shù)據(jù)庫的編號. 默認的數(shù)據(jù)庫是DB 0#使得你可以在每一個連接的基礎(chǔ)之上使用 SELECT <dbid> 來指定另外的數(shù)據(jù)庫,但是這個值必須在 0到 'database'-1之間databases 16################################ SNAPSHOTTING ################################## 保存 DB 到硬盤:##  save <seconds> <changes>##  將會在<seconds> 和 <changes>兩個值同時滿足時,將DB數(shù)據(jù)保存到硬盤中#  其中<seconds> 每多少秒,<changes>是改變的key的數(shù)量##  在以下的例子中,將會存在如下的行為#  當(dāng)存在最少一個key 變更時,900秒(15分鐘)后保存到硬盤#  當(dāng)存在最少10個key變更時,300秒后保存到硬盤#  當(dāng)存在最少1000個key變更時,60秒后保存到硬盤##  提示: 你可以禁用如下的所有 save 行##  你可以刪除所有的save然后設(shè)置成如下這樣的情況####  save ""save 900 1save 300 10save 60 10000## 作為默認,redis會在RDB快照開啟和最近后臺保存失敗的時候停止接受寫入(最少一個保存點)#這會使得用戶察覺(通常比較困難)到數(shù)據(jù)不會保持在硬盤上的正確性,否則很難發(fā)現(xiàn)#這些災(zāi)難會發(fā)生## 如果后臺保存程序再次開始工作,reidis會再次自動允許寫入##然而如果對redis服務(wù)器設(shè)置了合理持續(xù)的監(jiān)控,那么你可以關(guān)閉掉這個選項。#這會導(dǎo)致redis將繼續(xù)進行工作,無論硬盤,權(quán)限或者其他的是否有問題##stop-writes-on-bgsave-error yes# 是否在dump到 rdb 數(shù)據(jù)庫的時候使用LZF來壓縮字符串# 默認是 yes,因為這是一個優(yōu)良的做法## 如果你不想耗費你的CPU處理能力,你可以設(shè)置為 no,但是這會導(dǎo)致你的數(shù)據(jù)會很大rdbcompression yes# 從RDB的版本5開始,CRC64校驗值會寫入到文件的末尾#這會使得格式化過程中,使得文件的完整性更有保障,但是這會在保存和加載的時候損失不少的性能(大概在10%)#你可以關(guān)閉這個功能來獲得最高的性能##RDB文件會在校驗功能關(guān)閉的時候,使用0來作為校驗值,這將告訴加載代碼來跳過校驗步驟rdbchecksum yes# DB的文件名稱dbfilename dump.rdb# 工作目錄.## DB將會使用上述 'dbfilename'指定的文件名寫入到該目錄中# # 追加的文件也會在該目錄中創(chuàng)建# # 注意,你應(yīng)該在這里輸入的是一個目錄而不是一個文件名dir ./################################# REPLICATION ################################## 主從復(fù)制。使用 slaveof 命令來 指導(dǎo)redis從另一個redis服務(wù)的拷貝中來創(chuàng)建一個實例##注意:這個配置是主從結(jié)構(gòu)的從(主從結(jié)構(gòu)的從,怎么那么拗口呢)redis的本地配置##如下例子,這個配置指導(dǎo) slave (從redis) 通過另一個redis的實例的ip和端口號來獲取DB數(shù)據(jù)#### slaveof <masterip> <masterport>## 如果主服務(wù)器開啟了密碼保護(使用下面的"requirepass"配置)# 這個配置就是告訴從服務(wù)在發(fā)起向主服務(wù)器的異步復(fù)制的請求之前使用如下的密碼進行認證,#否則主服務(wù)器會拒絕這個請求#### masterauth <master-password>## 如果從服務(wù)器失去了和主服務(wù)器之間的連接,或者當(dāng)復(fù)制仍然處于處理狀態(tài)的時候# 從服務(wù)器做出如下的兩個行為## 1)如果 slave-serve-stale-data 被設(shè)置為 yes(默認值),從服務(wù)器將會持續(xù)# 回復(fù)來自客戶端的請求,可能會回復(fù)已經(jīng)過期的數(shù)據(jù),或者返回空的數(shù)據(jù),當(dāng)從服務(wù)器第一次異步請求數(shù)據(jù)時。## 2)如果 slave-serve-stale-data 被設(shè)置為 no ,從服務(wù)器就會返回"SYNC with master in progress"# 這個錯誤,來應(yīng)答所有命令除了 INFO 和 SLAVEOF#slave-serve-stale-data yes### 你可以配置一個從服務(wù)器的實例是否接受寫請求,# 從服務(wù)器在存儲一些短暫的數(shù)據(jù)的的時候,接收寫請求是一件非常正確的事情# (因為數(shù)據(jù)在向主服務(wù)器同步之后非常容易擦除)但是會因為配置不正確而導(dǎo)致一些問題## 從redis 2.6開始默認從服務(wù)器是只讀的服務(wù)器####提示:只讀的從服務(wù)器并不是設(shè)計用來公開給不受信任的互聯(lián)網(wǎng)客戶端的,它#僅僅是一個用來防止對實例進行誤操作的保護層。只讀從服務(wù)器默認用來輸出管理命令#例如 CONFIG, DEBUG 和其他。如果你想限制它的規(guī)模,你可以使用'rename-command'來#提高它的安全性,使得她作為一個影子來執(zhí)行管理或者危險的命令##slave-read-only yes# 從服務(wù)器在預(yù)設(shè)的間隔中發(fā)送送一個ping到目標服務(wù)器。你可以通過修改repl-ping-slave-period#的值來修改它,默認是10秒鐘### repl-ping-slave-period 10# repl-timeout設(shè)置了以下的復(fù)制超時值:## 1) 在從服務(wù)器中,使用同步IO進行大規(guī)模傳輸.# 2) 在從服務(wù)器中,主服務(wù)器的超時(ping,數(shù)據(jù))# 3) 在主服務(wù)器中. 從服務(wù)器的超時(對pings的響應(yīng))### 確保這個值大于 指定的repl-ping-slave-period 值,否則當(dāng)主從之間是低流量時# 會檢測到超時的情況## repl-timeout 60# 在從服務(wù)器同步之后是否關(guān)閉TCP_NODELAY?### 如果你選擇 "yes",redis將會使用一個很小的TCP包和很小的帶寬來向從服務(wù)器發(fā)送數(shù)據(jù)。# 如果使用默認的設(shè)置這會增加數(shù)據(jù)復(fù)制到從服務(wù)器之間的延遲。如果使用默認配置的linux內(nèi)核# 這個延遲會高達到40毫秒###如果你選擇 "no",數(shù)據(jù)復(fù)制到從服務(wù)器將會減少延遲,但是會使用更多的帶寬。##作為默認我們?yōu)榈脱舆t進行優(yōu)化,但是在一個高流量的情況下或者當(dāng)主服務(wù)器和從服務(wù)器#有很多hops的時候,將該值設(shè)置為yes會更好# (譯者注:這就是一個網(wǎng)絡(luò)調(diào)優(yōu)的問題,默認的TCP內(nèi)核會使用Nagle,即將小的數(shù)據(jù)包合并成大的數(shù)據(jù)包(及yes的情況))# (在等待合并的過程種,肯定會存在等待后續(xù)數(shù)據(jù)的步驟,因此這會導(dǎo)致數(shù)據(jù)的延遲)# (yes,就是使用TCP的默認情況開啟Nagle算法,no就是關(guān)閉Nagle算法)repl-disable-tcp-nodelay no###設(shè)置復(fù)制的backlog值。(這個backlog和tcp中的backlog不一樣)##這個backlog值是一個緩沖區(qū),當(dāng)從服務(wù)器斷開連接之后,主服務(wù)器將更新的數(shù)據(jù)放置#在這個緩沖區(qū)中,因為當(dāng)從服務(wù)重新連接上來時候不是所有的數(shù)據(jù)都需要同步,因此從這個#緩沖區(qū)中取數(shù)據(jù)就可以同步到和主服務(wù)器一樣的狀態(tài)###這個值設(shè)置得越大,從服務(wù)器的掉線時間就可以越長,上線后就可以進行局部更新#(譯者注:當(dāng)?shù)艟€時間過長而無法進行局部更新,那么從服務(wù)器就會再一次進行同步所有的數(shù)據(jù),耗時和當(dāng)時的數(shù)據(jù)量成正比)#當(dāng)且僅當(dāng)?shù)谝粋€從服務(wù)器連接到服務(wù)器之后這個緩存才會被分配## repl-backlog-size 1mb## # 當(dāng)從服務(wù)器在長時間內(nèi)沒有連接到主服務(wù)器時,backlog的緩存將會被釋放。# 以下的選項就是自 從服務(wù)器最后一次斷掉和主服務(wù)器之間的# 連接開始N秒后清空backlog的緩存## 設(shè)置為0意味著永遠不會清空backlog## repl-backlog-ttl 3600### 在redis的信息輸出中我們使用一個整型值來表示從服務(wù)器的優(yōu)先值##這個優(yōu)先級的作用是,在主從結(jié)構(gòu)種,當(dāng)主服務(wù)器不能正常工作的時候時候,#將一個從服務(wù)器提升為主服務(wù)器,提升的依據(jù)就是這個值。## 假設(shè)又三個 優(yōu)先級分別為 25 10 100 的服務(wù)器,將優(yōu)先將數(shù)值最少的提升為主服務(wù)器# 即最小值優(yōu)先# 如果優(yōu)先級設(shè)置為0,意味著將不會又機會成為主服務(wù)器# 默認優(yōu)先級是100slave-priority 100## 下面的值用來設(shè)置主服務(wù)器停止接受寫入事件的情況。# 如果從服務(wù)器的連接小于N # 從服務(wù)器的數(shù)據(jù)落后 小于等于M秒# # N個從服務(wù)器必須是在線的狀態(tài)## lag的單位是秒,它必須 <=指定的值,它從最后一次收到ping包的時間開始計算。 # 通常ping包都是每秒發(fā)送一次### 這個選項并不擔(dān)保N個副本都會接受寫入,但是會確保在指定的時間沒有足夠的從服務(wù)可用的時候# 窗口上顯示丟失寫入### 例如要求最少三個從服務(wù)器在lag<=10秒## min-slaves-to-write 3# min-slaves-max-lag 10## 設(shè)置任意一個為0都會導(dǎo)致關(guān)閉這項特性## 默認min-slaves-to-write 設(shè)置為0(關(guān)閉這個特性)# min-slaves-max-lag 設(shè)置為10################################## SECURITY ##################################### 要求客戶端在處理其他指令之前先發(fā)起AUTH <PASSWORD>## 這在你不信任其他的接入主機上的redis-server是比較有用## 這個選項應(yīng)當(dāng)注釋掉來保證向后的兼容性,畢竟大部分的人都不需要鑒權(quán)驗證(因為他們都運行自己的sever)## #注意,由于redis太快,所以每秒鐘可以嘗試150K次密碼,因此你應(yīng)該設(shè)置一個#非常強壯的密碼來防止別人的破解## requirepass foobared# 命令重命名.### 它用來改變共享環(huán)境中危險命令的名字,在這個例子中# CONFIG 命令被重命名為一個難以猜解的名字。# 這會對內(nèi)部用戶的工具有效,但是對一般的客戶端無效。## Example:## rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52### 可以使用一個空字符串來抹殺這個命令## rename-command CONFIG ""## 請注意,改變記錄在AOF文件中的命令名稱或者傳輸?shù)綇姆?wù)會導(dǎo)致問題# AOF file or transmitted to slaves may cause problems.################################### LIMITS ###################################### 設(shè)置同一時間的客戶端最大連接數(shù),默認的限制是10000個客戶端。#然而如果redis服務(wù)不設(shè)置這個限制值那么最大的用戶數(shù)就是最大文件描述符數(shù)-32.###一旦連接的用戶數(shù)超出了限制值,redis將會關(guān)閉新的連接并且發(fā)送 'max number of client reached'## maxclients 10000# 不使用超出指定大小的內(nèi)存,#當(dāng)redis使用到的內(nèi)存達到限定值的時候,將會根據(jù)淘汰策略試圖移除一部分key### 如果根據(jù)相關(guān)策略無法移除key,或者策略被設(shè)置為 'noeviction',redis將會對#使用到內(nèi)存的命令返回錯誤,比如 SET LPUSH等,并且進入只讀模式僅僅響應(yīng)只讀的命令如GET## 這個選項在你將redis當(dāng)做一個LRU緩存和設(shè)置一個內(nèi)存大小限制的時候十分有用。#### 警告:如果你的從服務(wù)器關(guān)聯(lián)到一個有最大內(nèi)存限制的redis實例上,# # 主服務(wù)器向從服務(wù)器輸出的緩存屬于被該服務(wù)器使用的內(nèi)存的一部分。#因此 網(wǎng)絡(luò)問題和重新同步引發(fā)的復(fù)制,不會觸發(fā)淘汰key的循環(huán),##反過來,從服務(wù)器的輸出緩存將會被觸發(fā)淘汰的DEL key,直到數(shù)據(jù)庫清空####簡單來說,如果你擁有一個從服務(wù)器,我們建議你將這個值#設(shè)置為少于系統(tǒng)可用的最大內(nèi)存,以便系統(tǒng)可以騰出空間來安放#從服務(wù)器的輸出緩存(但是如果策略是noeviction 那就沒這個必要)## maxmemory <bytes># 最大內(nèi)存策略: 當(dāng)redis使用的內(nèi)存達到指定的最大值時,你可以使用如下的5種# 策略來應(yīng)對這種情況## volatile-lru -> 使用LRU算法依據(jù)過期時間來移除key# allkeys-lru -> 使用LRU算法來移除任何key# volatile-random -> 根據(jù)過期時間設(shè)置隨即移除key# allkeys-random -> 隨即移除任何一個key# volatile-ttl -> 移除一個最近過期時間的key# noeviction -> 所有key用不過期(即不移除任何key),對于任何寫操作都返回一個錯誤信息# # 提示: 在以上的所有策略中,當(dāng)不存在一個key滿足以上的淘汰策略時(即無法空出內(nèi)存時)# 任何寫操作都會返回錯誤信息##    目前為止具有寫入操作的指令是: set setnx setex append#    incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd#    sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby#    zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby#    getset mset msetnx exec sort## 默認值為:## maxmemory-policy volatile-lru## LRU和最小TTL算法都不是精確的算法,但是是近似的算法,#因此你可以選擇一些樣本大小來進行測試,對于一個默認的redis實例#將會選選擇3個key,并且挑選其中之一作為最近最少的Key,你可以使用如下參數(shù)修改例子的數(shù)量大小### maxmemory-samples 3############################## APPEND ONLY MODE ################################ Redis默認使用異步存儲數(shù)據(jù)到硬盤上.## 這個模式非常合適一些應(yīng)用,但是當(dāng)redis的進程出現(xiàn)問題# 或者停電的時候,會丟失一些寫入的數(shù)據(jù)(丟失的多少根據(jù)保存點的設(shè)置)## # Append Only 文件(Append Only file),是一個備選的持久化模型,# 它提供了更好的續(xù)航能力,對于一個使用默認數(shù)據(jù)同步文件策略的實例#redis可能會因為一個戲劇性的災(zāi)難比如停電等丟失一秒鐘的數(shù)據(jù)##或者由于redis進程本身的錯誤僅僅寫入一個數(shù)據(jù),但操作系統(tǒng)一直運行#### AOF和RDB可以毫無問題地共存,因此你可以同時開啟他們,# # 如果你開啟了AOF,redis會在啟動時加載AOF,因為AOF有更好的魯棒性## 你可以從 http://redis.io/topics/persistence 獲取更多的信息appendonly no# append only file 的名稱 (默認是: "appendonly.aof")appendfilename "appendonly.aof"# fsync() 調(diào)用告訴操作系統(tǒng)立即將數(shù)據(jù)寫入到硬盤中,而不是寫入到輸出緩沖區(qū)# 等待足夠的數(shù)據(jù)再寫入。一些操作系統(tǒng)會立即將數(shù)據(jù)寫入到硬盤中,一些其他的#操作系統(tǒng)則只是盡可能快地將數(shù)據(jù)寫入硬盤中## # Redis支持三種不同的模式:## no:不進行強制同步,僅僅讓操作系統(tǒng)根據(jù)自身的決策寫入到硬盤中。這種速度更快 # always:在每一次追加寫入操作都采用強制同步,特點是慢,安全。# everysec:每間隔一秒鐘強制同步數(shù)據(jù)。折中的方案### 默認采用 "everysec"作為速度和安全性之間的平衡方案# 你將根據(jù)自己的需求決定采用更快的方案或者更安全的方案。# 選擇no,何時寫入數(shù)據(jù)將由操作系統(tǒng)決定,你可以由此獲取最快的速度# 選擇always,數(shù)據(jù)將立即寫入到硬盤中,你可以獲得更高的數(shù)據(jù)安全性## 更多的信息可以從以下地址中獲取:# http://antirez.com/post/redis-persistence-demystified.html## 如果不開啟該選項默認使用"everysec".# appendfsync alwaysappendfsync everysec# appendfsync no### 當(dāng)AOF的強制寫入策略設(shè)置為 always 或者 everysec,并且一個后臺保存進程#(一個后臺保存進程或者 AOF 日志后臺重寫)會占用硬盤的大量I/O資源,在一些linux# 的配置中redis會因為 fsync() 調(diào)用而長期鎖定。特別的是在目前我們沒法解決這個問題# 即使采用另外的線程來運行強制同步也會鎖定住我們的 同步 write(2)調(diào)用## 為了減輕這個問題,下面的選項將會在GBSAVE 或者BGREWRITEAOF運行時# 預(yù)防主進程調(diào)用fsync()## 這意味著當(dāng)另一個 子進程在保存的時候,Redis的保存策略將處于"appendfsync none"這樣的類似狀態(tài)# 在實際應(yīng)用當(dāng)中,這意味著在最壞的情況下將會失去30秒的日志(使用linux默認的設(shè)置)## # 如果你采用yes,那么將會存在一個潛在的隱患,不然請設(shè)置它為 "no",# 這是一個為了穩(wěn)定的安全性選擇#no-appendfsync-on-rewrite no# 自動改寫append only 文件.## redis會在AOF日志文件增長到指定百分比的時候通過調(diào)用BGREWRITEAOF來自動重寫日志文件# # 他是這樣工作的:redis會記住最后一次改寫后AOF文件的大小(如果重寫自重啟以來#尚未發(fā)生,那么AOF文件的大小就是啟動以來使用的大小)### 這個基準值將會和當(dāng)前值進行比較,如果當(dāng)前值比設(shè)定的百分比還要大,重寫事件就會發(fā)生。## 并且你需要指定一個AOF重寫的最小值,這用來避免當(dāng)重寫文件的百分比增長符合目標# 但是整個文件依然很小的時候### 將 auto-aof-rewrite-percentage 設(shè)置為0則可以關(guān)閉掉AOF自動重寫的功能#auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb################################ LUA SCRIPTING ################################ 以毫秒為單位限定lua腳本的最大執(zhí)行時間.### 當(dāng)lua腳本在超出最大允許執(zhí)行時間之后,redis會記錄下這個腳本到日志中,#并且會向這個請求返回error的錯誤#### 僅當(dāng) SCRIPT KILL 和 SHUTDOWN NOSAVE 命令可用的時候# 一個運行時間超過最大限定時間的腳本才會繼續(xù)執(zhí)行# SCRIPT KILL用來停止一個沒有調(diào)用寫入命令的腳本# 當(dāng)用戶不想等待腳本的自然中止但腳本又在進行寫操作的時候# 采用 SHUTDOWN NOSAVE 是解決這個問題的唯一辦法,他可以立即停掉整個腳本### 設(shè)置為0 或者一個負數(shù)來取消時間限定.lua-time-limit 5000################################## SLOW LOG #################################### # slow log(慢日志)用來記錄執(zhí)行時間超過指定值的查詢。# 執(zhí)行時間不包含 I/O操作,比如和客戶端交互,發(fā)送應(yīng)答等等# 僅僅是執(zhí)行命令的真實時間,(僅僅是線程因為執(zhí)行這個命令而鎖定且無法處理其他請求的階段)### 你可以使用兩個參數(shù)來配置 slow log,一個是以微秒為單位的命令執(zhí)行時間值,# 另一個是slow log 的長度(即記錄的最大數(shù)量)# 當(dāng)一個新的命令被記錄到slow log的時候,最舊的一條記錄將會被移除。### 下面的值將會被解釋為 微秒 為單位,所以 1000000 微秒為 1秒# # 將這個值設(shè)置為一個負數(shù),將關(guān)閉掉slow log ,如果設(shè)置為0,則記錄所有的命令#(默認是10毫秒)slowlog-log-slower-than 10000# 因為這會消耗內(nèi)存,因此實際上并不是限制到這個長度.# 你可以使用 SLOWLOG RESET來回收占用的內(nèi)存slowlog-max-len 128################################ LATENCY MONITOR ################################ redis延遲監(jiān)控子系統(tǒng)例子與操作系統(tǒng)收集的redis實例相關(guān)的數(shù)據(jù)不同## 通過LATENCY命令,可以為用戶打印出相關(guān)信息的圖形和報告##這個系統(tǒng)只會記錄運行時間超出指定時間值的命令,如果設(shè)置為0,這個監(jiān)控將會被關(guān)閉### 默認的情況下,延遲監(jiān)控是關(guān)閉,因為如果你沒有延遲的問題大部分情況下不需要#,并且收集數(shù)據(jù)的行為會對性能造成影響,雖然這個影響很小可以在大負荷下工作# #延遲監(jiān)控可以使用如下命令來打開## "CONFIG SET latency-monitor-threshold <milliseconds>".latency-monitor-threshold 0############################# Event notification ###############################redis 可以在key 空間中采用發(fā)布訂閱模式來通知事件的發(fā)生##這個功能的文檔可以查看 http://redis.io/topics/keyspace-events# ##對于一個實例,如果鍵空間事件通知是啟用狀態(tài),當(dāng)一個客戶端執(zhí)行在一個#存儲在Database 0名為"foo"的key的DEL(刪除)操作時,#有如下兩條信息將會通過發(fā)布訂閱系統(tǒng)產(chǎn)生### PUBLISH __keyspace@0__:foo del# PUBLISH __keyevent@0__:del foo### 以下是可選的redis事件通知,每個類別的事件可以由一個字符進行描述## K   Keyspace events, published with __keyspace@<db>__ prefix.# E   Keyevent events, published with __keyevent@<db>__ prefix.# g   Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...# $   String commands# l   List commands# s   Set commands# h   Hash commands# z   Sorted set commands# x   Expired events (events generated every time a key expires)# e   Evicted events (events generated when a key is evicted for maxmemory)# A   Alias for g$lshzxe, so that the "AKE" string means all the events.## The "notify-keyspace-events" takes as argument a string that is composed# by zero or multiple characters. The empty string means that notifications# are disabled at all.## 例子1: 啟用 list 和 generic 事件, ## notify-keyspace-events Elg## 例子2 2: 要想訂閱通道名為__keyevent@0__:expired 上expired keys的事件:## notify-keyspace-events Ex### 默認不啟用所有的通知,因為大部分的用戶不需要這些功能,而且這些功能會帶來一些開銷## 如果你沒有指定 K 或者 E,沒有事件會被傳遞#notify-keyspace-events ""############################### ADVANCED CONFIG #################################創(chuàng)建空白哈希表時,程序默認使用 REDIS_ENCODING_ZIPLIST 編碼,當(dāng)以下任何一個條件被滿#足時,程序?qū)⒕幋a從切換為 REDIS_ENCODING_HT#哈希表中某個鍵或某個值的長度大于 server.hash_max_ziplist_value (默認值為 64)。#壓縮列表中的節(jié)點數(shù)量大于 server.hash_max_ziplist_entries (默認值為 512 )。## ziplist是一個解決空間的緊湊的數(shù)據(jù)存儲結(jié)構(gòu),但是當(dāng)數(shù)據(jù)超過閾值時,將采用原生的數(shù)據(jù)存儲結(jié)構(gòu)##hash-max-ziplist-entries 512hash-max-ziplist-value 64## 與hash表類似,#list-max-ziplist-entries 512list-max-ziplist-value 64## 設(shè)置特殊編碼的唯一情況:# 當(dāng)一個set僅僅由一個基數(shù)為10最大位數(shù)為64位的有符號整形的字符串構(gòu)成的時候##以下配置設(shè)置了set的限制大小,當(dāng)小于這個值的時候?qū)褂靡粋€更緊湊的數(shù)據(jù)結(jié)構(gòu)來保存#以期減少內(nèi)存占用#set-max-intset-entries 512## 與hash和list類似 zsort也采用如下的配置來選擇是否進行特殊編碼來節(jié)省空間#zset-max-ziplist-entries 128zset-max-ziplist-value 64## HyperLogLog 稀疏表示字節(jié)限制# 這個限制包含了16個字節(jié)的頭部,當(dāng)一個HyperLogLog使用sparse representation# 超過了這個顯示,它就會轉(zhuǎn)換到dense representation上# #hll-sparse-max-bytes 3000## active rehashing使用CPU時間的每100毫秒中的1毫秒來進行rehashing工作# 來rehash redis的主hash表(rehash的時候在代碼種引入記時來保證)## lazy rehashing :逐步hash,每一次添加查找刪除進行一次rehash的步驟# 又稱惰性hash# # 因為hash的再散列會導(dǎo)致整個進程的stop,為了避免長時間的stop,以上的策略都是在分散整個# rehash的過程(參照《redis設(shè)計與實現(xiàn)》的字典部分)#activerehashing yes## 客戶端輸出緩沖區(qū)顯示可以用來解決由于某些原因?qū)е碌膹娭茢嗑€# 而造成的不能讀到足夠的數(shù)據(jù)# 一個比較常見的原因是發(fā)布訂閱模式種,客戶端不能足夠快速地消費發(fā)布者生產(chǎn)的信息## 這個限制可以設(shè)置為如下的三種類型:## normal -> 正常普通的客戶端,包含監(jiān)控客戶端# slave -> 主從服務(wù)器的從客戶端# pubsub -> 訂閱了最少一個頻道的客戶端## 每一個 client-output-buffer-limit 格式如下:## client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>#### 在兩種情況下服務(wù)器認為客戶端不是意外臨時掉線# # 1.緩沖區(qū)的數(shù)據(jù)達到硬限制# 2.緩沖區(qū)的數(shù)據(jù)達到軟限制,同時時間超過了指定值## 因為一個客戶離線,有可能是臨時性的網(wǎng)絡(luò)故障,或者傳輸問題# 也有可能是永久性離線 或者強制性離線,此時服務(wù)器將不會保留他的緩存數(shù)據(jù)# 以下的設(shè)置就是為了判斷這一情況的#### 硬限制和軟限制都可以通過將其設(shè)置為0來關(guān)閉掉client-output-buffer-limit normal 0 0 0client-output-buffer-limit slave 256mb 64mb 60client-output-buffer-limit pubsub 32mb 8mb 60## redis會按照一定的頻率來處理諸如 關(guān)閉超時連接,清理沒有被使用的過期key等等此類后臺任務(wù)## 并不是所有的任務(wù)都以相同的頻率來執(zhí)行的,redis通過一個hz的值來決定處理這些(如上所述的后臺任務(wù))任務(wù)的頻率### 提高這個值會使用更多的cpu時間來在redis閑置的時候處理以上的,但是以此同時# 超時的連接的處理和過期key的清理則會更精確## hz的取值范圍在1到500,不建議設(shè)置為超過100的值,默認是10hz 10## 當(dāng)子進程重寫AOF文件的時候,以下選項將會允許等到存在32MB數(shù)據(jù)的時候才調(diào)用強制同步# 這樣可以降低IO上的延遲#aof-rewrite-incremental-fsync yes

發(fā)表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發(fā)表
中文字幕一区二区三区四| 呦呦视频在线观看| 精品一区免费av| 影音先锋日韩有码| 成人午夜天堂| 免费三片60分钟| 中文字幕亚洲字幕| 视频一区二区在线播放| 丝袜美腿中文字幕| 日韩亚洲成人av在线| 欧美夫妇交换xxx| 欧美日韩国产综合草草| 欧美人牲a欧美精品| 午夜精品久久久久久久99水蜜桃| 欧在线一二三四区| 国产91网红主播在线观看| 亚洲一区二区三区四区五区中文| 樱桃国产成人精品视频| 久久婷婷五月综合色国产香蕉| 精品久久国产97色综合| 久久综合网络一区二区| 啦啦啦中文在线观看日本| 1区1区3区4区产品乱码芒果精品| 精品久久久久久久久久久久久久久久| av亚洲精华国产精华精华| 97超视频在线观看| 你懂的视频网站| 成人在线视频www| 91性高潮久久久久久久| 日本老熟妇毛茸茸| 日韩免费小视频| 亚洲欧洲精品一区二区| 亚洲永久免费精品| 999日本视频| 欧美freesex黑人又粗又大| 在线视频三区| 老司机2019福利精品视频导航| 91成人在线视频观看| 成人网18免费网站在线| 天堂аⅴ在线地址8| 一本久久精品一区二区| 欧美男女性生活在线直播观看| 18深夜在线观看免费视频| 欧美极品少妇xxxxⅹ喷水| 最新国产露脸在线观看| 亚洲午夜久久久久中文字幕| www.亚洲免费视频| 91偷拍与自偷拍精品| 亚洲色图偷拍自拍| 久久免费大视频| 性高潮视频在线观看| 欧美精品亚洲精品日韩精品| 91久久久久久久久久久久| 国产探花在线播放| 97精品国产99久久久久久免费| 高清电影一区| 777片理伦片在线观看| 亚洲欧洲成视频免费观看| 欧美日韩在线精品一区二区三区激情综| 免费毛片在线看片免费丝瓜视频| 妖精视频在线观看| 日本a一级在线免费播放| 亚洲一区二区欧美日韩| 国产福利a级| 97dyy97影院理论片在线| 成人公开免费视频| 日本一区二区三区四区在线观看| 国产精品一区二区三区在线免费观看| 欧美日韩不卡中文字幕在线| jizz国产免费| 日韩一二在线观看| 毛片在线播放网址| eeuss影院在线播放| 欧美日韩在线看| 91精品婷婷国产综合久久性色| 亚洲色图另类小说| 国产午夜亚洲精品不卡| 潘金莲一级淫片aaaaaaa| 在线日本高清免费不卡| 日本中文字幕在线看| 午夜免费福利视频在线观看| 午夜精品一区二区在线观看的| 独立日3在线观看完整版| 亚洲一本大道在线| 人妻丰满熟妇aⅴ无码| 99精品欧美一区二区三区| 成熟丰满熟妇高潮xxxxx视频| 真实乱视频国产免费观看| 婷婷在线观看视频| 久久国产成人| 欧洲一区二区视频| 成人羞羞国产免费图片| 欧美色图校园春色| melody高清在线观看| 中国黄色一级视频| 黄色福利在线观看| 精品视频在线播放色网色视频| 一个人看的www片免费高清视频| 99ri国产在线| 亚洲成人在线观看视频| 国产亚洲精品91在线| 婷婷久久久久久| 国产精品偷伦一区二区| 麻豆网在线观看| 欧美gvvideo网站| 日韩精品一区二区三区视频在线观看| √资源天堂中文在线| 国产日本欧美在线| 色综合久久88色综合天天6| 欧美亚洲免费| 国产高清久久久久| 国内精品麻豆美女在线播放视频| 亚洲欧美国产精品专区久久| 日本精品国产| 91在线观看视频| 国产一区在线电影| 国产精品一二三视频| 国产精品久久久久久久久久直播| 精品熟女一区二区三区| 性欧美一区二区| 免费观看成人在线视频| 一根才成人网| 日本中文字幕伦在线观看| 亚洲无av在线中文字幕| 国产精品国内视频| 免费观看的av| 18欧美乱大交hd1984| 久久影院理伦片| 免费观看一二区视频网站| 欧美国产成人精品一区二区三区| 亚洲xxxx在线| 欧美日韩中文国产| 精品欧美日韩精品| 精品国产精品国产偷麻豆| 色综合久久中文字幕综合网小说| 成人av网站在线播放| а_天堂中文在线| 久久久久国产精品厨房| 欧美高清不卡在线| 波多野结衣家庭主妇| 91一区二区在线观看| 韩国久久久久久| 热99精品只有里视频精品| 影音先锋中文字幕在线| 国产aⅴ精品一区二区三区久久| 精品国产aⅴ麻豆| 欧美一级黄色网| 一区一区三区| 97视频免费在线观看| 一级成人黄色片| 青青草视频社区| 午夜影院观看视频免费| 国产这里有精品| 久久亚洲无码视频| 人与牲动交xxxxbbbb高清| 潘金莲一级淫片aaaaaa播放1| 欧美成人福利视频| 另类天堂av| 久草成色在线| 69久久夜色精品国产69乱青草| 天天色天天综合| 99蜜月精品久久91| 麻豆一区二区在线观看| 国产精品网站在线看| 精品国产老师黑色丝袜高跟鞋| 久久精品2019中文字幕| 日韩午夜免费| 成人在线视频播放| 亚洲国产最新| 91aaaa| av手机在线播放| 老司机精品福利在线观看| 午夜精品久久99蜜桃的功能介绍| 亚洲影院高清在线| 最新97超碰在线| 免费中文字幕日韩欧美| 国产美女福利视频| 欧美综合亚洲图片综合区| 国产真人真事毛片视频| 在线一区二区三区| 蜜桃91丨九色丨蝌蚪91桃色| 538国产精品视频一区二区| 欧美专区视频| 在线成人综合色一区| www黄com| 成人免费图片免费观看| av电影在线观看一区二区三区| 亚洲精品日韩专区silk| 女同互添互慰av毛片观看| 亚洲国产高潮在线观看| √天堂8在线网| 欧美日韩一区 二区 三区 久久精品| 免费国产亚洲视频| 成年人网站国产| 亚洲久久久久久久久久| 欧美激情精品久久久久久久变态| 亚洲五码中文字幕| 性欧美暴力猛交另类hd| 2020国产精品自拍| 一区二区三区韩国免费中文网站| 国内伊人久久久久久网站视频| 波多野结衣一区二区三区在线观看| www.com.cn成人| 懂色av.com| 久久午夜夜伦鲁鲁一区二区| 免费看成一片| www.国产视频| 韩国中文免费在线视频| 欧美日韩精品一区二区三区蜜桃| 99riav1国产精品视频| 在线观看成年人视频| 国产精品乱看| 日韩成人精品| 久久五月情影视| 欧美高清视频不卡网| 国产成人aa精品一区在线播放| 久久久久综合网| 137大胆人体在线观看| 青青草视频在线免费播放| 久草免费资源站| 狠狠久久伊人| 中文字幕成人av| 中文字幕有码热在线视频| 欧美毛片在线观看| 亚洲精品一区二区在线| 欧美久久久久久久久中文字幕| 国产精品资源网站| 欧美日韩国产一级二级| 在线一区av| 青娱乐国产在线视频| 亚洲人成小说| 亚洲第一导航| 国产精品成人av性教育| 欧美色老头old∨ideo| jizzjizz免费| 精品人妻一区二区三区免费| 在线观看国产91| 成人福利电影精品一区二区在线观看| 国产毛片毛片毛片毛片毛片| av在线天堂网| 超碰成人在线免费| 无遮挡爽大片在线观看视频| 日韩午夜视频在线| 亚洲永久无码7777kkk| 日本精品视频| 亚洲一区二区三区久久| 国产精品欧美一区喷水| 波多野结衣亚洲| 亚洲国产精品久久久久久久| 懂色av粉嫩av浪潮av| 亚洲熟妇无码久久精品| 蜜桃av.网站在线观看| 美女欧美视频在线观看免费| 678五月天丁香亚洲综合网| 欧美日韩精品免费观看视一区二区| 精品卡1卡2卡三卡免费网站| 在线影院国内精品| 日本理论片2828理论片| 永久看片925tv| 中文字幕无码不卡免费视频| 亚洲欧洲激情在线乱码蜜桃| 国产精品日日摸夜夜摸av| 综合欧美亚洲日本| 922tv免费观看在线| 99久久99久久免费精品小说| 一区二区自拍偷拍| 日韩精品一级中文字幕精品视频免费观看| 国产精品国产三级国产aⅴ浪潮| 在线播放一区二区三区| 成人免费大片黄在线播放| 亚洲国产日韩在线人成电影| 久久久国内精品| 成人国产电影在线观看| 在线观看成人av| 亚洲人成网站精品片在线观看| 日韩视频在线观看免费视频| 亚洲一区二区三区四区| 中文字幕久久av| 91久久精品无嫩草影院| 日韩精品一区二区三区av| 中文字幕亚洲精品一区| 色屁屁www国产馆在线观看| 日韩精品一区二区三区中文精品| 国产在线一区二区三区播放| 亚洲精品乱码久久久久久蜜桃图片| 亚洲天天影视| 欧美高清在线视频| 成人短视频app| eeuss影院在线播放| 精品国产一区二区在线| 亚洲美女动态图120秒| 亚洲欧美欧美一区二区三区| 国产高潮流白浆喷水视频| 无码人妻丰满熟妇区五十路百度| 国产一区二区三区视频免费| 国产精品av在线播放| 538精品在线观看| 99国产精品免费视频观看| www.免费av| 欧美在线一级va免费观看| 美女久久久久久久久久久| 国产美女精品久久| 国产在线不卡一区二区三区| 99久久99精品久久久久久| 国精品人伦一区二区三区蜜桃| 久草在线中文888| 夜间精品视频| 一区二区三区视频观看| 亚洲精品传媒| 91精品国自产在线| 26uuu精品一区二区在线观看| 亚洲综合在线中文字幕| 蜜桃视频污在线观看| 一个色综合av| 中文字幕一区二区三区在线观看| 一本不卡影院| 亚洲福利一区二区三区| 日韩极品视频在线观看| 在线观看视频免费一区二区三区| 五月天一区二区| 色综合影院在线观看| 丝袜美腿诱惑一区二区三区| 国产乱人乱偷精品视频a人人澡| 黄色在线播放| 丁香啪啪综合成人亚洲小说| eeuss影院第1页在线| 亚洲欧洲高清在线| 亚洲久久视频|