鍍金池/ 教程/ 大數(shù)據(jù)/ 5.1 內(nèi)存、CPU規(guī)劃
6.2 并發(fā)延遲檢查
2.2.2 獲取key對(duì)應(yīng)的string值
11.1.5 其他問題
4.7 客戶端推薦
3.3 查看和修改配置
2.3.7 設(shè)置list中指定下標(biāo)的元素值
9.1 Shell提權(quán)問題
2.3.6 刪除元素
8.3.1 系統(tǒng)內(nèi)存查看
11.1.2 環(huán)境搭建
2.6.3 遞增某一個(gè)域的值
2.7.2 返回給定 HyperLogLog 的基數(shù)估算值
2.3.8 阻塞隊(duì)列
2.5.2 刪除元素
2.4.6 查看集合大小
8.3.4 dump.rdb文件成生內(nèi)存報(bào)告(rdb-tool)
8.3 內(nèi)存檢查
2.1.7 Key的超時(shí)設(shè)置處理
2.5.8 返回集合中元素個(gè)數(shù)
2.7.1 將元素添加至 HyperLogLog
2.5.4 獲取排名
6.1.2 探測(cè)服務(wù)延遲
10.1 概念
7.3 模擬hang
2.6.6 獲取域的數(shù)量
11.1.1 高可用原理
3.5 選擇數(shù)據(jù)庫(kù)
4.3 數(shù)據(jù)異常處理
2.4.10 集合差集
2.2.6 改寫字符串
11.1.3 維護(hù)操作
3.13.3 備份
2.2.5 截取字符串
4.6 典型使用場(chǎng)景參考
2.4.4 隨機(jī)返回一個(gè)元素
2.4.11 獲取所有元素
2.4.3 刪除并返回元素
2.4.2 移除元素
8.3.9 Rss增加,內(nèi)存碎片增加
2.4.8 集合交集
2.1.3 刪除給定key
2.5.3 增加score
11.1.4 高可用和異常測(cè)試
底層實(shí)現(xiàn)是hash table,一般操作復(fù)雜度是O(1),要同時(shí)操作多個(gè)field時(shí)就是O(N),N是field的數(shù)量。應(yīng)用場(chǎng)景
5.2 網(wǎng)卡RPS設(shè)置
2.6.7 獲取所有的域名
5.6 具體設(shè)置參數(shù)
生產(chǎn)環(huán)境慎用。
6. 常見運(yùn)維操作
8.3.8 查看key內(nèi)部結(jié)構(gòu)和編碼等信息
4.4 內(nèi)存考慮
4.1 Key設(shè)計(jì)
2.5.5 獲取排行榜
7.1 模擬oom
2.1.2 測(cè)試指定key是否存在
10.3 分片主要場(chǎng)景和對(duì)應(yīng)思路
6.1.1 探測(cè)服務(wù)是否可用
3.13.1 RDB相關(guān)操作
2.3.5 截取list
3.13.4 恢復(fù)
3.10 驗(yàn)證密碼
2.2.4 追加字符串
8.3.6 內(nèi)存抽樣分析
5. 上線部署規(guī)劃
Sorted Set的實(shí)現(xiàn)是hash table(element->score, 用于實(shí)現(xiàn)ZScore及判斷element
4.5 延遲考慮
2.6.1 設(shè)置hash值
8.3.5 query在線分析
6.2.4 檢查連接數(shù)
2.4.9 集合并集
7. 數(shù)據(jù)遷移
4. 開發(fā)設(shè)計(jì)規(guī)范
2.5.9 返回給定元素對(duì)應(yīng)的score
9. Redis安全問題
2.2.7 返回子字符串
3.4 批量執(zhí)行操作
Server
3.1 排序
8.3.2 系統(tǒng)swap內(nèi)存查看
2.6.4 判斷某一個(gè)域是否存在
3.6 清空數(shù)據(jù)庫(kù)
2.6.8 獲取所有域的值
3.11 性能測(cè)試命令
  • 1.
6.2.1 檢查CPU情況
7.5 模擬RDB load情形
7.4 快速產(chǎn)生測(cè)試數(shù)據(jù)
7.2 模擬宕機(jī)
2.7.3 合并多個(gè) HyperLogLog
  • 1.
9. 測(cè)試方法
2.7 HyperLogLog操作
3.7 重命名命令
6.1.7 查看日志
6.2.5 檢查持久化
4.2 超時(shí)設(shè)置
8.1 一般處理流程
2.1.4 返回給定key的value類型
5.3 服務(wù)器部署位置
2.5.6 返回給定分?jǐn)?shù)區(qū)間的元素
6.2.6 檢查命令執(zhí)行情況
7.6 模擬AOF加載情形
6.13 持久化與備份恢復(fù)
5.1 內(nèi)存、CPU規(guī)劃
5.5 多實(shí)例配置
2.2.1 設(shè)置key對(duì)應(yīng)的值為string類型的value
6.1.5 獲取慢查詢
incr key
3.4 發(fā)布訂閱
6.2.2 檢查網(wǎng)絡(luò)情況
2.6.5 刪除域
6.2.3 檢查系統(tǒng)情況
8. 數(shù)據(jù)遷移
2.5.7 返回集合中score在給定區(qū)間的數(shù)量
2.1. key操作
3.8 執(zhí)行l(wèi)ua腳本
1. 簡(jiǎn)述
11.1 主從復(fù)制-sentinel架構(gòu)
2.3.2 查看列表長(zhǎng)度
8.3.3 info查看內(nèi)存
2.6.2 獲取hash值
11. 高可用和集群架構(gòu)與實(shí)踐
3.13.2 AOF相關(guān)操作
2. 數(shù)據(jù)操作
3.3 流水線
3.1 啟動(dòng)
2.3.3 查看元素
2.4.5 集合間移動(dòng)元素
8.3.7 統(tǒng)計(jì)生產(chǎn)上比較大的key
10.4 適用場(chǎng)景對(duì)比列表
3.9 設(shè)置密碼
3.2 事務(wù)
2.1.5 返回從當(dāng)前數(shù)據(jù)庫(kù)中隨機(jī)選擇的一個(gè)key
5.7 其他好用的配置技巧
3. 專題功能
2.3.4 查看一段列表
2.4.7 判斷member是否在set中
2.4.1 添加元素
2.1.6 原子的重命名一個(gè)key
2.1.1 列出key
2.6.9 獲取所有域名和值
2.5.10 評(píng)分的聚合
3.12 Redis-cli命令行其他操作
最大字符串為512M,但是大字符串非常不建議。
4.1 將key從當(dāng)前數(shù)據(jù)庫(kù)移動(dòng)到指定數(shù)據(jù)庫(kù)
6.1.6 查看客戶端
10. 簡(jiǎn)述
2.2.10 位操作
2.2.9 取指定key的value值的長(zhǎng)度
  • 1.
