關於redis性能問題分析和優化

 

1、如何查看Redis性能

info命令輸出的數據能夠分爲10個分類，分別是：

server,clients,memory,persistence,stats,replication,cpu,commandstats,cluster,keyspace

爲了快速定位並解決性能問題，這裏選擇5個關鍵性的數據指標，它包含了大多數人在使用Redis上會常常碰到的性能問題

2、內存

上圖中used_memory 字段數據表示的是：由Redis分配器分配的內存總量，以字節（byte）爲單位。 其中used_memory_human和used_memory是同樣的，以G爲單位顯示

1 2 3 4 5 6 7 8 9 10

info memory # Memory used_memory:8589645288 used_memory_human:8.00G used_memory_rss:9439997952 used_memory_peak:9082282776 used_memory_peak_human:8.46G used_memory_lua:35840 mem_fragmentation_ratio:1.10 mem_allocator:jemalloc-3.6.0

used_memory是Redis使用的內存總量，包含了實際緩存佔用的內存和Redis自身運行所佔用的內存(如元數據、lua)，是由Redis使用內存分配器分配的內存，因此這個數據不包括內存碎片浪費掉的內存，其餘字段表明的含義，都以字節爲單位：

• used_memory_rss：從操做系統上顯示已經分配的內存總量。

• mem_fragmentation_ratio： 內存碎片率。

• used_memory_lua： Lua腳本引擎所使用的內存大小。

• mem_allocator： 在編譯時指定的Redis使用的內存分配器，能夠是libc、jemalloc、tcmalloc。

一、因內存交換引發的性能問題

內存使用率是Redis服務最關鍵的一部分。若是Redis實例的內存使用率超過可用最大內存 (used_memory > 可用最大內存)，那麼操做系統開始進行內存與swap空間交換，把內存中舊的或再也不使用的內容寫入硬盤上（硬盤上的這塊空間叫Swap分區），以便留出新的物理內存給新頁或活動頁(page)使用。 

若是Redis進程上發生內存交換，那麼Redis和依賴Redis上數據的應用會受到嚴重的性能影響。 經過查看used_memory指標可知道Redis正在使用的內存狀況，若是used_memory>可用最大內存，那就說明Redis實例正在進行內存交換或者已經內存交換完畢。

二、跟蹤內存使用率

如果在使用Redis期間沒有開啓rdb快照或aof持久化策略，那麼緩存數據在Redis崩潰時就有丟失的危險。由於當Redis內存使用率超過可用內存的95%時，部分數據開始在內存與swap空間來回交換，這時就可能有丟失數據的危險。

當開啓並觸發快照功能時，Redis會fork一個子進程把當前內存中的數據徹底複製一份寫入到硬盤上。所以如果當前使用內存超過可用內存的45%時觸發快照功能，那麼此時進行的內存交換會變的很是危險(可能會丟失數據)。 假若在這個時候實例上有大量頻繁的更新操做，問題會變得更加嚴重。

經過減小Redis的內存佔用率，來避免這樣的問題，或者使用下面的技巧來避免內存交換髮生：

• 假如緩存數據小於4GB，就使用32位的Redis實例。由於32位實例上的指針大小隻有64位的一半，它的內存空間佔用空間會更少些。 這有一個壞處就是，假設物理內存超過4GB，那麼32位實例能使用的內存仍然會被限制在4GB如下。 要是實例同時也共享給其餘一些應用使用的話，那可能須要更高效的64位Redis實例，這種狀況下切換到32位是不可取的。 無論使用哪一種方式，Redis的dump文件在32位和64位之間是互相兼容的， 所以假若有減小佔用內存空間的需求，能夠嘗試先使用32位，後面再切換到64位上。

• 儘量的使用Hash數據結構。由於Redis在儲存小於100個字段的Hash結構上，其存儲效率是很是高的。因此在不須要集合(set)操做或list的push/pop操做的時候，儘量的使用Hash結構。好比，在一個web應用程序中，須要存儲一個對象表示用戶信息，使用單個key表示一個用戶，其每一個屬性存儲在Hash的字段裏，這樣要比給每一個屬性單獨設置一個key-value要高效的多。 一般狀況下假若有數據使用string結構，用多個key存儲時，那麼應該轉換成單key多字段的Hash結構。 如上述例子中介紹的Hash結構應包含，單個對象的屬性或者單個用戶各類各樣的資料。Hash結構的操做命令是HSET(key, fields, value)和HGET(key, field)，使用它能夠存儲或從Hash中取出指定的字段。

