redis性能測試及瓶頸分析調(diào)優(yōu)-創(chuàng)新互聯(lián)

一、簡介

Redis(Remote Dictionary Server ),即遠程字典服務,是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫,并提供多種語言的API

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設,無錫企業(yè)網(wǎng)站建設,無錫品牌網(wǎng)站建設,網(wǎng)站定制,無錫網(wǎng)站建設報價,網(wǎng)絡營銷,網(wǎng)絡優(yōu)化,無錫網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè),幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力??沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿,時刻以成就客戶成長自我,堅持不斷學習、思考、沉淀、凈化自己,讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

mysql與redis的區(qū)別:

  • 類型上mysql是關(guān)系型數(shù)據(jù)庫,而redis是緩存數(shù)據(jù)庫;

  • 作用上mysql用于持久化的存儲數(shù)據(jù)到硬盤,功能強大,但速度較慢;而redis用于存儲使用較為頻繁的數(shù)據(jù)到緩存中,讀取速度快

  • mysql和redis因為需求的不同,一般都是配合使用

二、redis的應用
  1. 后端除了用Mysql/Oracle還要用Redis的原因

  • 內(nèi)存和磁盤的時延差

  • Mysql數(shù)據(jù)庫高性能成本高,同樣機器配置下,Redis性能比Mysql數(shù)據(jù)明顯更快

  • 互聯(lián)網(wǎng)公司 100%必用現(xiàn)在 很多項目都在用

  1. 緩存技術(shù)在后端架構(gòu)中的應用

數(shù)據(jù)存儲方式:出于數(shù)據(jù)持久化考慮,數(shù)據(jù)會保存一份在 關(guān)系型數(shù)據(jù)庫;出于高性能角度考慮,數(shù)據(jù)還會存儲一份在 Redis這中內(nèi)存型數(shù)據(jù)庫中

緩存應用流程:

  • 數(shù)據(jù)寫入:一般使用關(guān)系型 數(shù)據(jù)庫

  • 數(shù)據(jù)查詢: 先查 Redis緩存, 沒查到再去查詢數(shù)據(jù)庫

  • 高并發(fā)系統(tǒng)架構(gòu):讀多寫少 用緩存

三、性能測試注意事項 1.緩存預熱

如果程序初次運行,此時由于數(shù)據(jù)尚未加載到緩存,則程序的響應時間會明顯變長。對應到性能測試的現(xiàn)象--程序剛啟動,非常不穩(wěn)定,它的性能 明顯 低于 已經(jīng)運行一段時間的

注意需要測試場景:

1). 測試 緩存沒有的情況, 系統(tǒng)性能是怎么樣的? 以及 多久才能恢復到正常的性能(找開發(fā) - 把數(shù)據(jù)清空,模擬干凈的環(huán)境)

2). 測試 緩存已經(jīng)加載的情況, 系統(tǒng)運行了一段時間,各種業(yè)務場景都執(zhí)行過幾輪之后

2.緩存雪崩

redis目前架構(gòu)來水,不能保障100%數(shù)據(jù)不丟失,因此需要檢查系統(tǒng)是否能容忍緩存出問題。

模擬redis出現(xiàn)故障的場景,1).檢查多少秒之內(nèi),需要恢復redis緩存服務;2). 如果緩存失效,導致高并發(fā)請求懟到數(shù)據(jù)庫,是否會出現(xiàn)異常

3.緩存擊穿

如果查詢的目標是不存在于系統(tǒng)中的數(shù)據(jù),則緩存必然失效,緩存大量Miss,高并發(fā)請求同樣大量懟到數(shù)據(jù)庫,可能會導致系統(tǒng)崩潰

四、Redis瓶頸分析 1.服務器資源

1)機器資源不夠,存不下太多數(shù)據(jù):可考慮搭建redis集群

2)檢查redis自己是否占用了服務器這么多資源,可使用內(nèi)置的info命令,查看到如下多個小節(jié)信息:

  • server :獲取 server 信息

