redis性能分析與優(yōu)化建議

首先,并不是說redis是內(nèi)存應(yīng)用就完全沒性能問題,用的不好,還是會出現(xiàn)各種狀況,例如RDB頻繁,碎片太多等.

性能分析

info信息:

在redis-cli進(jìn)入登錄界面后,輸入info all,或者redis-cli -h ${ip} -p ${post} -a "${pass}" -c info all，通常我們只輸入info就夠了，是簡介模式的意思，info all是詳細(xì)模式

之后,就會獲取所有與Redis服務(wù)相關(guān)的實(shí)時性能信息,類似于linux命令top那樣的東西.

info命令輸出的數(shù)據(jù)可分為10個類別，分別是：

• server

• clients

• memory

• persistence

• stats

• replication

• cpu

• commandstats

• cluster

• keyspace

下面展開解析一些重點(diǎn)信息.

server?部分:

redis_version?:???? Redis 服務(wù)器版本,不同版本會有些功能和命令不同

arch_bits?: ????架構(gòu)（32 或 64 位）,某些情況,容易被忽略的坑

tcp_port?: ????TCP/IP 監(jiān)聽端口,確認(rèn)你操作的對不對

uptime_in_seconds?: ????自 Redis 服務(wù)器啟動以來，經(jīng)過的秒數(shù),可以確認(rèn)有沒有被重啟過

uptime_in_days?:???? 自 Redis 服務(wù)器啟動以來，經(jīng)過的天數(shù),可以確認(rèn)有沒有被重啟過

clients?部分:

connected_clients?: ????已連接客戶端的數(shù)量（不包括通過從屬服務(wù)器連接的客戶端）

client_longest_output_list?: ????當(dāng)前連接的客戶端當(dāng)中，最長的輸出列表

client_longest_input_buf?: ????當(dāng)前連接的客戶端當(dāng)中，最大輸入緩存

blocked_clients?: ????正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客戶端的數(shù)量

memory部分:

maxmemory/maxmemory_human:??? 配置文件redis.conf限制的可分配的最大內(nèi)存總量,當(dāng)超過之后,就會觸發(fā)LRU刪除舊數(shù)據(jù).

used_memory/used_memory_human:??? 當(dāng)前redis-server實(shí)際使用的內(nèi)存總量,如果used_memory > maxmemory ,那么操作系統(tǒng)開始進(jìn)行內(nèi)存與swap空間交換,以便騰出新的物理內(nèi)存給新頁或活動頁(page)使用,那是有多糟糕大家可以想得到.

used_memory_rss/used_memory_rss_human:????從操作系統(tǒng)上顯示已經(jīng)分配的內(nèi)存總量,也就是這個redis-server占用的系統(tǒng)物理內(nèi)存實(shí)際值,比used_memory多出來的就可能是碎片.

mem_fragmentation_ratio:????內(nèi)存碎片率,內(nèi)存碎片率稍大于1是合理的,說明redis沒有發(fā)生內(nèi)存交換,如果內(nèi)存碎片率超過1.5，那就說明Redis消耗了實(shí)際需要物理內(nèi)存的150%，其中50%是內(nèi)存碎片率。若是內(nèi)存碎片率低于1的話，說明Redis內(nèi)存分配超出了物理內(nèi)存，操作系統(tǒng)正在進(jìn)行內(nèi)存交換。內(nèi)存交換會引起非常明顯的響應(yīng)延遲.

????下面是計(jì)算公式:

????????

????當(dāng)碎片率出現(xiàn)問題,有3種方法解決內(nèi)存管理變差的問題,提高redis性能:

????????1. 重啟Redis服務(wù)器：如果內(nèi)存碎片率超過1.5，重啟Redis服務(wù)器可以讓額外產(chǎn)生的內(nèi)存碎片失效并重新作為新內(nèi)存來使用，使操作系統(tǒng)恢復(fù)高效的內(nèi)存管理。

????????2.限制內(nèi)存交換：?如果內(nèi)存碎片率低于1，Redis實(shí)例可能會把部分?jǐn)?shù)據(jù)交換到硬盤上。內(nèi)存交換會嚴(yán)重影響Redis的性能，所以應(yīng)該增加可用物理內(nèi)存或減少實(shí)Redis內(nèi)存占用