• 設置key的過時時間。一個減小內存使用率的簡單方法就是，每當存儲對象時確保設置key的過時時間。假若key在明確的時間週期內使用或者舊key不大可能被使用時，就能夠用Redis過時時間命令(expire,expireat, pexpire, pexpireat)去設置過時時間，這樣Redis會在key過時時自動刪除key。 假如你知道每秒鐘有多少個新key-value被建立，那能夠調整key的存活時間，並指定閥值去限制Redis使用的最大內存。

• 回收key。在Redis配置文件中(通常叫Redis.conf)，經過設置「maxmemory」屬性的值能夠限制Redis最大使用的內存，修改後重啓實例生效。 也可使用客戶端命令config set maxmemory 去修改值，這個命令是當即生效的，但會在重啓後會失效，須要使用config rewrite命令去刷新配置文件。 如果啓用了Redis快照功能，應該設置「maxmemory」值爲系統可以使用內存的45%，由於快照時須要一倍的內存來複制整個數據集，也就是說若是當前已使用45%，在快照期間會變成95%(45%+45%+5%)，其中5%是預留給其餘的開銷。 若是沒開啓快照功能，maxmemory最高能設置爲系統可用內存的95%。

當內存使用達到設置的最大閥值時，須要選擇一種key的回收策略，可在Redis.conf配置文件中修改「maxmemory-policy」屬性值。 如果Redis數據集中的key都設置了過時時間，那麼「volatile-ttl」策略是比較好的選擇。但若是key在達到最大內存限制時沒可以迅速過時，或者根本沒有設置過時時間。那麼設置爲「allkeys-lru」值比較合適，它容許Redis從整個數據集中挑選最近最少使用的key進行刪除(LRU淘汰算法)。Redis還提供了一些其餘淘汰策略，以下：

• volatile-lru：使用LRU算法從已設置過時時間的數據集合中淘汰數據。

• volatile-ttl：從已設置過時時間的數據集合中挑選即將過時的數據淘汰。

• volatile-random：從已設置過時時間的數據集合中隨機挑選數據淘汰。

• allkeys-lru：使用LRU算法從全部數據集合中淘汰數據。

• allkeys-random：從數據集合中任意選擇數據淘汰

• no-enviction：禁止淘汰數據。

經過設置maxmemory爲系統可用內存的45%或95%(取決於持久化策略)和設置「maxmemory-policy」爲「volatile-ttl」或「allkeys-lru」(取決於過時設置)，能夠比較準確的限制Redis最大內存使用率，在絕大多數場景下使用這2種方式可確保Redis不會進行內存交換。假若你擔憂因爲限制了內存使用率致使丟失數據的話，能夠設置noneviction值禁止淘汰數據。

3、命令處理數 

在info信息裏的total_commands_processed字段顯示了Redis服務處理命令的總數，其命令來自一個或多個Redis客戶端

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

info stats # Stats total_connections_received:843391006 total_commands_processed:3946780282 instantaneous_ops_per_sec:1447 total_net_input_bytes:5060670300797 total_net_output_bytes:13788457111609 instantaneous_input_kbps:1399.63 instantaneous_output_kbps:2863.71 rejected_connections:0 sync_full:2 sync_partial_ok:1 sync_partial_err:0 expired_keys:231497375 evicted_keys:0 keyspace_hits:613100363 keyspace_misses:252710911 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:60179

分析命令處理總數，診斷響應延遲

在Redis實例中，跟蹤命令處理總數是解決響應延遲問題最關鍵的部分，由於Redis是個單線程模型，客戶端過來的命令是按照順序執行的。比較常見的延遲是帶寬，經過千兆網卡的延遲大約有200μs。假若明顯看到命令的響應時間變慢，延遲高於200μs，那多是Redis命令隊列裏等待處理的命令數量比較多。 如上所述，延遲時間增長致使響應時間變慢多是因爲一個或多個慢命令引發的，這時能夠看到每秒命令處理數在明顯降低，甚至於後面的命令徹底被阻塞，致使Redis性能下降。要分析解決這個性能問題，須要跟蹤命令處理數的數量和延遲時間。

好比能夠寫個腳本，按期記錄total_commands_processed的值。當客戶端明顯發現響應時間過慢時，能夠經過記錄的total_commands_processed歷史數據值來判斷命理處理總數是上升趨勢仍是降低趨勢，以便排查問題。