屬性名 屬性值 說明
redis_version 5.0.3 Redis 服務版本號
redisgitsha1 00000000 Git SGA1
redisgitdirty 0 Git dirty flag
redisbuildid 89e87c8197752890 Redis build ID
redis_mode standalone 運行模式,分為:standalone、sentinel、cluster
os Darwin 18.2.0 x86_64 Redis 所在機器的操作系統(tǒng)
arch_bits 64 架構(gòu)(32位或者64位)
multiplexing_api kqueue Redis 所使用的事件處理機制
atomicvar_api atomic-builtin Atomicvar API
gcc_version 4.2.1 編譯 Redis 時所使用的 GCC 版本
process_id 40163 服務進程 ID
run_id c4f8bb49f8214f406725136e6f589b46502a0e00 run_id
tcp_port 6379 監(jiān)聽端口
uptimeinseconds 496059 自 Redis 服務器啟動已來,運行的秒數(shù)
uptimeindays 5 自 Redis 服務啟動已來,運行的天數(shù)
hz 10 serverCron 每秒運行次數(shù)
configured_hz 10  
lru_clock 5452491 以分鐘為單位進行自增的時鐘,用于 LRU 管理
executable /../redis-5.0.3/src/./redis-server 運行文件
config_file /../redis-5.0.3/redis.conf 配置文件
  • clients :獲取 clients 信息,如客戶端連接數(shù)等

connected_clients 1: 當前客戶端連接數(shù)
clientrecentmaxinputbuffer 2: 當前連接的客戶端當中,大輸入緩存
clientrecentmaxoutputbuffer 0: 當前連接的客戶端當中,最長的輸出列表
blocked_clients 0 正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH):的客戶端的數(shù)量
  • memory :獲取 server 的內(nèi)存信息,包括當前內(nèi)存消耗、內(nèi)存使用峰值

used_memory 18813680:由 redis 分配器(標準libc,jemalloc或其他分配器,例如tcmalloc)分配的內(nèi)存總量,以字節(jié)(byte)為單位
usedmemoryhuman 17.94M:redis 分配的內(nèi)存總量
usedmemoryrss 1945600 從操作系統(tǒng)的角度,Redis 已分配的內(nèi)存總量(俗稱常駐集大?。_@個值和 top、ps 等命令的輸出一致。
usedmemoryrss_human 1.86M:操作系統(tǒng)角度,返回 redis 分配的內(nèi)存總量
usedmemorypeak 18900752:redis 的內(nèi)存消耗峰值(以字節(jié)為單位)
usedmemorypeak_human 18.03M:Redis 的內(nèi)存消耗峰值
usedmemorypeak_perc 99.54%:usedmemorypeak在used_memory中所占的百分比
usedmemoryoverhead 11135798:分配用于管理其內(nèi)部數(shù)據(jù)結(jié)構(gòu)的所有開銷的總字節(jié)數(shù)
usedmemorystartup 988448:啟動時消耗的初始內(nèi)存量(以字節(jié)為單位)
usedmemorydataset 7677882:數(shù)據(jù)集的大?。ㄒ宰止?jié)為單位,usedmemory - usedmemory_overhead)
usedmemorydataset_perc 43.07%:usedmemorydataset在凈內(nèi)存(usedmemory-usedmemory_startup)使用量中所占的百分比
allocator_allocated 18780336:分配器分配的內(nèi)存
allocator_active 1907712:分配器活躍的內(nèi)存
allocator_resident 1907712:分配器常駐的內(nèi)存
totalsystemmemory 34359738368:主機擁有的內(nèi)存總量
totalsystemmemory_human 32.00G:主機擁有的內(nèi)存總量
usedmemorylua 37888:Lua引擎使用的字節(jié)數(shù)
usedmemorylua_human 37.00K:以可讀的格式返回Lua引擎使用內(nèi)存
usedmemoryscripts 0  usedmemoryscripts_human 0B  numberofcached_scripts 0  maxmemory 0 配置設置的大可使用內(nèi)存值,默認0,不限制
maxmemory_human 0B:以可讀的格式返回大可使用內(nèi)存值
maxmemory_policy noeviction:內(nèi)存容量超過maxmemory后的處理策略,noeviction當內(nèi)存使用達到閾值的時候,所有引起申請內(nèi)存的命令會報錯
allocatorfragratio 0.10:分配器的碎片率
allocatorfragbytes 18446744073692678992:分配器的碎片大?。ㄒ宰止?jié)為單位)
allocatorrssratio 1.00:分配器常駐內(nèi)存比例
allocatorrssbytes 0:分配器的常駐內(nèi)存大?。ㄒ宰止?jié)為單位)
rssoverheadratio 1.02:常駐內(nèi)存開銷比例
rssoverheadbytes 37888:常駐內(nèi)存開銷大小(以字節(jié)為單位)
memfragmentationratio 0.10:內(nèi)存碎片率,usedmemoryrss 和 used_memory 之間的比率
memfragmentationbytes -16834736:內(nèi)存碎片的大?。ㄒ宰止?jié)為單位)
memnotcountedforevict 112:被驅(qū)逐的大小
memreplicationbacklog 0 repl_backlogmemclientsslaves 0 clients_slavesmemclientsnormal 49694 clients_normalmemaofbuffer 112 aof時,占用的緩沖mem_allocator libc 內(nèi)存分配器(在編譯時選擇)
activedefragrunning 0:碎片整理是否處于活動狀態(tài)
lazyfreependingobjects 0:等待釋放的對象數(shù)(由于使用ASYNC選項調(diào)用UNLINK或FLUSHDB和FLUSHALL)
  • persistence :獲取 server 的持久化配置信息

