[TOC] redis-cli +命令 直接執行命令 `redis-cli client list |grep -v "omem=0"` 這是配合了Linux命令，執行了redis命令 > * redis是單線程架構，所有的讀寫操作都是在是在一 條主線程上完成的。 > * 大的數據結構的拆分，避免使用keys ，sort命令 > * config set 動態的設置redis參數 > * redis bind 配置是連接redis綁定的網卡，如果綁定內網卡，則只能由內網卡對應的IP訪問，外網同理。 * * * * * ### 1. 阻塞 1. 對于較大數據進行復雜度O（n）的操作 slowlog get<n> 查詢出最近n條慢查詢命令。解決辦法： 1）修改為復雜度低的操作，禁用keys、sort等命令 2）查分較大的數據結構 2. 持久化造成的阻塞 1）fork阻塞 在RDB和AOF重寫時，fork創建子進程，fork操作時間過長導致主線程的阻塞。info stats命令查看狀態。 2）AOF 文件刷盤操作每秒執行一次，如果超過2秒，則阻塞后臺進程直到fsync操作完成。 * * * * * ### 2. CPU、內存 * 單線程的Redis處理命令時只能使用一個CPU。而CPU 飽和是指Redis把單核CPU使用率跑到接近100%。使用 top命令很容易識別出對應Redis進程的CPU使用率。 * redis對內存的消耗主要包括：自身內存+對象內存+內存碎片 * redis是典型的cpu密集型應用，最好不要和其他多核密集型應用部署到一起。 * 為了充分利用多核CPU，通常一臺機器部署多臺redis實例。為了充分利用多核CPU，通常一臺機器部署多臺redis實例。子進程重寫時對單核CPU使用率通常在90%以上，父進程與子進程將產生激烈CPU競爭，極大影響Redis穩定性。因此對于開啟了持久化或參與復制的主節點不建議綁定CPU。 * * * * * #### 2.1內存信息 * redis使用內存分為進程和子進程消耗兩塊 * info memory 命令獲取內存使用相關信息，下面是執行命令得到的結果 ~~~ 127.0.0.1:6379> info memory Memory used_memory:2154128 ---由 Redis 分配器分配的內存總量，以字節（byte）為單位，redis存儲的所有數據所占內存 used_memory_human:2.05M ---直觀可讀的內存總量 used_memory_rss:4263936---從操作系統的角度，返回 Redis 已分配的內存總量（俗稱常駐集大小） used_memory_rss_human:4.07M used_memory_peak:2301128 used_memory_peak_human:2.19M total_system_memory:2098147328 total_system_memory_human:1.95G used_memory_lua:37888---Lua 引擎所使用的內存大小（以字節為單位） used_memory_lua_human:37.00K maxmemory:0 maxmemory_human:0B maxmemory_policy:noeviction mem_fragmentation_ratio:1.98---used_memory_rss和used_memory以及它們的比值 mem_allocator:libc ~~~ 說明： * 當mem_fragmentation_ratio>1時說明used_memory_rss-used_memory多出來的內存沒有用于數據存儲，而是別內存碎片消耗，越大說明碎片越嚴重。 * 當mem_fragmentation_ratio<1時說明這種情況一般出現在操作系統把Redis內存交換（Swap）到硬盤導致，由于硬盤速度遠遠慢于內存，Redis性能會變得很差，甚至僵死。 #### 內存劃分  > 1. 對象內存：key對象和value對象 > 2. 緩沖內存：客戶端緩沖區、復制積壓緩沖區和AOF緩沖區 * * * * * #### 2.2內存占用 * 對象內存是占用redis內存最大的，存儲著用戶的數據。 * 緩沖內存（客戶端緩沖、復制積壓緩沖、AOF緩沖） #### 2.3內存管理 1. 設置內存上限 通過設置maxmemory參數限制最大可用內內存，或者config set maxmemory進行動態修改。 1）用于緩存：當超出內存上限maxmemory時，使用2）LRU等刪除策略釋放空間 3）防止所用內存超過服務器內存 4）方便實現一臺服務器部署多個redis進程的內存控制 2. 內存回收 1）刪除過期鍵對象 redis的所用鍵都可以設置過期屬性，內部保存在過期字典中。 2）內存溢出控制 當redis所用內存達到maxmemory上限時會觸發相應的溢出控制策略。 * * * * * #### 2.4 內存優化 * redisObject結構體： redis存儲的所有值對象在內部定義為redisObject結構體。redisObject對象包含以下屬性 1）type ：表示當前對象使用的數據類型redis主要支持五種數據類型（string、hash、List、set、zset） 2) encode：表示當前對象采用哪種數據結構實現 3）lru：記錄對象最后一次被訪問的時間 4）refcount：記錄當前對象被引用次數，當refcount=0時，可以安全回收對象空間。 5）ptr：對象的數據內容相關，如果是整數，直接存儲數據，否則是指針 * 開發時盡量少對字符串頻繁修改操作，例如append、setrange，用set 修改字符串，降低預分配帶來的內存浪費和內存碎片。 * 利用hash結構對大規模的鍵進行重構，使用zipList編碼可以減少內存消耗，如果是用hashtable編碼反而會增加內存的消耗。---ziplist+hash優化keys 1. 如果有多個redis實例，盡量保證同一時刻只有一個子進程在工作 2. 避免大量寫入時，子進程做重寫操作，這樣到這父進程維護大量的副本，造成內存消耗。 * * * * * ### 3. 數據持久化 * redis是內存數據庫，所有運行時的數據都存在于內存中，如果redis服務器被關閉或者重啟，所有數據將會消失，所以對數據進行持久化操作在某些環境下是非常必要的。redis的持久化操作有兩種： 1）RDB（redis DB）:在磁盤上以二進制文件的形式保存所有redis數據，文件名dump.rdb。 2）AOF（append only file）：保存命令，文件名appendonly.aof。 * * * * * #### 3.1 RDB * 讀取RDB恢復數據較快，由于數據量大，無法實時持久化。 將redis數據寫到磁盤，覆蓋原來的dump.rdb文件，這種數據的寫入可以手工的觸發，也可以通過配置文件自動執行。 1. 手動觸發寫入磁盤 1）save 命令：執行這個命令會阻塞redis服務器，服務器不能處理客戶端請求。 2）bgsave：會創建子進程完成寫入磁盤操作，會阻塞redis服務，阻塞時間為fork子進程所花費的時間，雖然時間可能很短，在高并發的業務場景下，可能也會拖慢數萬條命令的執行。但是寫入速度慢于save命令。 * rdb采用LZF算法存儲，所有dump.rdb文件比內存中的數據小的多 * rdbacompression ：yes表示開啟壓縮，no，不壓縮 #### 3.2 fork進程開銷 * info stats 命令  ~~~ total_connections_received:7 # redis一共服務了多少個連接 total_commands_processed:41 # redis處理多少個命令 latest_fork_usec:209 # 最近一次fork子進程所花費的時間（微秒） ~~~ * save命令適合于在客戶端請求少的情況下使用，很快的完成數據的備份，bgsave雖然備份速度較慢但是不會阻塞redis服務器，應該根據實際的情況選擇不同的備份命令。 2. 配置文件的方式備份 在redis的配置文件中redis.conf中默認開啟了RDB備份模式。文件中有如下配置 save 900 1 save 300 10 save 60 10000 save <秒> <操作次數> * 表示在規定秒數內，如果有N個鍵值對發生變化，則觸發備份，上面的條件任意一個滿足就會觸發，并且這些條件不會疊加。在完成一次備份產生dump.rdb文件后，時間和次數計數器將會被清零。 * * * * * #### 3.3 AOF * AOF在redis.conf配置文件中默認默認不開啟--- ~~~ appendonly no ---yes 開啟 appendfsync everysec ---默認每秒持久化一次 auto-aof-rewrite-percentage 100 --- .aofwen文件大小超過一倍時發生重寫 auto-aof-rewrite-min-size 64mb ---.aof文件大小超過64M發生重寫 no-appendfsync-on-rewrite ~~~ #### 3.4 改善fork消耗性能 1. 優先使用物理機或者高效支持虛擬化的技術，避免使用Xen。 2. 控制redis實例最大可用內存，fork耗時和內存成正比，線上redis實例內存控制在10G以內。 > * no-appendfsync-on-rewrite：指定是否在后臺aof文件rewrite期間調用fsync，默認為no，表示要調用fsync（無論后臺是否有子進程在刷盤）。Redis在后臺寫RDB文件或重寫afo文件期間會存在大量磁盤IO，此時，在某些linux系統中，調用fsync可能會阻塞。 * AOF重寫：為了控制appendonly.aof文件的大小，redis提供了重寫功能，重寫會重整一些命令，減少命令的數量，并且使得數據不發生改變也不會阻塞redis服務。 * AOF持久化會將命令追加到appendonly.aof文件的末尾，只要redis重新執行這些命令就可以還原數據，在一些由于誤操作導致數據丟失，可以將appendonly.aof文件中的操作刪掉來恢復數據。最開始命令被寫入內存緩沖區中，等到緩沖區被填滿或者用戶調用fsync、fdatasync命令才將命令寫入到磁盤文件。觸發命令持久化有三種方式always、everysec、no。 1. always：redis服務器每當接受一條命令都會調用fdatasync命令，將緩沖區的命令追加到文件中。這種方式可以保證數據的零丟失。 2. everysec：redis服務器每秒鐘都會調用fdatasync命令，將緩沖區的命令追加到文件中。這種方式可以最多會丟失一秒鐘的數據。 3. no：服務器不主動調用fdatasync命令，由操作系統決定何時將緩沖區的命令追加到文件當中去，所以發生意外的時候丟失的數據是無法預料的。 * 這兩種持久化方式可以同時使用，根據需要判斷，但是還原數據時優先使用AOF持久化。可見，從持久化角度講，always是最安全的。從效率上講，no是最快的。而redis默認設置進行了折中，選擇了everysec。合情合理。 bgrewriteaof機制，在一個子進程中進行aof的重寫，從而不阻塞主進程對其余命令的處理，同時解決了aof文件過大問題。 現在問題出現了，同時在執行bgrewriteaof操作和主進程寫aof文件的操作，兩者都會操作磁盤，而bgrewriteaof往往會涉及大量磁盤操作，這樣就會造成主進程在寫aof文件的時候出現阻塞的情形，現在no-appendfsync-on-rewrite參數出場了。如果該參數設置為no，是最安全的方式，不會丟失數據，但是要忍受阻塞的問題。如果設置為yes呢？這就相當于將appendfsync設置為no，這說明并沒有執行磁盤操作，只是寫入了緩沖區，因此這樣并不會造成阻塞（因為沒有競爭磁盤），但是如果這個時候redis掛掉，就會丟失數據。丟失多少數據呢？在Linux的操作系統的默認設置下，最多會丟失30s的數據。 ### 3.4 持久化對性能的影響 > * 它的運行過程主要涉及CPU、內存、硬盤三部分 的消耗。 * CPU * 子進程在把內存數據向硬盤持久化時，屬于CPU的密集操作，對于單核CPU利用率會達到90%左右。會和父進程產生單核資源競爭。 所以不要把redis和其他CPU密集型服務放在一起，CPU競爭太激烈。 * info Persistence 查看持久化信息，是否發生阻塞redis，AOF如果持久化距離上次持久化超過2秒，主線程將阻塞，直到同步操作完成。如果AOF發生延遲，可能是磁盤壓力較大，使用iotop定位消耗IO資源的進程。 * * * * * ### 4.Linux系統對Redis服務的影響 * overcommit： Linux對大部分內存的請求都回復yes，以便能夠運行更多的程序，但是申請內存后并不會馬上使用內存，這種技術叫做overcommit。overcommit_memory對應有三個值，分別是0,1，2 0：Linux內核會檢查內存是否足夠，內存足夠的話內存申請就會通過，否則失敗并把錯誤返回給應用程序。 1：允許超量使用內存，知道用完為止。、 2：內核不會過量使用內存，系統整個內存地址空間不會超過swap+50%RAM。 * swap 交換分區 Linux在內存不足時會使用磁盤充當內存使用，解決一定內存緊缺的問題。 * * * * * ### 5.Pipeline * redis客戶端執行一條命令經過以下四個過程 1)發送命令 2）命令排隊 3）命令執行 4）返回結果 其中1）+4）稱為RoundTripTime（RTT，往返時間）。 * Redis提供了批量操作命令（例如mget、mset等），有效地節約RTT。但大部分命令是不支持批量操作的，例如要執行hgetall命令，并沒有相關的批處理命令 * Pipeline（流水線）機制能改善上面這類問題，它能將一組Redis命令進行組裝，通過一次RTT傳輸給Redis，再將這組Redis命令的執行結果按順序返回給客戶端------Java支持Pipeline * redis批命令與Pipeline對比 1）原生批量命令是原子的，Pipeline是非原子的。 2）原生批量命令是一個命令對應多個key，Pipeline支持多個命令。·原生批量命令是Redis服務端支持實現的，而Pipeline需要服務端和客戶端的共同實現。 * * * * * ### 6. 客戶端管理 #### 6.1 client list、info clients > * client list 會列出與redis服務端連接所有客戶端連接信息。  > * clientlist中的age和idle分別代表當前客戶端已經連接的時間和最近一次的空閑時間 > 1. id： 客戶端連接唯一標識，ID隨著redis客戶端的連接而自增長。redis重啟后重置為0 > 2. addr： 客戶端連接的IP和端口號 > 3. fd： socket的文件描述符，與lsof命令結果中的fd是同一個，如果fd=-1代表當前客戶端不是外部客戶端，而是Redis內部的偽裝客戶端。 > 4. qbuf、qbuf-free ：輸入緩沖區 redis為每個客戶端發來的命令分配輸入緩沖區，臨時保存命令。redis會從輸入緩沖區中拉去命令然后執行。qbuf、qbuf-free代表輸入緩沖區大小，輸入緩沖區剩余 > * 輸入緩沖區的大小會根據實際情況動態的分配，不能配置，但是大小不會超過1G，`否則這個客戶端將會被關閉。` > 5. cmd 客戶端執行的命令 * info clients：查看redis集群連接狀態  可以查看連接的總數，阻塞的連接總數，最大輸入緩沖區的連接。 client_ longest_ output_ list: 最大的客戶端連接的輸出緩沖區對象個數 * * * * * #### 6.2 輸入緩沖區的問題 1. 一旦某個客戶端的輸入緩沖區超過1G，這個客戶將會被關閉。 2. 輸入緩沖區不受maxmemory控制，假設一個Redis實例設置了maxmemory為4G，已經存了2G數據，但是如果此時輸入緩沖區使用了3G，已經超過maxmemory限制，可能會產生數據丟失、鍵值淘汰、OOM等情況。 * 輸入緩沖區過大的原因 1. redis的處理速度跟不上輸入緩沖區的輸入命令速度。 2. 輸入緩沖區中包含大量的bigkey 3. redis發生了阻塞，短時間內不能處理緩沖區的命令，導致了堆積。 * * * * * #### 6.3 解決輸入緩沖區的辦法 1. 定期執行client list，收集輸入緩沖區記錄，分析出有問題的客戶端連接。 2. 通過 info clients 找到最大的輸入緩沖區，client_biggest_input_buf,可以設置超過10m就報警。  #### 6.4 輸出緩沖區 * 為客戶端的命令執行結提供緩沖，和輸入緩沖區對應。 與輸入緩沖區不同的是，輸出緩沖區的容量可以通過參數client-output-buffer-limit來進行設置，并且輸出緩沖區做得更加細致，按照客戶端的不同分為三種：普通客戶端、發布訂閱客戶端、slave客戶端。 > * 配置規則 ~~~ client- output- buffer- limit < class> < hard limit> < soft limit> < soft seconds> ~~~ `config set client-output-buffer-limit normal 20mb 10mb 120` > 表示超過10mb，并且連接了120秒，立即連接，如果超過20mb，也立即關閉。把普通客戶端輸入緩沖區控制起來，防止錯誤發生。 <class>：客戶端類型，分為三種。 a）normal：普通客戶端； b）slave：slave客戶端，用于復制； c）pubsub：發布訂閱客戶端。 <hardlimit>：如果客戶端使用的輸出緩沖區大于<hardlimit>，客戶端會被立即關閉。 <softlimit>和<softseconds>：如果客戶端使用的輸出緩沖區超過了<softlimit>并且持續了<softlimit>秒，客戶端會被立即關閉 clientlist中的obl代表固定緩沖區的長度，oll代表動態緩沖區列表的長度，omem代表使用的字節數。例如下面代表當前客戶端的固定緩沖區的長度為0，動態緩沖區有4869個對象，兩個部分共使用了133081288字節=126M * 輸出緩沖區可能造成內存的抖動。  #### 6.5 動態設置最大連接數 ~~~ config set maxclients 500 # 動態設置同一時間最大連接數。 config get maxclients # 查詢最大連接數 ~~~ #### 6.6 客戶端超時時間 * 執行 `client list`  age：表示客戶端已經連接時間 idle：最近一次空閑時間 * 如果發現jedis的idle時間過長，肯定有問題，沒有關閉連接。可以設置timeout超時時間，超時就斷開連接。redis默認配置idle超時時間為0； * 如果設置了超時時間，注意對jedis pool 客戶端的影響。  ### 7.主從復制 1. 主從架構中，數據由主節點流向從節點（單向） 2. 主節點和從節點的數據復制的偏移量正常應該一致（info replication） 3. 主從關系首次建立后，主從連接正常，主會把全部數據發送給從節點，此時特別消耗性能。  問題： > 當主從節點網絡中斷后，從節點再次連上主節點時會發送psync{offset}{runId}命令請求部分復制，如果請求的偏移量不在主節點的積壓緩沖區內，則無法提供給從節點數據，因此部分復制會退化為全量復制。全量復制導致性能下降 #### 7.1 repl-disable-tcp-nodelay：默認關閉  * 當關閉時，主節點產生的命令會及時發送給從節點，增加了網絡消耗 * 當開啟時，主節點會合并較小的TCP數據包從而節省帶寬。默認發送時間間隔取決于Linux的內核，一般默認為40毫秒. #### 7.2 復制積壓區 * 這個緩沖區可用于，主從復制數據丟失恢復  > 復制積壓緩沖區是保存在主節點上的一個固定長度的隊列，默認大小為1MB，當主節點有連接的從節點（slave）時被創建，這時主節點（master）響應寫命令時，不但會把命令發送給從節點，還會寫入復制積壓緩沖區， ~~~ role:master connected_slaves:1 slave0:ip=192.168.56.130,port=6379,state=online,offset=381567,lag=0 # slave復制偏移量，正常與master相等 master_repl_offset:381567 # master自身復偏移量 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:2 repl_backlog_histlen:381566 # redis所有數據偏移量，參考master和slave復制偏移量，查看問題 ~~~  #### 7.3 復制注意問題 1. 在首次建立主從復制關系后，主節點會執行bgsave命令，產生dump.rdb文件保存到本地，然后給 從節點發送rdb文件，之后異步的發送修改命令給從節點達到數據同步。 所有即使在沒有開啟RBD的情況下，也會產生rdb文件。 * 主節點沒有沒開啟自動save  * 開啟了AOF  * 主節點的data目錄，下多了dump文件  * * * * * * 主從數據同步超時 > * 針對數據量較大的節點，建議調大repl-timeout參數防止出現全量同步數據超時。例如對于千兆網卡的機器，網卡帶寬理論峰值大約每秒傳輸100MB，在不考慮其他進程消耗帶寬的情況下，6GB的RDB文件至少需要60秒傳輸時間，默認配置下，極易出現主從數據同步超時。 * 復制客戶端緩沖區 > * 對于從節點開始接收RDB快照到接收完成期間，主節點仍然響應讀寫命令，因此主節點會把這期間寫命令數據保存在復制客戶端緩沖區內，當從節點加載完RDB文件后，主節點再把緩沖區內的數據發送給從節點，保證主從之間數據一致性。如果主節點創建和傳輸RDB的時間過長，對于高流量寫入場景非常容易造成主節點復制客戶端緩沖區溢出。默認配置為client-output-buffer-limitslave256MB64MB60，如果60秒內緩沖區消耗持續大于64MB或者直接超過256MB 時， 主節點將直接閉復制客戶端連接， 造成全量同步失敗。對應日志如下： #### 7.4 引起全量復制的原因 1. 剛建立主從關系，第一次復制。這是無法避免的，所以注意建立主從關系的時機。 2. 節點運行ID不匹配。如果主節點重啟后，runID發生改變，從節點記錄的是以前的主節點ID，認為是新主，所以引發全量復制。建議開啟哨兵服務。 3. 復制積壓緩沖區不足：當主從復制中斷后，再次復制，如果請求的偏移量不在復制積壓緩沖區中，引起全量復制。在高并發的場景下，增加緩沖區大小，默認是1M。 ### 8.bigkeys * 能在從節點做，盡量在從節點做。 ~~~ # -h 127.0.0.1 -p 6379 redis-cli --bigkeys ~~~  * * * * * ### 9. 慢查詢 ~~~ # 設置慢查詢時間，單位微妙 config set slowlog-log-slower-than 200 # 超過200微妙為慢查詢 config set slowlog-max-len 1000 # 設置保存慢查詢記錄條數 slowlog get 4 # 查詢四條慢查詢 slowlog len # 顯示有多少條慢查詢 slowlog reset # 清空慢查詢 ~~~  > * 每條慢查詢四個屬性 > * * * * * > 1. 慢查詢表示id > 2. 查詢發生時間撮 > 3. 查詢消耗時間 > 4. 查詢命令、參數 * 圖中顯示，系統保存128條慢查詢記錄  * * * * * ### 10. 實時監控命令 * 實時監控redis數據庫庫信息，數據庫鍵信息，占用內存，連接信息。。。 `redis-cli --stat`  * * * * * ### 11. 誤操作恢復 * 如果持久化是AOF的，并且在誤操作后沒有發生過重寫，則修改屌誤操作記錄，然后使用 redis- check- aof 檢查AOF格式是否正確，修復。然后重啟redis `sudo redis-check-aof --fix appendonly.aof` * * * * * ### 12. 命令 #### 1.redis-cli ~~~ redis-cli 【option】【command】 ~~~ * option > 1. -r：（repeat），代表將命令重復執行 > redis-cli -r 3 ping  > 2. -i : (interval),代表每隔幾秒執行一次命令，必須和-r 一起使用 ~~~ tuna@docker02:/etc/init.d$ redis-cli -r 3 -i 2 ping PONG PONG PONG ~~~ > 3. -x，讀取標準輸入 ~~~ tuna@docker01:~$ echo 'hello' | redis-cli -x set x OK ~~~ > 4. -c：連接redis集群時使用 > 5. -a：加入redis密碼 > 6. `--slave`：把客戶端模擬成所連接redis節點的從節點，獲得數據庫更新信息。  > 7. `--latency`：測試客戶端到redis服務器的網絡延遲。 > 8. `--state`：實時查看redis信息，包括客戶端連接數量，redis占用內存。。。  > 9.` --raw`：返回格式化后的結果，`--no-raw`：返回原始格式  ~~~ redis-cli shutdown # 關閉redis，自動持久化，shutdown 后可加nosave|save顯示指定是否持久化 ~~~ #### 2. redis-benchmark > 測試redis并發量 > * -c：模擬出的客戶端數量（默認50） > * -n：模擬出客戶端請求總數量（默認100000） > * ` --csv`按照格式導出，便于后續處理，如導入到Excel > * -t：指定測試的命令，如測試set、get等操作性能 ~~~ redis-benchmark redis-benchmark -c 100 -n 10000 # 顯示的指出測試數量 ~~~ > `redis-benchmark `  如圖，完成10萬次操作用了4.94秒，由于用的是虛擬機，慢很多 * 指定測試操作命令，并格式化