redis (remote dictionary server)
<meta charset="utf-8">http://download.redis.io/releases/
文檔
expire k1 10 設置過期時間
ttl 查詢過期時間
時間到期后 刪除 keys * 就沒有當前k1了
String 常用命令
set / get / del / append / strlen
incr / decr / incrby / decrby / 一定要是數(shù)據(jù)才能加減
getrange / setrange
setex(set with expire)鍵過期秒數(shù) / setnx (set if not exist)
mset / mget / msetnx
getset
列表常用命令
lpush / rpush / lrange
lpop / rpop
lindex，按照索引下標獲得元素（從上到下）
llen
lrem key 刪N個value
ltrim key 開始index 結束index，截取制定范圍的值后再賦給key
rpoplpush 源列表 目的列表
lset key index value 設置指定下標的value
linsert key before / after key 值2
列表 是一個字符串鏈表， left 和 right都可以插入添加；
如果鍵不存在，創(chuàng)建新的鏈表
如果鍵已存在，新增內容
如果值全部移除，對應的鍵也消失了
鏈表的操作無論是頭和尾效率都很高，但假如是對中間的元素進行操作，效率就很慘淡了
list
set
hash 就是一個鍵值對，可以存儲對象
zset
redis配置
daemonize:yes:redis采用的是單進程多線程的模式。當redis.conf中選項daemonize設置成yes時，代表開啟守護進程模式。在該模式下，redis會在后臺運行，并將進程pid號寫入至redis.conf選項pidfile設置的文件中，此時redis將一直運行，除非手動kill該進程。
daemonize:no: 當daemonize選項設置成no時，當前界面將進入redis的命令行界面，exit強制退出或者關閉連接工具(putty,xshell等)都會導致redis進程退出。
1.redis 默認支持同時10000個客戶端連接 Maxclients
2.redis value 最大 512M Maxmemory
3.Redis內存不足的緩存淘汰策略（maxmemeory-policy）
- noeviction：當內存使用超過配置的時候會返回錯誤，不會驅逐任何鍵
- allkeys-lru：加入鍵的時候，如果過限，首先通過LRU算法驅逐最久沒有使用的鍵
- volatile-lru：加入鍵的時候如果過限，首先從設置了過期時間的鍵集合中驅逐最久沒有使用的鍵
- allkeys-random：加入鍵的時候如果過限，從所有key隨機刪除
- volatile-random：加入鍵的時候如果過限，從過期鍵的集合中隨機驅逐
- volatile-ttl：從配置了過期時間的鍵中驅逐馬上就要過期的鍵
- volatile-lfu：從所有配置了過期時間的鍵中驅逐使用頻率最少的鍵
- allkeys-lfu：從所有鍵中驅逐使用頻率最少的鍵
redis默認測試，永不過期
4.maxmemeory-samples: 設置樣本的數(shù)量，默認5個
redis持久化(重要)
介紹：
1.rdb redis database 指定的時間間隔內，將內存中的快照數(shù)據(jù)Snapshot寫入磁盤
2.aof append only file
RDB 詳解
rdb 出廠默認策略
1分鐘內改了1萬次
或5分鐘內改了10次
或15分鐘內改了1次
save " 代表禁用 RDB策略
在命令中使用save，立馬備份當前操作的數(shù)據(jù)
save命令，馬上就持久化，可以針對很重要的數(shù)據(jù)，set之后 立馬執(zhí)行save命令；
如果不執(zhí)行save，默認使用.conf里面的備份策略
bgsave也可以里面?zhèn)浞莓斍安僮?，與save的區(qū)別是 bgsave是異步的，不會發(fā)生阻塞；save命令會發(fā)生阻塞
save和flushall都會立即將命令同步到rdb文件中
RDB配置
1、stop-writes-on-bgsave-error 當發(fā)生持久化錯誤的時候，redis是否停止接收數(shù)據(jù)。默認 yes
2、rdbcompression 快照文件是否用 LZF算法壓縮，但會消耗CPU。 默認yes
配置異常 用 redis_check_dump 修復
AOF詳解
配置文件：
appendonly true打開。默認no，關閉。
appendfilename aof文件名
appendfsync: allways 同步持久化，每次變化都會記錄到磁盤，性能差，數(shù)據(jù)完整性好
everysec 出廠默認設置，異步操作。每秒記錄一次，發(fā)生宕機，丟失1s數(shù)據(jù)
no 不同步
配置異常 用 redis_check_aof 修復 用法 ： redis-check-aof --fix AOF文件
AOF rewrite
aof文件是追加的形式，所會越來越大。
rewrite aof 文件壓縮精簡機制
什么時候觸發(fā)rewrite：默認 是記錄上次rewrite之后文件大小的一倍 并且文件大小大于64M后 fork新的線程 觸發(fā)
No-appendfsync-on-rewrite 重寫時是否可以運用Appendfsync,默認 no，保證數(shù)據(jù)安全性
Auto-aof-rewirte-min-size 設置重寫的基準值 默認 64M
Auto-aof-rewrite-percentage 設置重寫的基準值（上次重寫后大小的百分比）
AOF 關鍵點：同步策略，文件修復，rewrite
劣勢：
1、數(shù)據(jù)會越來越大，不如rdb
2、恢復的速度也慢
redis事務
MULTI 開始事務
EXEC 提交事務
DISCARD 放棄事務
事務中有一條語句錯誤，所有的語句都會執(zhí)行失敗(編譯時異常)；
如果其中的語句是 incr這樣的語句，錯誤了不會提醒，exec后單這條語句不會成功。所以redis對事務的支持并非是絕對的。
WATCH 監(jiān)控：
悲觀鎖：對事情的發(fā)展很悲觀，為了不出事，自動加鎖
樂觀鎖：在每條記錄后面加上version
redis發(fā)布與訂閱
消息中間件
進程間的通信模式 pub發(fā)送者發(fā)送消息，sub 訂閱者接收
訂閱 subscribe c1 c2 c3 同時訂閱 c1 c2 c3 三個頻道的發(fā)布
publish c1 hello-redis -- 向c1頻道發(fā)送消息 hello-redis
psubscribe news* 訂閱 帶有通配符的 頻道
redis主從復制
1、配從不配主
2、從庫配置 slaveof 主庫IP 主庫端口
1、命令 info replication 查看主從復制狀態(tài)
2、成為從機那一刻，將會復制主機所有的數(shù)據(jù)
3、從庫不能set值，只能get值 只讀模式
4、主機掛了，重啟之后，從機自動連接主機
5、從機掛了，重啟之后 變成 master，不會從主機獲取數(shù)據(jù)；如果需要連接主機，可以在配置文件中配置主機地址IP端口
6、主從復制原理：首次成為slave，全量同步；后面進行增量同步
7、主機down了之后，從機6380可以執(zhí)行 slaveof no one，不再跟從任何主機。另外一臺從機 slave of ip 6380 重新確認主機 --- 反客為主
主從三種方式：
一主多從 6379 ---》 6380、6381
薪火相傳 6379 ---》 6380 ---》6381
反客為主 主機掛掉之后，其中一臺從機 slaveof no one,其他從機 slaveof 新的slaveof no one的機器
如果主機掛了，不可能手動指定新的master；要使用哨兵模式
在redis 目錄下 配置sentinel.conf,內容為：
sentinel monitor host6379 127.0.0.1 6379 1 代表 其他從機投票數(shù)多，就被選為主機
79掛掉之后，重新回來 會變成從機
redis主從復制原理：
從數(shù)據(jù)庫連接主數(shù)據(jù)庫，發(fā)送SYNC命令;
主數(shù)據(jù)庫接收到SYNC命令后，可以執(zhí)行BGSAVE命令生成RDB文件并使用緩沖區(qū)記錄此后執(zhí)行的所有寫命令;
主數(shù)據(jù)庫BGSAVE執(zhí)行完后，向所有從數(shù)據(jù)庫發(fā)送快照文件，并在發(fā)送期間繼續(xù)記錄被執(zhí)行的寫命令;
從數(shù)據(jù)庫收到快照文件后丟棄所有舊數(shù)據(jù)，載入收到的快照;
主數(shù)據(jù)庫快照發(fā)送完畢后開始向從數(shù)據(jù)庫發(fā)送緩沖區(qū)中的寫命令;
從數(shù)據(jù)庫完成對快照的載入，開始接受命令請求，并執(zhí)行來自主數(shù)據(jù)庫緩沖區(qū)的寫命令;(從數(shù)據(jù)庫初始化完成)
主數(shù)據(jù)庫每執(zhí)行一個寫命令就會向從數(shù)據(jù)庫發(fā)送相同的寫命令，從數(shù)據(jù)庫接收并執(zhí)行收到的寫命令(從數(shù)據(jù)庫初始化完成后的操作)
出現(xiàn)斷開重連后，2.8之后的版本會將斷線期間的命令傳給從數(shù)據(jù)庫，增量復制。
主從剛剛連接的時候，進行全量同步;全同步結束后，進行增量同步。當然，如果有需要，slave在任何時候都可以發(fā)起全量同步。Redis的策略是，無論如何，首先會嘗試進行增量同步，如不成功，要求從機進行全量同步
redis哨兵模式工作模式：
http://www.itdecent.cn/p/06ab9daf921d
問題：
數(shù)據(jù)穿透？
實現(xiàn)隊列？