loading 0 記錄服務器是否正在載入持久化文件
rdbchangessincelastsave 0 最近一次成功創(chuàng)建持久化文件之后,經(jīng)過了多少秒
rdbbgsavein_progress 0 記錄了服務器是否正在創(chuàng)建 RDB 文件
rdblastsave_time 1582508875 最近一次成功創(chuàng)建 RDB 文件的 UNIX 時間戳
rdblastbgsave_status ok 記錄最近一次創(chuàng)建 RDB 文件的狀態(tài),是成功還是失敗
rdblastbgsavetimesec 1 記錄了最近一次創(chuàng)建 RDB 文件耗費的秒數(shù)
rdbcurrentbgsavetimesec -1 如果正在創(chuàng)建 RDB 文件,記錄當前的創(chuàng)建操作已經(jīng)耗費的秒數(shù)
rdblastcow_size 0 上一次RBD保存操作期間寫時復制的大小(以字節(jié)為單位)
aof_enabled 1 AOF是否開啟
aofrewritein_progress 0 記錄了是否正在創(chuàng)建 AOF 文件
aofrewritescheduled 0 記錄了 RDB 文件創(chuàng)建完畢之后,是否需要執(zhí)行 AOF 重寫操作
aoflastrewritetimesec -1 最近一次創(chuàng)建 AOF 文件耗費的秒數(shù)
aofcurrentrewritetimesec -1 如果正在創(chuàng)建 AOF 文件,那么記錄當前的創(chuàng)建操作耗費的秒數(shù)
aoflastbgrewrite_status ok 記錄了最近一次創(chuàng)建 AOF 文件的狀態(tài),是成功還是失敗
aoflastwrite_status ok AOF的最后寫入操作的狀態(tài),是成功還是失敗
aoflastcow_size 0 上一次AOF保存操作期間寫時復制的大?。ㄒ宰止?jié)為單位)
aofcurrentsize 4747340 AOF 文件當前的大小
aofbasesize 4746996 最近一次啟動或重寫時的AOF文件大小
aofpendingrewrite 0 記錄了是否有 AOF 重寫操作在等待 RDB 文件創(chuàng)建完畢之后執(zhí)行
aofbufferlength 0 AOF緩沖區(qū)的大小
aofrewritebuffer_length 0 AOF 重寫緩沖區(qū)的大小
aofpendingbio_fsync 0 后臺 I/O 隊列里面,等待執(zhí)行的 fsync 數(shù)量
aofdelayedfsync 0 被延遲的 fsync 調(diào)用數(shù)量,如果該值比較大,可以開啟參數(shù):no-appendfsync-on-rewrite=yes
  • stats :獲取 server 的一些基本統(tǒng)計信息,如處理過的連接數(shù)量等# 緩存命中次數(shù)越高,代表緩存起到了很大的作用。如:keyspace_hits:9808 命中 keyspace_misses:1 miss