使用命令處理總數解決延遲時間增長

經過與記錄的歷史數據比較得知，命令處理總數確實是處於上升或降低狀態，那麼多是有2個緣由引發的:

• 命令隊列裏的命令數量過多，後面命令一直在等待中

• 幾個慢命令阻塞Redis

下面有三個辦法能夠解決，因上面2條緣由引發的響應延遲問題。

1. 使用多參數命令：如果客戶端在很短的時間內發送大量的命令過來，會發現響應時間明顯變慢，這因爲後面命令一直在等待隊列中前面大量命令執行完畢。有個方法能夠改善延遲問題，就是經過單命令多參數的形式取代多命令單參數的形式。舉例來講，循環使用LSET命令去添加1000個元素到list結構中，是性能比較差的一種方式，更好的作法是在客戶端建立一個1000元素的列表，用單個命令LPUSH或RPUSH，經過多參數構造形式一次性把1000個元素髮送的Redis服務上。下面是Redis的一些操做命令，有單個參數命令和支持多個參數的命令，經過這些命令可儘可能減小使用多命令的次數。  

   1 2 3 4 5 6

   set   -> mset get  -> mget lset -> lpush, rpush lindex -> lrange hset -> hmset hget -> hmget

                                                                                                                                      

2. 管道命令：另外一個減小多命令的方法是使用管道(pipeline)，把幾個命令合併一塊兒執行，從而減小因網絡開銷引發的延遲問題。由於10個命令單獨發送到服務端會引發10次網絡延遲開銷，使用管道會一次性把執行結果返回，僅須要一次網絡延遲開銷。Redis自己支持管道命令，大多數客戶端也支持，假若當前實例延遲很明顯，那麼使用管道去下降延遲是很是有效的。

3. 避免操做大集合的慢命令：若是命令處理頻率太低致使延遲時間增長，這多是由於使用了高時間複雜度的命令操做致使，這意味着每一個命令從集合中獲取數據的時間增大。 因此減小使用高時間複雜的命令，能顯著的提升的Redis的性能。

4、延遲時間 

Redis的延遲數據是沒法從info信息中獲取的。能夠用 Redis-cli工具加 --latency參數運行，如:

1	redis-cli --latency -h 127.0.0.1 -p 6379

因爲當前服務器不一樣的運行狀況，延遲時間可能有所偏差，一般1G網卡的延遲時間是200μs，Redis的響應延遲時間以毫秒爲單位

1 2	[root@localhost ~] # redis-cli --latency -h 127.0.0.1 -p 6379 min: 0, max: 1, avg: 0.07 (12596 samples)

跟蹤Redis延遲性能

Redis之因此這麼流行的主要緣由之一就是低延遲特性帶來的高性能，因此說解決延遲問題是提升Redis性能最直接的辦法。拿1G帶寬來講，如果延遲時間遠高於200μs，那明顯是出現了性能問題。 雖然在服務器上會有一些慢的IO操做，但Redis是單核接受全部客戶端的請求，全部請求是按良好的順序排隊執行。所以如果一個客戶端發過來的命令是個慢操做，那麼其餘全部請求必須等待它完成後才能繼續執行。

使用延遲命令提升性能

一旦肯定延遲時間是個性能問題後，這裏有幾個辦法能夠用來分析解決性能問題。

1. 使用slowlog查出引起延遲的慢命令：Redis中的slowlog命令可讓咱們快速定位到那些超出指定執行時間的慢命令，默認狀況下命令如果執行時間超過10ms就會被記錄到日誌。slowlog只會記錄其命令執行的時間，不包含io往返操做，也不記錄單由網絡延遲引發的響應慢。一般1gb帶寬的網絡延遲，預期在200μs左右，假若一個命令僅執行時間就超過10ms，那比網絡延遲慢了近50倍。 想要查看全部執行時間比較慢的命令，能夠經過使用Redis-cli工具，輸入slowlog get命令查看，返回結果的第三個字段以微妙位單位顯示命令的執行時間。假如只須要查看最後10個慢命令，輸入slowlog get 10便可

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

