前言

學習是一個持續的過程。像咱們一直在更新的Redis學習內容，由基礎結構，到原理應用，再到集群搭建，了解的夠充分了，咱們接著又介紹Redis拓展應用，將知識面拓寬，畢竟技術都是相通的，只有靈活運用，才能發揮出最大作用。

好了，接著今天的學習更新，拓寬Redis應用。

拓展 2：無所不知 —— Info 指令

在使用 Redis 時，時常會遇到很多問題需要診斷，在診斷之前需要了解 Redis 的運行狀 態，通過強大的 Info 指令，你可以清晰地知道 Redis 內部一系列運行參數。

Info 指令顯示的信息非常繁多，分為 9 大塊，每個塊都有非常多的參數，這 9 個塊分別是：

• ?1、Server 服務器運行的環境參數
• 2、Clients 客戶端相關信息
• 3、Memory 服務器運行內存統計數據
• 4、Persistence 持久化信息
• 5、Stats 通用統計數據
• 6、Replication 主從復制相關信息
• 7、CPU CPU 使用情況
• 8、Cluster 集群信息
• 9、KeySpace 鍵值對統計數量信息

?Info 可以一次性獲取所有的信息，也可以按塊取信息。

# 獲取所有信息> info# 獲取內存相關信息> info memory# 獲取復制相關信息> info replication

考慮到參數非常繁多，一一說明工作量巨大，下面我只挑一些關鍵性的、非常實用和最常用的參數進行詳細講解。

Redis 每秒執行多少次指令？

這個信息在 Stats 塊里，可以通過 info stats 看到。

# ops_per_sec: operations per second，也就是每秒操作數> redis-cli info stats |grep opsinstantaneous_ops_per_sec:789

以上，表示 ops 是 789，也就是所有客戶端每秒會發送 789 條指令到服務器執行。極限情況下，Redis 可以每秒執行 10w 次指令，CPU 幾乎完全榨干。如果 qps 過高，可以考慮通過 monitor 指令快速觀察一下究竟是哪些 key 訪問比較頻繁，從而在相應的業務上進行優化，以減少 IO 次數。monitor 指令會瞬間吐出來巨量的指令文本，所以一般在執行monitor 后立即 ctrl+c 中斷輸出。

> redis-cli monitor

Redis 連接了多少客戶端？

這個信息在 Clients 塊里，可以通過 info clients 看到。

> redis-cli info clients# Clientsconnected_clients:124 # 這個就是正在連接的客戶端數量client_longest_output_list:0client_biggest_input_buf:0blocked_clients:0

這個信息也是比較有用的，通過觀察這個數量可以確定是否存在意料之外的連接。如果發現這個數量不對勁，接著就可以使用 client list 指令列出所有的客戶端鏈接地址來確定源頭。

關于客戶端的數量還有個重要的參數需要觀察，那就是 rejected_connections，它表示因為超出最大連接數限制而被拒絕的客戶端連接次數，如果這個數字很大，意味著服務器的最大連接數設置的過低需要調整 maxclients 參數。

> redis-cli info stats |grep rejectrejected_connections:0

Redis 內存占用多大 ？

這個信息在 Memory 塊里，可以通過 info memory 看到。

> redis-cli info memory | grep used | grep humanused_memory_human:827.46K # 內存分配器 (jemalloc) 從操作系統分配的內存總量used_memory_rss_human:3.61M # 操作系統看到的內存占用 ,top 命令看到的內存used_memory_peak_human:829.41K # Redis 內存消耗的峰值used_memory_lua_human:37.00K # lua 腳本引擎占用的內存大小

如果單個 Redis 內存占用過大，并且在業務上沒有太多壓縮的空間的話，可以考慮集群化了。

復制積壓緩沖區多大？

這個信息在 Replication 塊里，可以通過 info replication 看到。

> redis-cli info replication |grep backlogrepl_backlog_active:0repl_backlog_size:1048576 # 這個就是積壓緩沖區大小repl_backlog_first_byte_offset:0repl_backlog_histlen:0