totalconnectionsreceived 11 服務器接受的連接總數(shù)totalcommandsprocessed 48 服務器已執(zhí)行的命令數(shù)量instantaneousopsper_sec 0 服務器每秒鐘執(zhí)行的命令數(shù)量totalnetinput_bytes 1312 啟動以來,流入的字節(jié)總數(shù)totalnetoutput_bytes 114800 啟動以來,流出的字節(jié)總數(shù)instantaneousinputkbps 0.00 接收輸入的速率(每秒)instantaneousoutputkbps 0.00 輸出的速率(每秒)rejected_connections 0 由于maxclients限制而被拒絕的連接數(shù)sync_full 0 與slave full sync的次數(shù)syncpartialok 0 接受的部分重新同步(psync)請求的數(shù)量syncpartialerr 0 被拒絕的部分重新同步(psync)請求的數(shù)量expired_keys 0 key過期事件總數(shù)expiredstaleperc 0.00 過期的比率expiredtimecapreachedcount 0 過期計數(shù)evicted_keys 0 由于大內(nèi)存限制而被驅(qū)逐的key數(shù)量keyspace_hits 6 key命中次數(shù)keyspace_misses 0 key未命中次數(shù)pubsub_channels 0 發(fā)布/訂閱頻道的數(shù)量pubsub_patterns 0 發(fā)布/訂閱的模式數(shù)量latestforkusec 803 最近一次 fork() 操作耗費的毫秒數(shù)(以微秒為單位)migratecachedsockets 0 為遷移而打開的套接字數(shù)slaveexpirestracked_keys 0 跟蹤過期key數(shù)量(僅適用于可寫從)activedefraghits 0 活躍碎片執(zhí)行的值重新分配的數(shù)量activedefragmisses 0 活躍碎片執(zhí)行的中止值重新分配的數(shù)量activedefragkey_hits 0 活躍碎片整理的key數(shù)activedefragkey_misses 0 活躍碎片整理過程跳過的key數(shù)
  • replication: 獲取 server 的主從配置信息

role master 角色(master、slave),一個從服務器也可能是另一個服務器的主服務器
connected_slaves 1 連接slave實例的個數(shù)
slave0 ip=127.0.0.1,port=6380,state=online,offset=14,lag=1 連接的slave的信息
master_replid 899b9814f2e841ca194dcc2620c83aa5df0abc10 服務器的復制ID
master_replid2 0000000000000000000000000000000000000000 第二服務器復制ID,用于故障轉(zhuǎn)移后的PSYNC,用于集群等高可用之后主從節(jié)點的互換
masterreploffset 14 復制偏移量1
secondreploffset -1 第二服務器復制偏移量2
replbacklogactive 1 復制緩沖區(qū)狀態(tài)
replbacklogsize 1048576 復制緩沖區(qū)的大?。ㄒ宰止?jié)為單位)
replbacklogfirstbyteoffset 1 復制緩沖區(qū)的偏移量,標識當前緩沖區(qū)可用范圍
replbackloghistlen 14 復制緩沖區(qū)中數(shù)據(jù)的大?。ㄒ宰止?jié)為單位)
  • cpu: 獲取 server 的 CPU 使用信息。

usedcpusys 2.559564 消耗的系統(tǒng)CPU
usedcpuuser 0.878593 消耗的用戶CPU
usedcpusys_children 0.001414 后臺進程占用的系統(tǒng)CPU
usedcpuuser_children 0.000510 后臺進程占用的用戶CPU
  • keyspace: 獲取 server 中各個 DB 的 key 的數(shù)量

  • cluster: 獲取集群節(jié)點信息,僅在開啟集群后可見

2.redis存在大量連接

通過 info 查看連接數(shù)量,redis連接數(shù)過多會影響性能

3.響應時間

1)info commandstats 獲取每種命令的統(tǒng)計信息,查看Redis 哪些命令操作 比較耗時間

  • calls: 次數(shù)

  • usec: 總時間

  • usec_per_call:平均時間

