一、簡介

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

成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),無錫企業(yè)網(wǎng)站建設(shè),無錫品牌網(wǎng)站建設(shè),網(wǎng)站定制,無錫網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,無錫網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?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的應(yīng)用

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

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

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

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

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

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

緩存應(yīng)用流程：

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

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

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

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

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

注意需要測試場景：

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

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

2.緩存雪崩

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

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

3.緩存擊穿

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

四、Redis瓶頸分析 1.服務(wù)器資源

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

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

• server ：獲取 server 信息

屬性名 屬性值 說明
redis_version 5.0.3 Redis 服務(wù)版本號
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 服務(wù)進程 ID
run_id c4f8bb49f8214f406725136e6f589b46502a0e00 run_id
tcp_port 6379 監(jiān)聽端口
uptimeinseconds 496059 自 Redis 服務(wù)器啟動已來，運行的秒數(shù)
uptimeindays 5 自 Redis 服務(wù)啟動已來，運行的天數(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 配置設(shè)置的大可使用內(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 記錄服務(wù)器是否正在載入持久化文件
rdbchangessincelastsave 0 最近一次成功創(chuàng)建持久化文件之后，經(jīng)過了多少秒
rdbbgsavein_progress 0 記錄了服務(wù)器是否正在創(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保存操作期間寫時復(fù)制的大?。ㄒ宰止?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保存操作期間寫時復(fù)制的大?。ㄒ宰止?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 服務(wù)器接受的連接總數(shù)totalcommandsprocessed 48 服務(wù)器已執(zhí)行的命令數(shù)量instantaneousopsper_sec 0 服務(wù)器每秒鐘執(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），一個從服務(wù)器也可能是另一個服務(wù)器的主服務(wù)器
connected_slaves 1 連接slave實例的個數(shù)
slave0 ip=127.0.0.1,port=6380,state=online,offset=14,lag=1 連接的slave的信息
master_replid 899b9814f2e841ca194dcc2620c83aa5df0abc10 服務(wù)器的復(fù)制ID
master_replid2 0000000000000000000000000000000000000000 第二服務(wù)器復(fù)制ID，用于故障轉(zhuǎn)移后的PSYNC，用于集群等高可用之后主從節(jié)點的互換
masterreploffset 14 復(fù)制偏移量1
secondreploffset -1 第二服務(wù)器復(fù)制偏移量2
replbacklogactive 1 復(fù)制緩沖區(qū)狀態(tài)
replbacklogsize 1048576 復(fù)制緩沖區(qū)的大?。ㄒ宰止?jié)為單位）
replbacklogfirstbyteoffset 1 復(fù)制緩沖區(qū)的偏移量，標識當前緩沖區(qū)可用范圍
replbackloghistlen 14 復(fù)制緩沖區(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.響應(yīng)時間

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

• calls: 次數(shù)

• usec: 總時間

• usec_per_call:平均時間

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

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

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

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

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

影響相應(yīng)時間的因素：

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

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

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

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，通過采集服務(wù)所在的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服務(wù)；

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

3.grafana配置

導(dǎo)入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就可以用 管道

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

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

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

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

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

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

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

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、全網(wǎng)營銷推廣、定制網(wǎng)站、網(wǎng)站設(shè)計、品牌網(wǎng)站建設(shè)、小程序開發(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)