3.2 停止
5.4 持久化設(shè)置
10.2 高可用主要場(chǎng)景和對(duì)應(yīng)思路
2.5.1 添加元素
2.3.1 添加元素

5.1 內(nèi)存、CPU規(guī)劃

一定要設(shè)置最大內(nèi)存maxmemory參數(shù),否則物理內(nèi)存用爆了就會(huì)大量使用Swap,寫RDB文件時(shí)的速度很慢。注意這個(gè)參數(shù)指的是info中的used_memory,在一些不利于jmalloc的時(shí)候,內(nèi)存碎片會(huì)很大。

多留55%內(nèi)存是最安全的。重寫AOF文件和RDB文件的進(jìn)程(即使不做持久化,復(fù)制到Slave的時(shí)候也要寫RDB)會(huì)fork出一條新進(jìn)程來(lái),采用了操作系統(tǒng)的Copy-On-Write策略(子進(jìn)程與父進(jìn)程共享Page。如果父進(jìn)程的Page-每頁(yè)4K有修改,父進(jìn)程自己創(chuàng)建那個(gè)Page的副本,不會(huì)影響到子進(jìn)程)。

另外,需要考慮內(nèi)存碎片,假設(shè)碎片為1.2,則如果機(jī)器為64G,那么64*45%/1.2 = 24G作為maxmemory是比較安全的規(guī)劃。

留意Console打出來(lái)的報(bào)告,如"RDB: 1215 MB of memory used by copy-on-write"。在系統(tǒng)極度繁忙時(shí),如果父進(jìn)程的所有Page在子進(jìn)程寫RDB過程中都被修改過了,就需要兩倍內(nèi)存。

按照Redis啟動(dòng)時(shí)的提醒,設(shè)置

echo "vm.overcommit_memory = 1" >>  /etc/sysctl.conf

使得fork()一條10G的進(jìn)程時(shí),因?yàn)镃OW策略而不一定需要有10G的free memory。

另外,記得關(guān)閉THP,這個(gè)默認(rèn)的Linux內(nèi)存頁(yè)面大小分配策略會(huì)導(dǎo)致RDB時(shí)出現(xiàn)巨大的latency和巨大的內(nèi)存占用。關(guān)閉方法為:

echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

當(dāng)最大內(nèi)存到達(dá)時(shí),按照配置的Policy進(jìn)行處理, 默認(rèn)策略為volatile-lru,對(duì)設(shè)置了expire time的key進(jìn)行LRU清除(不是按實(shí)際expire time)。如果沒有數(shù)據(jù)設(shè)置了expire time或者policy為noeviction,則直接報(bào)錯(cuò),但此時(shí)系統(tǒng)仍支持get之類的讀操作。 另外還有幾種policy,比如volatile-ttl按最接近expire time的,allkeys-lru對(duì)所有key都做LRU。注意在一般的緩存系統(tǒng)中,如果沒有設(shè)置超時(shí)時(shí)間,則lru的策略需要設(shè)置為allkeys-lru,并且應(yīng)用需要做好未命中的異常處理。特殊的,當(dāng)redis當(dāng)做DB時(shí),請(qǐng)使用noneviction策略,但是需要對(duì)系統(tǒng)內(nèi)存監(jiān)控加強(qiáng)粒度。

CPU不求核數(shù)多,但求主頻高,Cache大,因?yàn)閞edis主處理模式是單進(jìn)程的。同時(shí)避免使用虛擬機(jī)。