Redis實戰(zhàn)案例是怎樣的,針對這個問題,這篇文章詳細介紹了相對應(yīng)的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

【1】案例一現(xiàn)象:
生產(chǎn)系統(tǒng)剛開始運行階段,系統(tǒng)穩(wěn)定。但是運行了一段時間后,發(fā)現(xiàn)部分時間段系統(tǒng)接口響應(yīng)變慢。查看客戶端日志經(jīng)常會出現(xiàn)如下錯誤:
redis.clients.jedis.exception.JedisConnectionException:java.net.SocketTimeoutException:Read time out
問題定位:執(zhí)行 slowlog 查看慢查詢?nèi)罩荆l(fā)現(xiàn)大量的 keys 命令操作,keys 命令在大量并發(fā)情況下性能非常差,生產(chǎn)環(huán)境,盡量避免使用 keys,接下來找出使用 keys 的代碼做優(yōu)化,直到 time out 問題解決。
192.168.17.46:6386> slowlog get 1) 1) (integer) 22 2) (integer) 1563344158 3) (integer) 10193 4) 1) "SET" 2) "getBatchChapterFiles" 3) "\x0b\xfa\529:\t489761532B\x02-1J\t48976181... (1293 more bytes)" 2) 1) (integer) 21 2) (integer) 1545403066 3) (integer) 10915 4) 1) "GET" 2) "getVolumeChapters#data"
【2】案例二現(xiàn)象:
生產(chǎn)環(huán)境長時間的運行后,經(jīng)常會有接口返回數(shù)據(jù)失敗的情況,或者是從監(jiān)控上發(fā)現(xiàn)數(shù)據(jù)庫壓力某一時間暴增。查看客戶端日志發(fā)現(xiàn)如下錯誤:
redis.clients.jedis.exceptions.JedisConnectionException:Cloud not get a resource from the pool
在redis日志里面發(fā)現(xiàn)報錯:
[2489] 02 Jun 10:43:42 # Error allocating resoures for the client
問題定位:執(zhí)行 client list 命令,發(fā)現(xiàn)大量的 client 的 idle 時間特別長。檢查配置發(fā)現(xiàn) timeout 和 tcp-keepalive(心跳檢測) 均為啟用(均為0),Redis 服務(wù)端沒有有效的機制來確保服務(wù)端連接是否已經(jīng)失效。當(dāng)服務(wù)器與客戶端網(wǎng)絡(luò)發(fā)生閃斷,導(dǎo)致tcp中斷,這種情況下的 client 將會一直被 redis 服務(wù)端所持有,就會出現(xiàn) idle(空閑)時間特長的 client 連接。
解決辦法:設(shè)置 timeout 和 tcp-keepalive 來清理失效的連接。
redis/bin>redis-cli -h 192.168.17.46 -p 6386 info Clients # Clients connected_clients:5000 ---------------偏大 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 192.168.17.46:6386> CONFIG GET timeout 1) "timeout" 2) "0" 192.168.17.46:6386> CONFIG GET tcp-keepalive 1) "tcp-keepalive" 2) "0"
192.168.17.46:6386> client list id=612260747 addr=192.168.17.92:53069 fd=806 name= age=114 idle=21 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 id=612260593 addr=192.168.41.44:38248 fd=381 name= age=131 idle=61 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
字段定義
addr : 客戶端的地址和端口
fd : 套接字所使用的文件描述符
age : 以秒計算的已連接時長
idle : 以秒計算的空閑時長
flags : 客戶端 flag
db : 該客戶端正在使用的數(shù)據(jù)庫 ID
sub : 已訂閱頻道的數(shù)量
psub : 已訂閱模式的數(shù)量
multi : 在事務(wù)中被執(zhí)行的命令數(shù)量
qbuf : 查詢緩沖區(qū)的長度(字節(jié)為單位, 0 表示沒有分配查詢緩沖區(qū))
qbuf-free : 查詢緩沖區(qū)剩余空間的長度(字節(jié)為單位, 0 表示沒有剩余空間)
obl : 輸出緩沖區(qū)的長度(字節(jié)為單位, 0 表示沒有分配輸出緩沖區(qū))
oll : 輸出列表包含的對象數(shù)量(當(dāng)輸出緩沖區(qū)沒有剩余空間時,命令回復(fù)會以字符串對象的形式被入隊到這個隊列里)
omem : 輸出緩沖區(qū)和輸出列表占用的內(nèi)存總量
events : 文件描述符事件
cmd : 最近一次執(zhí)行的命令
【3】案例三現(xiàn)象:
Redis 突然間不能訪問,返回如下錯誤:
redis.client.jedis.exception.JedisDataException:MISCONF Redis is configured to save RDB snapshots,
but is currently not able to persist on disk.Commands that may modify the data set are disabled.
Please check Redis logs for details about the error
問題定位:查看 redis 日志,發(fā)現(xiàn)如下錯誤:Cant save in background:fork:Cannot allocate memory Redis在保存內(nèi)存的數(shù)據(jù)到磁盤時,為了防止主線程假死,會Fork 一個子進程來完成這個保存操作,這個Fork 的子進程需要分配與主進程相同的內(nèi)存,這時候就相當(dāng)于需要的內(nèi)存翻倍了。如果這時候可用內(nèi)存不足以分配需要的內(nèi)存,將會導(dǎo)致Fork 子進程失敗而無法將數(shù)據(jù)持久化到磁盤。修改Linux內(nèi)核參數(shù) vm.overcommit_memeory=1(表示內(nèi)核允許分配所有的物理內(nèi)存,而不管當(dāng)前的內(nèi)存狀態(tài)如何) 問題便可解決。
192.168.17.46:6386> CONFIG GET logfile 1) "logfile" 2) "/home/redis02/redis/log/6386.log"
關(guān)于Redis實戰(zhàn)案例是怎樣的問題的解答就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識。
當(dāng)前文章:Redis實戰(zhàn)案例是怎樣的-創(chuàng)新互聯(lián)
文章源于:http://www.chinadenli.net/article28/docgjp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供搜索引擎優(yōu)化、網(wǎng)站營銷、網(wǎng)站策劃、Google、小程序開發(fā)、商城網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容