本文開始會(huì)講解一下redis的基本優(yōu)化，然后會(huì)舉一些優(yōu)化示例代碼或?qū)嵗?/strong>。最后講解一下，默認(rèn)啟動(dòng)redis時(shí)，所報(bào)的一些警示錯(cuò)誤。
一、優(yōu)化的一些建議
1、盡量使用短的key
當(dāng)然在精簡(jiǎn)的同時(shí)，不要為了key的“見名知意”。對(duì)于value有些也可精簡(jiǎn)，比如性別使用0、1。
2、避免使用keys *
keys *, 這個(gè)命令是阻塞的，即操作執(zhí)行期間，其它任何命令在你的實(shí)例中都無(wú)法執(zhí)行。當(dāng)redis中key數(shù)據(jù)量小時(shí)到無(wú)所謂，數(shù)據(jù)量大就很糟糕了。所以我們應(yīng)該避免去使用這個(gè)命令?？梢匀ナ褂肧CAN,來(lái)代替。
3、在存到Redis之前先把你的數(shù)據(jù)壓縮下
redis為每種數(shù)據(jù)類型都提供了兩種內(nèi)部編碼方式，在不同的情況下redis會(huì)自動(dòng)調(diào)整合適的編碼方式。
4、設(shè)置key有效期
我們應(yīng)該盡可能的利用key有效期。比如一些臨時(shí)數(shù)據(jù)（短信校驗(yàn)碼），過(guò)了有效期Redis就會(huì)自動(dòng)為你清除！
5、選擇回收策略(maxmemory-policy)
當(dāng)Redis的實(shí)例空間被填滿了之后，將會(huì)嘗試回收一部分key。根據(jù)你的使用方式，強(qiáng)烈建議使用 volatile-lru（默認(rèn)） 策略——前提是你對(duì)key已經(jīng)設(shè)置了超時(shí)。但如果你運(yùn)行的是一些類似于 cache 的東西，并且沒有對(duì) key 設(shè)置超時(shí)機(jī)制，可以考慮使用 allkeys-lru 回收機(jī)制，具體講解查看 。maxmemory-samples 3 是說(shuō)每次進(jìn)行淘汰的時(shí)候 會(huì)隨機(jī)抽取3個(gè)key 從里面淘汰最不經(jīng)常使用的（默認(rèn)選項(xiàng)）。
1 2 3 4 5 6 7 | maxmemory-policy 六種方式 :volatile-lru：只對(duì)設(shè)置了過(guò)期時(shí)間的key進(jìn)行LRU（默認(rèn)值）allkeys-lru ： 是從所有key里 刪除 不經(jīng)常使用的keyvolatile-random：隨機(jī)刪除即將過(guò)期keyallkeys-random：隨機(jī)刪除volatile-ttl ： 刪除即將過(guò)期的noeviction ： 永不過(guò)期，返回錯(cuò)誤 |
6、使用bit位級(jí)別操作和byte字節(jié)級(jí)別操作來(lái)減少不必要的內(nèi)存使用
1 2 | bit位級(jí)別操作：GETRANGE, SETRANGE, GETBIT and SETBITbyte字節(jié)級(jí)別操作：GETRANGE and SETRANGE |
7、盡可能地使用hashes哈希存儲(chǔ)
8、當(dāng)業(yè)務(wù)場(chǎng)景不需要數(shù)據(jù)持久化時(shí)，關(guān)閉所有的持久化方式可以獲得最佳的性能
數(shù)據(jù)持久化時(shí)需要在持久化和延遲/性能之間做相應(yīng)的權(quán)衡.
9、想要一次添加多條數(shù)據(jù)的時(shí)候可以使用管道
10、限制redis的內(nèi)存大小（64位系統(tǒng)不限制內(nèi)存，32位系統(tǒng)默認(rèn)最多使用3GB內(nèi)存）
數(shù)據(jù)量不可預(yù)估，并且內(nèi)存也有限的話，盡量限制下redis使用的內(nèi)存大小，這樣可以避免redis使用swap分區(qū)或者出現(xiàn)OOM錯(cuò)誤。（使用swap分區(qū)，性能較低，如果限制了內(nèi)存，當(dāng)?shù)竭_(dá)指定內(nèi)存之后就不能添加數(shù)據(jù)了，否則會(huì)報(bào)OOM錯(cuò)誤。可以設(shè)置maxmemory-policy，內(nèi)存不足時(shí)刪除數(shù)據(jù)）
11、SLOWLOG [get/reset/len]
1 2 | slowlog-log-slower-than 它決定要對(duì)執(zhí)行時(shí)間大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的命令進(jìn)行記錄。slowlog-max-len 它決定 slowlog 最多能保存多少條日志，當(dāng)發(fā)現(xiàn)redis性能下降的時(shí)候可以查看下是哪些命令導(dǎo)致的。 |
二、管道測(cè)試
redis的管道功能在命令行中沒有，但是redis是支持管道的，在java的客戶端(jedis)中是可以使用的：
示例代碼：
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 | //注：具體耗時(shí)，和自身電腦有關(guān)(博主是在虛擬機(jī)中運(yùn)行的數(shù)據(jù))/** * 不使用管道初始化1W條數(shù)據(jù) * 耗時(shí)：3079毫秒 * @throws Exception */@Testpublic void NOTUsePipeline() throws Exception { Jedis jedis = JedisUtil.getJedis(); long start_time = System.currentTimeMillis(); for (int i = 0; i < 10000; i++) { jedis.set("aa_"+i, i+""); } System.out.println(System.currentTimeMillis()-start_time);}/** * 使用管道初始化1W條數(shù)據(jù) * 耗時(shí)：255毫秒 * @throws Exception */@Testpublic void usePipeline() throws Exception { Jedis jedis = JedisUtil.getJedis(); long start_time = System.currentTimeMillis(); Pipeline pipelined = jedis.pipelined(); for (int i = 0; i < 10000; i++) { pipelined.set("cc_"+i, i+""); } pipelined.sync();//執(zhí)行管道中的命令 System.out.println(System.currentTimeMillis()-start_time);} |
hash的應(yīng)用
示例：我們要存儲(chǔ)一個(gè)用戶信息對(duì)象數(shù)據(jù)，包含以下信息：
key為用戶ID，value為用戶對(duì)象（姓名，年齡，生日等）如果用普通的key/value結(jié)構(gòu)來(lái)存儲(chǔ)，主要有以下2種存儲(chǔ)方式：
1、將用戶ID作為查找key,把其他信息封裝成一個(gè)對(duì)象以序列化的方式存儲(chǔ)
缺點(diǎn)：增加了序列化/反序列化的開銷，引入復(fù)雜適應(yīng)系統(tǒng)（Complex adaptive system）修改其中一項(xiàng)信息時(shí)，需要把整個(gè)對(duì)象取回，并且修改操作需要對(duì)并發(fā)進(jìn)行保護(hù)。
2、用戶信息對(duì)象有多少成員就存成多少個(gè)key-value對(duì)
雖然省去了序列化開銷和并發(fā)問(wèn)題，但是用戶ID為重復(fù)存儲(chǔ)。
Redis提供的Hash很好的解決了這個(gè)問(wèn)題，提供了直接存取這個(gè)Map成員的接口。Key仍然是用戶ID, value是一個(gè)Map，這個(gè)Map的key是成員的屬性名，value是屬性值。( 內(nèi)部實(shí)現(xiàn)：Redis Hashd的Value內(nèi)部有2種不同實(shí)現(xiàn)，Hash的成員比較少時(shí)Redis為了節(jié)省內(nèi)存會(huì)采用類似一維數(shù)組的方式來(lái)緊湊存儲(chǔ)，而不會(huì)采用真正的HashMap結(jié)構(gòu)，對(duì)應(yīng)的value redisObject的encoding為zipmap,當(dāng)成員數(shù)量增大時(shí)會(huì)自動(dòng)轉(zhuǎn)成真正的HashMap,此時(shí)encoding為ht )。
Instagram內(nèi)存優(yōu)化
Instagram可能大家都已熟悉，當(dāng)前火熱的拍照App，月活躍用戶3億。四年前Instagram所存圖片3億多時(shí)需要解決一個(gè)問(wèn)題：想知道每一張照片的作者是誰(shuí)（通過(guò)圖片ID反查用戶UID），并且要求查詢速度要相當(dāng)?shù)膲K，如果把它放到內(nèi)存中使用String結(jié)構(gòu)做key-value:
1 2 3 | HSET "mediabucket:1155" "1155315" "939"HGET "mediabucket:1155" "1155315""939" |
測(cè)試：1百萬(wàn)數(shù)據(jù)會(huì)用掉70MB內(nèi)存，3億張照片就會(huì)用掉21GB的內(nèi)存。當(dāng)時(shí)(四年前)最好是一臺(tái)EC2的 high-memory 機(jī)型就能存儲(chǔ)（17GB或者34GB的，68GB的太浪費(fèi)了）,想把它放到16G機(jī)型中還是不行的。
Instagram的開發(fā)者向Redis的開發(fā)者之一Pieter Noordhuis詢問(wèn)優(yōu)化方案，得到的回復(fù)是使用Hash結(jié)構(gòu)。具體的做法就是將數(shù)據(jù)分段，每一段使用一個(gè)Hash結(jié)構(gòu)存儲(chǔ).
由于Hash結(jié)構(gòu)會(huì)在單個(gè)Hash元素在不足一定數(shù)量時(shí)進(jìn)行壓縮存儲(chǔ)，所以可以大量節(jié)約內(nèi)存。這一點(diǎn)在上面的String結(jié)構(gòu)里是不存在的。而這個(gè)一定數(shù)量是由配置文件中的hash-zipmap-max-entries參數(shù)來(lái)控制的。經(jīng)過(guò)實(shí)驗(yàn)，將hash-zipmap-max-entries設(shè)置為1000時(shí)，性能比較好，超過(guò)1000后HSET命令就會(huì)導(dǎo)致CPU消耗變得非常大。
1 2 3 | HSET "mediabucket:1155" "1155315" "939"HGET "mediabucket:1155" "1155315""939" |
測(cè)試：1百萬(wàn)消耗16MB的內(nèi)存。總內(nèi)存使用也降到了5GB。當(dāng)然我們還可以優(yōu)化，去掉mediabucket:key長(zhǎng)度減少了12個(gè)字節(jié)。
1 2 3 | HSET "1155" "315" "939"HGET "1155" "315""939" |
三、優(yōu)化案例
1、修改linux中TCP監(jiān)聽的最大容納數(shù)量
1 2 | WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. |
在高并發(fā)環(huán)境下你需要一個(gè)高backlog值來(lái)避免慢客戶端連接問(wèn)題。注意Linux內(nèi)核默默地將這個(gè)值減小到/proc/sys/net/core/somaxconn的值，所以需要確認(rèn)增大somaxconn和tcp_max_syn_backlog兩個(gè)值來(lái)達(dá)到想要的效果。
echo 511 > /proc/sys/net/core/somaxconn
注意：這個(gè)參數(shù)并不是限制redis的最大鏈接數(shù)。如果想限制redis的最大連接數(shù)需要修改maxclients，默認(rèn)最大連接數(shù)為10000
2、修改linux內(nèi)核內(nèi)存分配策略
1 2 3 | 錯(cuò)誤日志：WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1 |
redis在備份數(shù)據(jù)的時(shí)候，會(huì)fork出一個(gè)子進(jìn)程，理論上child進(jìn)程所占用的內(nèi)存和parent是一樣的，比如parent占用的內(nèi)存為8G，這個(gè)時(shí)候也要同樣分配8G的內(nèi)存給child,如果內(nèi)存無(wú)法負(fù)擔(dān)，往往會(huì)造成redis服務(wù)器的down機(jī)或者IO負(fù)載過(guò)高，效率下降。所以內(nèi)存分配策略應(yīng)該設(shè)置為 1（表示內(nèi)核允許分配所有的物理內(nèi)存，而不管當(dāng)前的內(nèi)存狀態(tài)如何）。
內(nèi)存分配策略有三種
可選值：0、1、2。
0， 表示內(nèi)核將檢查是否有足夠的可用內(nèi)存供應(yīng)用進(jìn)程使用；如果有足夠的可用內(nèi)存，內(nèi)存申請(qǐng)?jiān)试S；否則，內(nèi)存申請(qǐng)失敗，并把錯(cuò)誤返回給應(yīng)用進(jìn)程。
1， 不管需要多少內(nèi)存，都允許申請(qǐng)。
2， 只允許分配物理內(nèi)存和交換內(nèi)存的大小(交換內(nèi)存一般是物理內(nèi)存的一半)。
3、關(guān)閉Transparent Huge Pages(THP)
THP會(huì)造成內(nèi)存鎖影響redis性能，建議關(guān)閉
1 2 3 4 | Transparent HugePages ：用來(lái)提高內(nèi)存管理的性能Transparent Huge Pages在32位的RHEL 6中是不支持的執(zhí)行命令 echo never > /sys/kernel/mm/transparent_hugepage/enabled把這條命令添加到這個(gè)文件中/etc/rc.local |
參考：http://blog.xiaoxiaomo.com/2016/05/02/Redis-優(yōu)化詳解/
聯(lián)系客服