????????3.修改內(nèi)存分配器：
Redis支持glibc’s malloc、jemalloc11、tcmalloc幾種不同的內(nèi)存分配器，每個分配器在內(nèi)存分配和碎片上都有不同的實(shí)現(xiàn)。不建議普通管理員修改Redis默認(rèn)內(nèi)存分配器，因?yàn)檫@需要完全理解這幾種內(nèi)存分配器的差異，也要重新編譯Redis。

used_memory_lua:????Lua腳本引擎所使用的內(nèi)存大小。redis默認(rèn)允許使用lua腳本,不過太多了的話就占用了可用內(nèi)存

mem_allocator:????在編譯時指定的Redis使用的內(nèi)存分配器，可以是libc、jemalloc、tcmalloc.

persistence?部分:

RDB信息,RDB的操作要用到bgsave命令,是比較耗費(fèi)資源的持久化操作,而且不是實(shí)時的,容易造成宕機(jī)數(shù)據(jù)消失,如果內(nèi)存容量滿了,不能做bgsave操作的話,隱患會很大.

rdb_changes_since_last_save?: ????距離最近一次成功創(chuàng)建持久化文件之后，經(jīng)過了多少秒。持久化是需要占用資源的,在高負(fù)載下需要盡量避免持久化的影響,下列參數(shù)均有參考價值.

rdb_bgsave_in_progress:????當(dāng)前是否在進(jìn)行bgsave操作。是為1

rdb_last_save_time?:???? 最近一次成功創(chuàng)建 RDB 文件的 UNIX 時間戳。

rdb_last_bgsave_time_sec?: ????記錄了最近一次創(chuàng)建 RDB 文件耗費(fèi)的秒數(shù)。

rdb_last_bgsave_status:????上次保存的狀態(tài)

rdb_current_bgsave_time_sec?: ????如果服務(wù)器正在創(chuàng)建 RDB 文件，那么這個域記錄的就是當(dāng)前的創(chuàng)建操作已經(jīng)耗費(fèi)的秒數(shù)。

AOF信息,AOF是持續(xù)記錄命令到持久化文件的方法,比較節(jié)省資源,但是AOF存儲文件會沒有限制存儲,時間一長,或者操作太頻繁,那就會出現(xiàn)AOF文件過大,撐爆硬盤的事.而且,這個方法還是會定期bgsave操作.

aof_enabled:????AOF文件是否啟用

aof_rewrite_in_progress:????表示當(dāng)前是否在進(jìn)行寫入AOF文件操作

aof_last_rewrite_time_sec?: ????最近一次創(chuàng)建 AOF 文件耗費(fèi)的時長。

aof_current_rewrite_time_sec?: ????如果服務(wù)器正在創(chuàng)建 AOF 文件，那么這個域記錄的就是當(dāng)前的創(chuàng)建操作已經(jīng)耗費(fèi)的秒數(shù)。

aof_last_bgrewrite_status:????上次寫入狀態(tài)

aof_last_write_status:????上次寫入狀態(tài)

aof_base_size?: ????服務(wù)器啟動時或者 AOF 重寫最近一次執(zhí)行之后，AOF 文件的大小。

aof_pending_bio_fsync?: ????后臺 I/O 隊(duì)列里面，等待執(zhí)行的?fsync?調(diào)用數(shù)量。

aof_delayed_fsync?: ????被延遲的?fsync?調(diào)用數(shù)量。

stats部分:

total_commands_processed:????顯示了Redis服務(wù)處理命令的總數(shù)，且值是遞增的.因?yàn)镽edis是個單線程模型，客戶端過來的命令是按照順序執(zhí)行的,如果命令隊(duì)列里等待處理的命令數(shù)量比較多,命令的響應(yīng)時間就變慢,甚至于后面的命令完全被阻塞，導(dǎo)致Redis性能降低.所以這個時候就需要記錄這個參數(shù)的值,是不是增長過快,導(dǎo)致了性能降低.

instantaneous_ops_per_sec?:???? 服務(wù)器每秒鐘執(zhí)行的命令數(shù)量,同上,如果增長過快就有問題。

expired_keys?:???? 因?yàn)檫^期而被自動刪除的數(shù)據(jù)庫鍵數(shù)量,具有參考意義。

