縮減鍵值物件
命令處理
記憶體淘汰策略
如何選擇淘汰策略
內容**為六星教育，這裡僅作為學習筆記
目前大部分公司都會將 web 伺服器、資料庫伺服器等部署在 linux 作業系統上，redis優化也需要考慮作業系統，所以接下來介紹 linux 作業系統如何優化redis。
檢查資料持久化策略
資料落磁碟盡可能減少效能損壞，以空間換時間。設定如下命令：
監控客戶端的連線
因為redis是單執行緒模型(只能使用單核)，來處理所有客戶端的請求， 但由於客戶端連線數的增長，處理請求的執行緒資源開始降低分配給單個客戶端連線的處理時間
限制客戶端連線數 。在redis-cli工具中輸入info clients可以檢視到當前例項的所有客戶端連線資訊
maxclients屬性上修改客戶端連線的最大數，可以通過在redis-cli工具上輸入 config set maxclients 去設定最大連線數。根據連線數負載的情況
降低redis記憶體使用最直接的方式就是縮減鍵（key）和值（value）的長度。
壓縮方法
解壓方法
壓縮時間
壓縮效果
bzcompress()
bzdecompress()
耗時多壓縮效果好
gzcompress()
gzuncompress()
耗時少壓縮效果差
redis基於c/s架構模式，基於redis操作命令是解決響應延遲問題最關鍵的部分，因為redis是個單執行緒模型，客戶端過來的命令是按照順序執行的。比較常見的延遲是頻寬，通過千兆網絡卡的延遲大約有200μs。倘若明顯看到命令的響應時間變慢，延遲高於200μs，那可能是redis命令佇列裡等待處理的命令數量比較多
要分析解決這個效能問題，需要跟蹤命令處理數的數量和延遲時間。
比如可以寫個指令碼，定期記錄total_commands_processed的值。當客戶端明顯發現響應時間過慢時，可以通過記錄的total_commands_processed歷史資料值來判斷命理處理總數是上公升趨勢還是下降趨勢，以便排查問題
在info資訊裡的 total_commands_processed欄位顯示了redis服務處理命令的總數
info stats
# stats
total_connections_received:843391006
total_commands_processed:3946780282
instantaneous_ops_per_sec:1447
total_net_input_bytes:5060670300797
total_net_output_bytes:13788457111609
instantaneous_input_kbps:1399.63
instantaneous_output_kbps:2863.71
rejected_connections:0
sync_full:2
sync_partial_ok:1
sync_partial_err:0
expired_keys:231497375
evicted_keys:0
keyspace_hits:613100363
keyspace_misses:252710911
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:60179
使用多引數命令：若是客戶端在很短的時間內傳送大量的命令過來，會發現響應時間明顯變慢，這由於後面命令一直在等待佇列中前面大量命令執行完畢。有個方法可以改善延遲問題，就是通過單命令多引數的形式取代多命令單引數的形式。
舉例來說 迴圈使用lset命令去新增1000個元素到list結構中，是效能比較差的一種方式，更好的做法是在客戶端建立乙個1000元素的列表，用單個命令lpush或rpush，通過多引數構造形式一次性把1000個元素傳送的redis服務上。下面是redis的一些操作命令，有單個引數命令和支援多個引數的命令，通過這些命令可儘量減少使用多命令的次數。
管道命令：另乙個減少多命令的方法是使用管道(pipeline)，把幾個命令合併一起執行，從而減少因網路開銷引起的延遲問題。因為10個命令單獨傳送到服務端會引起10次網路延遲開銷，使用管道會一次性把執行結果返回，僅需要一次網路延遲開銷。redis本身支援管道命令，大多數客戶端也支援，倘若當前例項延遲很明顯，那麼使用管道去降低延遲是非常有效的
redis 記憶體資料集大小上公升到一定大小的時候，就會進行資料淘汰策略。如果不淘汰經常不用的快取資料，那麼正常的資料將不會儲存到快取當中。
我們通過配置redis.conf中的maxmemory這個值來開啟記憶體淘汰功能。
根據應用場景，選擇淘汰策略
首先，客戶端發起了需要申請更多記憶體的命令（如set）。此外，redis支援動態改配置，無需重啟。然後，redis檢查記憶體使用情況，如果已使用的記憶體大於maxmemory則開始根據使用者配置的不同淘汰策略來淘汰記憶體（key），從而換取一定的記憶體。
最後，如果上面都沒問題，則這個命令執行成功。
設定最大記憶體
config set maxmemory 100000
設定淘汰策略
config set maxmemory-policy noeviction
volatile-lru
從已設定過期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰。
allkeys-lru
從資料集（server.db[i].dict）中挑選最近最少使用的資料淘汰
volatile-lfu
從設定了過期時間的資料集（server.db[i].expires）中選擇某段時間之內使用頻次最小的鍵值對清除掉
allkeys-lfu
從所有的資料集（server.db[i].dict）中選擇某段時間之內使用頻次最少的鍵值對清除
volatile-ttl
從已設定過期時間的資料集（server.db[i].expires）中挑選將要過期的資料淘汰
volatile-random
從已設定過期時間的資料集（server.db[i].expires）中任意選擇資料淘汰
allkeys-random
從資料集（server.db[i].dict）中任意選擇資料淘汰
no-enviction
當記憶體達到限制的時候，不淘汰任何資料，不可寫入任何資料集，所有引起申請記憶體的命令會報錯。
演算法文章:
下面看看幾種策略的適用場景
allkeys-lru：如果我們的應用對快取的訪問符合冪律分布，也就是存在相對熱點資料，或者我們不太清楚我們應用的快取訪問分布狀況，我們可以選擇allkeys-lru策略。
allkeys-random：如果我們的應用對於快取key的訪問概率相等，則可以使用這個策略。
volatile-ttl：這種策略使得我們可以向redis提示哪些key更適合被eviction。
另外，volatile-lru策略和volatile-random策略適合我們將乙個redis例項既應用於快取和又應用於持久化儲存的時候，然而我們也可以通過使用兩個redis例項來達到相同的效果，值得一提的是將key設定過期時間實際上會消耗更多的記憶體，因此我們建議使用allkeys-lru策略從而更有效率的使用記憶體
Redi學筆記 Redis簡介
易擴充套件 nosql資料庫種類繁多，但是乙個共同的特點都是去掉關聯式資料庫的關係型特性。資料之間無關係，這樣就非常容易擴充套件。也無形之間，在架構的層面上帶來了可擴充套件的能力。高效能 nosql資料庫都具有非常高的讀寫效能，尤其在大資料量下，同樣表現優秀。這得益於它的無關係性，資料庫的結構簡單。...
redis學習筆記（5）
2.1 節點取餘 客戶端分片 雜湊 取餘 節點伸縮 資料節點關係變化，導致資料遷移 遷移數量和新增的節點數量有關 建議翻倍擴容 2.2 一致性雜湊 客戶端分片 雜湊 順時針 優化取餘 節點伸縮 只影響臨近節點，但是還是有資料遷移 翻倍伸縮 保證最小遷移資料和負載均衡 2.3 虛擬槽分割槽 預設虛擬槽...
redis學習筆記之hash
hash 適合儲存乙個物件，相較於將每個字段儲存為string 將乙個物件儲存為乙個hash將占用更少的記憶體 1.hset user001 name zhangsan 設定乙個user001 的hash name 為 zhangsan 2.hget user001 name 獲取 user001 ...