slowlog get   1) 1) (integer) 12849      2) (integer) 1495630160      3) (integer) 61916      4) 1)  "KEYS"         2)  "20170524less*"   2) 1) (integer) 12848      2) (integer) 1495629901      3) (integer) 59368      4) 1)  "KEYS"         2)  "20170524more*"   3) 1) (integer) 12847      2) (integer) 1495629504      3) (integer) 59522      4) 1)  "KEYS"         2)  "sou_dzmore_16_*"   4) 1) (integer) 12846      2) (integer) 1495629504      3) (integer) 57941      4) 1)  "KEYS"         2)  "sou_dz_16_*"   5) 1) (integer) 12845      2) (integer) 1495629504      3) (integer) 15053      4) 1)  "KEYS"         2)  "list_dingzhis_16_*"   6) 1) (integer) 12844      2) (integer) 1495629504      3) (integer) 24391      4) 1)  "KEYS"         2)  "cache_kwnew_*"   7) 1) (integer) 12843      2) (integer) 1495629469      3) (integer) 57001      4) 1)  "KEYS"         2)  "sou_dzmore_15_*"   8) 1) (integer) 12842      2) (integer) 1495629469      3) (integer) 61131      4) 1)  "KEYS"         2)  "sou_dz_15_*"   9) 1) (integer) 12841      2) (integer) 1495629469      3) (integer) 10035      4) 1)  "KEYS"         2)  "ztlistnew_dingzhi_15_*" 10) 1) (integer) 12840      2) (integer) 1495629469      3) (integer) 17974      4) 1)  "KEYS"         2)  "list_dingzhis_15_*"

圖中字段分別意思是：

• 一、日誌的惟一標識符

• 二、被記錄命令的執行時間點，以 UNIX 時間戳格式表示

• 三、查詢執行時間，以微秒爲單位

• 四、執行的命令，以數組的形式排列。完整命令是config get *

假若你想自定義慢命令的標準，能夠調整觸發日誌記錄慢命令的閥值。如果不多或沒有命令超過10ms，想下降記錄的閥值，好比5毫秒，可在Redis-cli工具中輸入下面的命令配置：

config set slowlog-log-slower-than 5000

也能夠在Redis.config配置文件中設置，以微妙位單位。

2.監控客戶端的鏈接：由於Redis是單線程模型(只能使用單核)，來處理全部客戶端的請求， 但因爲客戶端鏈接數的增加，處理請求的線程資源開始下降分配給單個客戶端鏈接的處理時間，這時每一個客戶端須要花費更多的時間去等待Redis共享服務的響應。這種狀況下監控客戶端鏈接數是很是重要的，由於客戶端建立鏈接數的數量可能超出預期的數量，也多是客戶端端沒有有效的釋放鏈接。在Redis-cli工具中輸入info clients能夠查看到當前實例的全部客戶端鏈接信息。以下圖，第一個字段(connected_clients)顯示當前實例客戶端鏈接的總數：

1 2 3 4 5 6

info clients # Clients connected_clients:21 client_longest_output_list:0 client_biggest_input_buf:13856 blocked_clients:0

Redis默認容許客戶端鏈接的最大數量是10000。如果看到鏈接數超過5000以上，那可能會影響Redis的性能。假若一些或大部分客戶端發送大量的命令過來，這個數字會低的多。

3.限制客戶端鏈接數：自Redis2.6之後，容許使用者在配置文件(Redis.conf)maxclients屬性上修改客戶端鏈接的最大數，也能夠經過在Redis-cli工具上輸入config set maxclients 去設置最大鏈接數。根據鏈接數負載的狀況，這個數字應該設置爲預期鏈接數峯值的110到150之間，如果鏈接數超出這個數字後，Redis會拒絕並馬上關閉新來的鏈接。經過設置最大鏈接數來限制非預期數量的鏈接數增加，是很是重要的。另外，新鏈接嘗試失敗會返回一個錯誤消息，這可讓客戶端知道，Redis此時有非預期數量的鏈接數，以便執行對應的處理措施。 上述二種作法對控制鏈接數的數量和持續保持Redis的性能最優是很是重要的，

4.增強內存管理：較少的內存會引發Redis延遲時間增長。若是Redis佔用內存超出系統可用內存，操做系統會把Redis進程的一部分數據，從物理內存交換到硬盤上，內存交換會明顯的增長延遲時間。關於怎麼監控和減小內存使用，可查看used_memory介紹章節。