evicted_keys:????顯示因?yàn)閙axmemory限制導(dǎo)致key被回收刪除的數(shù)量.根據(jù)配置文件中設(shè)置maxmemory-policy值來確定Redis是使用lru策略還是過期時間策略.如果是過期回收的,不會被記錄在這里,通常這個值不為0,那就要考慮增加內(nèi)存限制,不然就會造成內(nèi)存交換,輕則性能變差,重則丟數(shù)據(jù).

latest_fork_usec:???? 最近一次?fork()?操作耗費(fèi)的微秒數(shù)。fork()是很耗費(fèi)資源的操作,所以要留意一下.

commandstats部分:

cmdstat_XXX:????記錄了各種不同類型的命令的執(zhí)行統(tǒng)計(jì)信息,命令包含有讀有寫，分得比較細(xì)，其中calls代表命令執(zhí)行的次數(shù),usec代表命令耗費(fèi)的 CPU 時間,usec_per_call代表每個命令耗費(fèi)的平均 CPU 時間,單位為微秒.對于排錯有一定用途.

---------------------------------------------------------------------------------------------------

其他問題的分析方法:

查看redis的網(wǎng)絡(luò)延時:

Redis的延遲數(shù)據(jù)是無法從info信息中獲取的。倘若想要查看延遲時間，可以用 Redis-cli工具加--latency參數(shù)運(yùn)行

redis-cli --latency -h 10.1.2.11 -p 6379

他將會持續(xù)掃描延遲時間,直到按ctrl+C退出,以毫秒為單位測量Redis的響應(yīng)延遲時間,由于服務(wù)器不同的運(yùn)行情況，延遲時間可能有所誤差，通常1G網(wǎng)卡的延遲時間是0.2毫秒,若延時值遠(yuǎn)高于這個參考值,那明顯是有性能問題了。這個時候我們要考慮檢查一下網(wǎng)絡(luò)狀況.

查看redis的慢查詢:

Slow log 是 Redis 用來記錄查詢執(zhí)行時間的日志系統(tǒng)。Redis中的slowlog命令可以讓我們快速定位到那些超出指定執(zhí)行時間的慢命令，默認(rèn)情況下會記錄執(zhí)行時間超過10ms的記錄到日志,由參數(shù)slowlog-log-slower-than控制.最多記錄128條,由參數(shù)slowlog-max-len控制,超過就自動刪除.

通常這個默認(rèn)參數(shù)夠用,也可以在線CONFIG SET修改參數(shù)slowlog-log-slower-than和slowlog-max-len來修改這個時間和限制條數(shù)。

通常1gb帶寬的網(wǎng)絡(luò)延遲，預(yù)期在0.2ms左右，倘若一個命令僅執(zhí)行時間就超過10ms，那比網(wǎng)絡(luò)延遲慢了近50倍?？梢酝ㄟ^使用Redis-cli工具，輸入slowlog get命令查看，返回結(jié)果的第三個字段以微妙位單位顯示命令的執(zhí)行時間。假如只需要查看最后3個慢命令，輸入slowlog get 10即可。

127.0.0.1:6379>?slowlog?get?10
????.
????.
????.
4)?1)?(integer)?215
????2)?(integer)?1489099695
????3)?(integer)?11983
????4)?1)?"SADD"
???????2)?"USER_TOKEN_MAP51193"
???????3)?"qIzwZKBmBJozKprQgoTEI3Qo8QO2Fi!4"
?5)?1)?(integer)?214
????2)?(integer)?1489087112
????3)?(integer)?18002
????4)?1)?"SADD"
???????2)?"USER_TOKEN_MAP51192"
???????3)?"Z3Hs!iTUNfweqvLLf!ptdchSV2JAOrrH"
?6)?1)?(integer)?213
????2)?(integer)?1489069123
????3)?(integer)?15407
????4)?1)?"SADD"
???????2)?"USER_TOKEN_MAP51191"
???????3)?"S3rNzOBwUlaI3QfOK9dIITB6Bk7LIGYe"

• 1=日志的唯一標(biāo)識符

• 2=被記錄命令的執(zhí)行時間點(diǎn)，以 UNIX 時間戳格式表示

• 3=查詢執(zhí)行時間，以微秒為單位。例子中命令使用11毫秒。

• 4= 執(zhí)行的命令，以數(shù)組的形式排列。完整命令是拼在一起.

監(jiān)控客戶端的連接：