復制積壓緩沖區大小非常重要，它嚴重影響到主從復制的效率。當從庫因為網絡原因臨時斷開了主庫的復制，然后網絡恢復了，又重新連上的時候，這段斷開的時間內發生在 master 上的修改操作指令都會放在積壓緩沖區中，這樣從庫可以通過積壓緩沖區恢復中斷的主從同步過程。

積壓緩沖區是環形的，后來的指令會覆蓋掉前面的內容。如果從庫斷開的時間過長，或者緩沖區的大小設置的太小，都會導致從庫無法快速恢復中斷的主從同步過程，因為中間的修改指令被覆蓋掉了。這時候從庫就會進行全量同步模式，非常耗費 CPU 和網絡資源。

如果有多個從庫復制，積壓緩沖區是共享的，它不會因為從庫過多而線性增長。如果實例的修改指令請求很頻繁，那就把積壓緩沖區調大一些，幾十個 M 大小差不多了，如果很閑，那就設置為幾個 M。

> redis-cli info stats | grep syncsync_full:0sync_partial_ok:0sync_partial_err:0 # 半同步失敗次數

通過查看 sync_partial_err 變量的次數來決定是否需要擴大積壓緩沖區，它表示主從半同步復制失敗的次數。

拓展 3：拾遺漏補 —— 再談分布式鎖

?在之前，我們細致講解了分布式鎖的原理，它的使用非常簡單，一條指令就可以完成 加鎖操作。不過在集群環境下，這種方式是有缺陷的，它不是絕對安全的。

比如在 Sentinel 集群中，主節點掛掉時，從節點會取而代之，客戶端上卻并沒有明顯感 知。原先第一個客戶端在主節點中申請成功了一把鎖，但是這把鎖還沒有來得及同步到從節點，主節點突然掛掉了。然后從節點變成了主節點，這個新的節點內部沒有這個鎖，所以當另一個客戶端過來請求加鎖時，立即就批準了。這樣就會導致系統中同樣一把鎖被兩個客戶端同時持有，不安全性由此產生。

?不過這種不安全也僅僅是在主從發生 failover 的情況下才會產生，而且持續時間極短， 業務系統多數情況下可以容忍。

Redlock 算法

為了解決這個問題，Antirez 發明了 Redlock 算法，它的流程比較復雜，不過已經有了很多開源的 library 做了良好的封裝，用戶可以拿來即用，比如 redlock-py。

import redlockaddrs = [{ "host": "localhost", "port": 6379, "db": 0}, { "host": "localhost", "port": 6479, "db": 0}, { "host": "localhost", "port": 6579, "db": 0}]dlm = redlock.Redlock(addrs)success = dlm.lock("user-lck-laoqian", 5000)if success: print 'lock success' dlm.unlock('user-lck-laoqian')else: print 'lock failed'

?為了使用 Redlock，需要提供多個 Redis 實例，這些實例之前相互獨立沒有主從關系。 同很多分布式算法一樣，redlock 也使用「大多數機制」。

加鎖時，它會向過半節點發送 set(key, value, nx=True, ex=xxx) 指令，只要過半節點 set 成功，那就認為加鎖成功。釋放鎖時，需要向所有節點發送 del 指令。不過 Redlock 算法還 需要考慮出錯重試、時鐘漂移等很多細節問題，同時因為 Redlock 需要向多個節點進行讀寫，意味著相比單實例 Redis 性能會下降一些。

Redlock 使用場景

如果你很在乎高可用性，希望掛了一臺 redis 完全不受影響，那就應該考慮 redlock。不過代價也是有的，需要更多的 redis 實例，性能也下降了，代碼上還需要引入額外的library，運維上也需要特殊對待，這些都是需要考慮的成本，使用前請再三斟酌。

今天的Redis拓展應用就先到這里吧，希望朋友們都有所收獲啊~~~

喜歡請多多點贊評論分享，讓更多的人看到獲益，關注小編，后續小編會帶來更豐富的學習內容更新，希望能幫到大家更好的學習~~~

總結

以上是生活随笔為你收集整理的redis客户端连接数量_实战解析无所不知的Redis拓展应用——Info，进阶学习，无所不能...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。