5. 性能數據指標：分析解決Redis性能問題，一般須要把延遲時間的數據變化與其餘性能指標的變化相關聯起來。命令處理總數降低的發生多是由慢命令阻塞了整個系統，但若是命令處理總數的增長，同時內存使用率也增長，那麼就多是因爲內存交換引發的性能問題。對於這種性能指標相關聯的分析，須要從歷史數據上來觀察到數據指標的重要變化，此外還能夠觀察到單個性能指標相關聯的全部其餘性能指標信息。這些數據能夠在Redis上收集，週期性的調用內容爲Redis info的腳本，而後分析輸出的信息，記錄到日誌文件中。當延遲發生變化時，用日誌文件配合其餘數據指標，把數據串聯起來排查定位問題。

5、內存碎片率

info信息中的mem_fragmentation_ratio給出了內存碎片率的數據指標，它是由操系統分配的內存除以Redis分配的內存得出：

1	mem_fragmentation_ratio = used_memory_rss / used_memory

used_memory和used_memory_rss都包含的內存分配有：

• 用戶定義的數據：內存被用來存儲key-value值。

• 內部開銷： 存儲內部Redis信息用來表示不一樣的數據類型。

used_memory_rss的rss是Resident Set Size的縮寫，表示該進程所佔物理內存的大小，是操做系統分配給Redis實例的內存大小。除了用戶定義的數據和內部開銷之外，used_memory_rss指標還包含了內存碎片的開銷，內存碎片是由操做系統低效的分配/回收物理內存致使的。

操做系統負責分配物理內存給各個應用進程，Redis使用的內存與物理內存的映射是由操做系統上虛擬內存管理分配器完成的。
舉個例子來講，Redis須要分配連續內存塊來存儲1G的數據集，這樣的話更有利，但可能物理內存上沒有超過1G的連續內存塊，那操做系統就不得不使用多個不連續的小內存塊來分配並存儲這1G數據，也就致使內存碎片的產生。

內存分配器另外一個複雜的層面是，它常常會預先分配一些內存塊給引用，這樣作會使加快應用程序的運行。

理解資源性能

跟蹤內存碎片率對理解Redis實例的資源性能是很是重要的。內存碎片率稍大於1是合理的，這個值表示內存碎片率比較低，也說明redis沒有發生內存交換。但若是內存碎片率超過1.5，那就說明Redis消耗了實際須要物理內存的150%，其中50%是內存碎片率。如果內存碎片率低於1的話，說明Redis內存分配超出了物理內存，操做系統正在進行內存交換。內存交換會引發很是明顯的響應延遲，可查看used_memory介紹章節。

1 2 3 4 5 6 7 8 9 10

info memory # Memory used_memory:21189222536 used_memory_human:19.73G used_memory_rss:21901688832 used_memory_peak:27350156888 used_memory_peak_human:25.47G used_memory_lua:35840 mem_fragmentation_ratio:1.03 mem_allocator:jemalloc-3.6.0

用內存碎片率預測性能問題

假若內存碎片率超過了1.5，那多是操做系統或Redis實例中內存管理變差的表現。下面有3種方法解決內存管理變差的問題，並提升Redis性能：

1. 重啓Redis服務器：若是內存碎片率超過1.5，重啓Redis服務器可讓額外產生的內存碎片失效並從新做爲新內存來使用，使操做系統恢復高效的內存管理。額外碎片的產生是因爲Redis釋放了內存塊，但內存分配器並無返回內存給操做系統，這個內存分配器是在編譯時指定的，能夠是libc、jemalloc或者tcmalloc。 經過比較used_memory_peak, used_memory_rss和used_memory_metrics的數據指標值能夠檢查額外內存碎片的佔用。從名字上能夠看出，used_memory_peak是過去Redis內存使用的峯值，而不是當前使用內存的值。若是used_memory_peak和used_memory_rss的值大體上相等，並且兩者明顯超過了used_memory值，這說明額外的內存碎片正在產生。 在Redis-cli工具上輸入info memory能夠查看上面三個指標的信息：

在重啓服務器以前，須要在Redis-cli工具上輸入shutdown save命令，意思是強制讓Redis數據庫執行保存操做並關閉Redis服務，這樣作能保證在執行Redis關閉時不丟失任何數據。 在重啓後，Redis會從硬盤上加載持久化的文件，以確保數據集持續可用。

2.限制內存交換： 若是內存碎片率低於1，Redis實例可能會把部分數據交換到硬盤上。內存交換會嚴重影響Redis的性能，因此應該增長可用物理內存或減小實Redis內存佔用。 可查看used_memory章節的優化建議。