因?yàn)镽edis是單線程模型(只能使用單核)，來處理所有客戶端的請求， 但由于客戶端連接數(shù)的增長，處理請求的線程資源開始降低分配給單個客戶端連接的處理時間，這時每個客戶端需要花費(fèi)更多的時間去等待Redis共享服務(wù)的響應(yīng)。

#查看客戶端連接狀態(tài)
127.0.0.1:6379>?info?clients
#?Clients
connected_clients:11
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0

第一個字段(connected_clients)顯示當(dāng)前實(shí)例客戶端連接的總數(shù),Redis默認(rèn)允許客戶端連接的最大數(shù)量是10000。若是看到連接數(shù)超過5000以上，那可能會影響Redis的性能。倘若一些或大部分客戶端發(fā)送大量的命令過來，這個數(shù)字會低的多。

查當(dāng)前客戶端狀態(tài)

#查看所有正在連接的客戶端狀態(tài),
127.0.0.1:6379>?client?list
id=821882?addr=10.25.138.2:60990?fd=8?name=?age=53838?idle=24?flags=N?db=0?sub=0?psub=0?multi=-1?qbuf=0?qbuf-free=0?obl=0?oll=0?omem=0?events=r?cmd=ping

這個看起來有點(diǎn)繞,因?yàn)楹蜌v史數(shù)據(jù)是混在一起的:

addr:客戶端的地址和端口,包含當(dāng)前連接和歷史連接

age:這個客戶端連進(jìn)來的生命周期,也就是連進(jìn)來之后的持續(xù)時間,單位是秒

idle:這個客戶端的空閑時間,也就是說這個時間內(nèi),客戶端沒有操作,單位是秒

db:操作的數(shù)據(jù)庫,redis默認(rèn)有db0~db15可用選擇

cmd:客戶端最后一次使用的命令

也就是說,idle越少,那就代表這個客戶端剛剛操作,反則是歷史記錄而已.age越少就代表是剛剛建立的連接,越大則是歷史連接.而有些時候個別使用者用了scan或keys命令,會對數(shù)據(jù)量大的redis造成很大的負(fù)載壓力,所以需要特別關(guān)注.

特大key的統(tǒng)計(jì):

在redis的單線程處理方式下,一些數(shù)據(jù)量比較大的key的操作明顯是會影響性能,所以必要時,我們要統(tǒng)計(jì)出來,交給開發(fā)來優(yōu)化

#統(tǒng)計(jì)生產(chǎn)上比較大的key
redis-cli?-h*?-a*?-p*?--bigkeys
#查看某個key的持續(xù)時間
127.0.0.1:6379>?OBJECT?IDLETIME?key名字

--bigkeys信息解析:

1.該命令使用scan方式對key進(jìn)行統(tǒng)計(jì)，所以使用時無需擔(dān)心對redis造成阻塞。
2.輸出大概分為兩部分，summary之上的部分，只是顯示了掃描的過程。summary部分給出了每種數(shù)據(jù)結(jié)構(gòu)中最大的Key,所以下面部分更重要些。
3.統(tǒng)計(jì)出的最大key只有string類型是以字節(jié)長度為衡量標(biāo)準(zhǔn)的。list,set,zset等都是以元素個數(shù)作為衡量標(biāo)準(zhǔn)，不能說明其占的內(nèi)存就一定多,需要另外計(jì)算。

得出最大key名字后,就去看看粗略大小,

#查看某個key序列化后的長度
debug?object?key

輸出的項(xiàng)的說明：

• Value at：key的內(nèi)存地址

• refcount：引用次數(shù)

• encoding：編碼類型

• serializedlength：經(jīng)過壓縮后的序列化長度,單位是 B, 也就是 Byte（字節(jié)）,因?yàn)閴嚎s效果要看編碼類型,不一定反應(yīng)內(nèi)存中的大小,只是有參考價值.

• lru_seconds_idle：空閑時間

終上所述,我們要關(guān)注的大key信息正是serializedlength的長度了.

另外還有一個工具[rdbtools],可以全面分析redis里面的key信息,但是要額外安裝,對于內(nèi)網(wǎng)用戶不可謂不麻煩,因?yàn)椴皇窍到y(tǒng)自帶的功能,這里不詳細(xì)說明,請等待另一篇文章另外介紹.

數(shù)據(jù)持久化引發(fā)的延遲