2)Redis 慢查詢?nèi)罩?/p>

配置文件里面可進行設置如下兩個參數(shù):

  • slowlog-log-slower-than 10000:單位 微秒指定執(zhí)行時間超過多少微秒的命令會被記錄到日志上

  • slowlog-max-len 128:服務器上最多保存慢查詢?nèi)罩镜臈l數(shù)

查看慢查詢?nèi)罩荆簊lowlog get

影響相應時間的因素:

  • 持久化:持久化對于性能有直接的影響,因為不僅要操作內(nèi)存,還要操作磁盤 【會直接影響命令的處理時間】

  • 有大量的數(shù)據(jù)過期失效:內(nèi)部 數(shù)據(jù)過期機制,Redis 自動刪除 ,同樣 需要消耗資源

五、Redis 監(jiān)控體系 1.采集服務部署

1)官網(wǎng)下載redis_exporter:https://github.com/oliver006/redis_exporter

2)下載后進行解壓

3)啟動(在解壓后的路徑操作)

前臺啟動:./redis_exporter -redis.addr 127.0.0.1:6379

后臺啟動:nohup ./redis_exporter -redis.addr 127.0.0.1:6379 >nginx_exporter.log 2>&1 &

啟動后,默認端口 9121,通過采集服務所在的IP+端口可以訪問到采集的數(shù)據(jù)內(nèi)容

參數(shù)說明:

  • -redis.addr:指明一個或多個 Redis 節(jié)點的地址,多個節(jié)點使用逗號分隔,默認為 redis://localhost:6379

  • -redis.password:驗證 Redis 時使用的密碼;

  • -redis.file:包含一個或多個redis 節(jié)點的文件路徑,每行一個節(jié)點,此選項與 -redis.addr 互斥。

  • -web.listen-address:監(jiān)聽的地址和端口,默認為 0.0.0.0:9121

2.Prometheus配置

修改配置文件prometheus.yml,新增如下內(nèi)容,修改后重啟prometheus服務;

# 以下為新增內(nèi)容  
- job_name: "redis"    
  static_configs:      
    - targets: ['redis機器ip:9121']  # 這個就是你的redis_exporter啟動的端口
3.grafana配置

導入grafana_prometheus_redis_dashboard.json看板模板

https://download.csdn.net/download/qq_38571773/87387394

六、Redis 調(diào)優(yōu)建議

Redis本身的性能足夠逆天,大部分的問題在于 開發(fā)人員沒有用好Redis

  1. pipelining 管道批處理:比如 將大量數(shù)據(jù) 加載到 redis就可以用 管道

  1. Redis處理命令時采取的單線程,所以不需要大量 Redis連接

  1. Redis的應用場景對速度要求很高,采用合理的數(shù)據(jù)類型,更快速的操作

例如,采用字符串 string 類型,每一次查詢 必須從redis 查詢所有的內(nèi)容,會增加 網(wǎng)絡消耗,增加處理的資源占用;采用 hash,可以 將 用戶信息 分為多個key進行存放,查詢效率高

  1. 盡量避免讓開發(fā)使用復雜的命令

例如 keys,Redis 里面,標記為 O(1) 命令,代表速度快 ,O(n)、 O(logn) 速度較慢。如果你看到慢查詢?nèi)罩?里邊大量的命令,都是 非 O(1),則需要開發(fā)優(yōu)化命令

你是否還在尋找穩(wěn)定的海外服務器提供商?創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源,準確流量調(diào)度確保服務器高可用性,企業(yè)級服務器適合批量采購,新人活動首月15元起,快前往官網(wǎng)查看詳情吧

分享標題:redis性能測試及瓶頸分析調(diào)優(yōu)-創(chuàng)新互聯(lián)
本文URL:http://muchs.cn/article24/dchdje.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供建站公司全網(wǎng)營銷推廣、定制網(wǎng)站網(wǎng)站設計、品牌網(wǎng)站建設、小程序開發(fā)

廣告

聲明:本網(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)

成都網(wǎng)站建設