3.修改內存分配器：Redis支持glibc’s malloc、jemalloc十一、tcmalloc幾種不一樣的內存分配器，每一個分配器在內存分配和碎片上都有不一樣的實現。不建議普通管理員修改Redis默認內存分配器，由於這須要徹底理解這幾種內存分配器的差別，也要從新編譯Redis。這個方法更多的是讓其瞭解Redis內存分配器所作的工做，固然也是改善內存碎片問題的一種辦法。

6、回收key

info信息中的evicted_keys字段顯示的是，由於maxmemory限制致使key被回收刪除的數量。回收key的狀況只會發生在設置maxmemory值後，不設置會發生內存交換。 當Redis因爲內存壓力須要回收一個key時，Redis首先考慮的不是回收最舊的數據，而是在最近最少使用的key或即將過時的key中隨機選擇一個key，從數據集中刪除。

這能夠在配置文件中設置maxmemory-policy值爲「volatile-lru」或「volatile-ttl」，來肯定Redis是使用lru策略仍是過時時間策略。 假若全部的key都有明確的過時時間，那過時時間回收策略是比較合適的。如果沒有設置key的過時時間或者說沒有足夠的過時key，那設置lru策略是比較合理的，這能夠回收key而不用考慮其過時狀態。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

# Stats total_connections_received:843708918 total_commands_processed:3947987793 instantaneous_ops_per_sec:1360 total_net_input_bytes:5061895225788 total_net_output_bytes:13791028024582 instantaneous_input_kbps:1247.52 instantaneous_output_kbps:2756.92 rejected_connections:0 sync_full:2 sync_partial_ok:1 sync_partial_err:0 expired_keys:231544806 evicted_keys:0 keyspace_hits:613324172 keyspace_misses:252815503 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:60179

根據key回收定位性能問題

跟蹤key回收是很是重要的，由於經過回收key，能夠保證合理分配Redis有限的內存資源。若是evicted_keys值常常超過0，那應該會看到客戶端命令響應延遲時間增長，由於Redis不但要處理客戶端過來的命令請求，還要頻繁的回收知足條件的key。
須要注意的是，回收key對性能的影響遠沒有內存交換嚴重，如果在強制內存交換和設置回收策略作一個選擇的話，選擇設置回收策略是比較合理的，由於把內存數據交換到硬盤上對性能影響很是大(見前面章節)。

減小回收key以提高性能

減小回收key的數量是提高Redis性能的直接辦法，下面有2種方法能夠減小回收key的數量：

1.增長內存限制：假若開啓快照功能，maxmemory須要設置成物理內存的45%，這幾乎不會有引起內存交換的危險。如果沒有開啓快照功能，設置系統可用內存的95%是比較合理的，具體參考前面的快照和maxmemory限制章節。若是maxmemory的設置是低於45%或95%(視持久化策略)，經過增長maxmemory的值能讓Redis在內存中存儲更多的key，這能顯著減小回收key的數量。 如果maxmemory已經設置爲推薦的閥值後，增長maxmemory限制不但沒法提高性能，反而會引起內存交換，致使延遲增長、性能下降。 maxmemory的值能夠在Redis-cli工具上輸入config set maxmemory命令來設置。
須要注意的是，這個設置是當即生效的，但重啓後丟失，須要永久化保存的話，再輸入config rewrite命令會把內存中的新配置刷新到配置文件中。

2.對實例進行分片：分片是把數據分割成合適大小，分別存放在不一樣的Redis實例上，每個實例都包含整個數據集的一部分。經過分片能夠把不少服務器聯合起來存儲數據，至關於增長總的物理內存，使其在沒有內存交換和回收key的策略下也能存儲更多的key。假若有一個很是大的數據集，maxmemory已經設置，實際內存使用也已經超過了推薦設置的閥值，那經過數據分片能明顯減小key的回收，從而提升Redis的性能。 分片的實現有不少種方法，下面是Redis實現分片的幾種常見方式：

• a. Hash分片：一個比較簡單的方法實現，經過Hash函數計算出key的Hash值，而後值所在範圍對應特定的Redis實例。

• b. 代理分片：客戶端把請求發送到代理上，代理經過分片配置表選擇對應的Redis實例。 如Twitter的Twemproxy，豌豆莢的codis。

• c. 一致性Hash分片

• d. 虛擬桶分片

• 做者：踏雪無痕
• 出處：http://www.cnblogs.com/chenpingzhao/