Redis的數(shù)據(jù)持久化工作本身就會帶來延遲，需要根據(jù)數(shù)據(jù)的安全級別和性能要求制定合理的持久化策略：

1.AOF + fsync always的設(shè)置雖然能夠絕對確保數(shù)據(jù)安全，但每個操作都會觸發(fā)一次fsync，會對Redis的性能有比較明顯的影響
2.AOF + fsync every second是比較好的折中方案，每秒fsync一次
3.AOF + fsync never會提供AOF持久化方案下的最優(yōu)性能,使用RDB持久化通常會提供比使用AOF更高的性能，但需要注意RDB的策略配置
4.每一次RDB快照和AOF Rewrite都需要Redis主進(jìn)程進(jìn)行fork操作。fork操作本身可能會產(chǎn)生較高的耗時，與CPU和Redis占用的內(nèi)存大小有關(guān)。根據(jù)具體的情況合理配置RDB快照和AOF Rewrite時機(jī)，避免過于頻繁的fork帶來的延遲.
例如：Redis在fork子進(jìn)程時需要將內(nèi)存分頁表拷貝至子進(jìn)程，以占用了24GB內(nèi)存的Redis實(shí)例為例，共需要拷貝24GB / 4kB * 8 = 48MB的數(shù)據(jù)。在使用單Xeon 2.27Ghz的物理機(jī)上，這一fork操作耗時216ms。

可以通過INFO命令返回的latest_fork_usec字段查看上一次fork操作的耗時（微秒）。

Swap引發(fā)的延遲

當(dāng)Linux將Redis所用的內(nèi)存分頁移至swap空間時，將會阻塞Redis進(jìn)程，導(dǎo)致Redis出現(xiàn)不正常的延遲。Swap通常在物理內(nèi)存不足或一些進(jìn)程在進(jìn)行大量I/O操作時發(fā)生，應(yīng)盡可能避免上述兩種情況的出現(xiàn)。

在/proc/redis進(jìn)程號/smaps文件中會保存進(jìn)程的swap記錄，通過查看這個文件，能夠判斷Redis的延遲是否由Swap產(chǎn)生。如果這個文件中記錄了較大的Swap size，則說明延遲很有可能是Swap造成的。

例子如下，可以看到當(dāng)前swap的狀態(tài)時0KB，也就是沒用到swap，

#/proc/pid/smaps顯示了進(jìn)程運(yùn)行時的內(nèi)存影響，系統(tǒng)的運(yùn)行時庫(so)，堆，棧信息均可在其中看到。
cat?/proc/`ps?aux?|grep?redis?|grep?-v?grep?|awk?'{print?$2}'`/smaps
00400000-00531000?r-xp?00000000?fc:02?805438521?/usr/local/bin/redis-server
Size:???????????????1220?kB
Rss:?????????????????924?kB
Pss:?????????????????924?kB
Shared_Clean:??????????0?kB
Shared_Dirty:??????????0?kB
Private_Clean:???????924?kB
Private_Dirty:?????????0?kB
Referenced:??????????924?kB
Anonymous:?????????????0?kB
AnonHugePages:?????????0?kB
Shared_Hugetlb:????????0?kB
Private_Hugetlb:???????0?kB
Swap:??????????????????0?kB
SwapPss:???????????????0?kB
KernelPageSize:????????4?kB
MMUPageSize:???????????4?kB
Locked:????????????????0?kB

內(nèi)存滿了怎么辦:
redis內(nèi)存滿了,那確實(shí)是很麻煩的事,但是再麻煩也得處理啊,這就得從redis架構(gòu)原理說起了.
首先我們要了解,redis的內(nèi)存滿,并不代表是用了系統(tǒng)的100%內(nèi)存,為什么這么說呢?我們都知道redis做持久化是save和bgsave,而常用的bgsave(也是默認(rèn))是fork一個進(jìn)程,把內(nèi)存copy一份再壓縮后存到硬盤成*.rdb文件.這里就涉及一個問題,你內(nèi)存必須保證有和數(shù)據(jù)一樣大的空間才能做bgsave,那嚴(yán)格來說,只要你的內(nèi)存超過系統(tǒng)內(nèi)存的50%,那就可以被稱為redis內(nèi)存滿了.
redis的持久化策略,上面只說了持久化會阻塞操作導(dǎo)致延時,而如果內(nèi)存滿了,數(shù)據(jù)量的增加會讓持久化造成的延時會更嚴(yán)重,而且持久化失敗后是默認(rèn)每分鐘重試一遍.
那么問題就來了,因?yàn)閮?nèi)存滿了,持久化失敗,然后一分鐘后再持久化,就造成了惡性循環(huán),redis的性能直線下降.那怎么辦好呢?
更改持久化策略是個臨時解決方案,

可以先嘗試關(guān)閉持久化失敗導(dǎo)致的終止所有的客戶端write請求的選項(xiàng),

config?set?stop-writes-on-bgsave-error?no

但是這個方法治標(biāo)不治本，我們只是忽略了問題而已,

另一種解決方案就是直接把rdb持久化關(guān)閉掉:

config?set?save?""

為什么能解決,答案也很明顯,關(guān)閉了持久化,那就不會阻塞操作,那你redis的性能還是保證到了.但是又會引入新問題,沒了持久化,內(nèi)存數(shù)據(jù)如果redis-server程序重啟或關(guān)閉就沒了,還是比較危險(xiǎn)的.而且內(nèi)存滿的問題還在,如果內(nèi)存用到了系統(tǒng)內(nèi)存100%,甚至觸發(fā)了系統(tǒng)的OOM,那就坑大了,因?yàn)閮?nèi)存被徹底清空,數(shù)據(jù)也都沒有了.也就是所謂的臨時解決辦法.
所以正確的做法是,在不阻塞操作之后,刪掉可以刪除的數(shù)據(jù),再重新拉起持久化,然后準(zhǔn)備擴(kuò)容的工作.
占用內(nèi)存看哪里,上面已經(jīng)說了,但是內(nèi)存滿了的定義,并不一定只是實(shí)際內(nèi)存占用,碎片也是要包含在內(nèi)的,例如:

#這種情況,肯定就是內(nèi)存滿
used_memory_human:4.2G
maxmemory_human:4.00G
#但是這種情況,也是內(nèi)存滿
used_memory_human:792.30M
used_memory_rss_human:3.97G
used_memory_peak_human:4.10G
maxmemory_human:4.00G

因?yàn)閮?nèi)存碎片沒有被釋放,那它還是會占用內(nèi)存空間,對于系統(tǒng)來說,碎片也是redis-server占用的內(nèi)存,不是空閑的內(nèi)存,那剩下的內(nèi)存還是不足以用來bgsave.那怎么解決碎片呢?

在redis4.0之前,沒其他更好辦法,只能重啟redis-server,之后的新版本則新加了一個碎片回收參數(shù),杜絕了這個問題.

而碎片問題其實(shí)影響頗大,因?yàn)檎Ｇ闆r下,這些用不了又確實(shí)占著內(nèi)存的數(shù)據(jù),會讓我們的redis浪費(fèi)空間之余,還會額外造成內(nèi)存滿的風(fēng)險(xiǎn).所以也正如上面說的那樣,如果碎片率超過1.5之后,是該想想回收一下.

那確實(shí)需要保存內(nèi)存數(shù)據(jù)怎么辦?只能忍痛割愛,把不必要的數(shù)據(jù)刪除掉,讓內(nèi)存降到能做bgsave之后再重啟來回收碎片.要不,就是升級到4.0之后避免同類問題.

優(yōu)化建議

系統(tǒng)優(yōu)化

1.關(guān)閉Transparent huge pages

Transparent HugePages會讓內(nèi)核khugepaged線程在運(yùn)行時動態(tài)分配內(nèi)存。在大部分linux發(fā)行版本中默認(rèn)是啟用的，缺點(diǎn)是可能會造成內(nèi)存在運(yùn)行時的延遲分配，對于大內(nèi)存應(yīng)用并不友好，例如：oracle，redis等會占用大量內(nèi)存的應(yīng)用，所以建議關(guān)閉。

#關(guān)閉Transparent?HugePages，默認(rèn)狀態(tài)是[always]
echo?never?>?/sys/kernel/mm/transparent_hugepage/enabled

2.在物理機(jī)部署redis，這點(diǎn)不用多說了，虛擬機(jī)或者是docker都會有一定的延時，沒有必要為了好管理二浪費(fèi)這些性能。

3.多用連接池，而不是頻繁斷開再連接，效果我想不言而喻。

4.客戶端進(jìn)行的批量數(shù)據(jù)操作，應(yīng)使用Pipeline特性在一次交互中完成。

行為優(yōu)化

1.假如緩存數(shù)據(jù)小于4GB，可以選擇使用32位的Redis實(shí)例。因?yàn)?2位實(shí)例上的指針大小只有64位的一半，它的內(nèi)存空間占用空間會更少些。Redis的dump文件在32位和64位之間是互相兼容的， 因此倘若有減少占用內(nèi)存空間的需求，可以嘗試先使用32位，后面再切換到64位上。

2.盡可能的使用Hash數(shù)據(jù)結(jié)構(gòu)。因?yàn)镽edis在儲存小于100個字段的Hash結(jié)構(gòu)上，其存儲效率是非常高的。所以在不需要集合(set)操作或list的push/pop操作的時候，盡可能的使用Hash結(jié)構(gòu)。Hash結(jié)構(gòu)的操作命令是HSET(key, fields, value)和HGET(key, field)，使用它可以存儲或從Hash中取出指定的字段。

3.盡量設(shè)置key的過期時間。一個減少內(nèi)存使用率的簡單方法就是，每當(dāng)存儲對象時確保設(shè)置key的過期時間。倘若key在明確的時間周期內(nèi)使用或者舊key不大可能被使用時，就可以用Redis過期時間命令(expire,expireat, pexpire, pexpireat)去設(shè)置過期時間，這樣Redis會在key過期時自動刪除key.用ttl命令可以查詢過期時間,單位是秒,顯示-2代表key不存在,顯示-1代表沒有設(shè)置超時時間(也就是永久的).

4.使用多參數(shù)命令：若是客戶端在很短的時間內(nèi)發(fā)送大量的命令過來，會發(fā)現(xiàn)響應(yīng)時間明顯變慢，這由于后面命令一直在等待隊(duì)列中前面大量命令執(zhí)行完畢。舉例來說，循環(huán)使用LSET命令去添加1000個元素到list結(jié)構(gòu)中，是性能比較差的一種方式，更好的做法是在客戶端創(chuàng)建一個1000元素的列表，用單個命令LPUSH或RPUSH，通過多參數(shù)構(gòu)造形式一次性把1000個元素發(fā)送的Redis服務(wù)上。

5.管道命令：另一個減少多命令的方法是使用管道(pipeline)，把幾個命令合并一起執(zhí)行，從而減少因網(wǎng)絡(luò)開銷引起的延遲問題。因?yàn)?0個命令單獨(dú)發(fā)送到服務(wù)端會引起10次網(wǎng)絡(luò)延遲開銷，使用管道會一次性把執(zhí)行結(jié)果返回，僅需要一次網(wǎng)絡(luò)延遲開銷。Redis本身支持管道命令，大多數(shù)客戶端也支持，倘若當(dāng)前實(shí)例延遲很明顯，那么使用管道去降低延遲是非常有效的。

6.避免操作大集合的慢命令：如果命令處理頻率過低導(dǎo)致延遲時間增加，這可能是因?yàn)槭褂昧烁邥r間復(fù)雜度的命令操作導(dǎo)致，這意味著每個命令從集合中獲取數(shù)據(jù)的時間增大。 所以減少使用高時間復(fù)雜的命令，能顯著的提高的Redis的性能。

7.限制客戶端連接數(shù)：自Redis2.6以后，允許使用者在配置文件(Redis.conf)maxclients屬性上修改客戶端連接的最大數(shù)，也可以通過在Redis-cli工具上輸入config set maxclients 去設(shè)置最大連接數(shù)。根據(jù)連接數(shù)負(fù)載的情況，這個數(shù)字應(yīng)該設(shè)置為預(yù)期連接數(shù)峰值的110%到150之間，若是連接數(shù)超出這個數(shù)字后，Redis會拒絕并立刻關(guān)閉新來的連接。通過設(shè)置最大連接數(shù)來限制非預(yù)期數(shù)量的連接數(shù)增長，是非常重要的。另外，新連接嘗試失敗會返回一個錯誤消息，這可以讓客戶端知道，Redis此時有非預(yù)期數(shù)量的連接數(shù)，以便執(zhí)行對應(yīng)的處理措施。 上述二種做法對控制連接數(shù)的數(shù)量和持續(xù)保持Redis的性能最優(yōu)是非常重要的