Linux雲計算運維-Redis
Redis簡介
Redis是一款開源的，ANSI C語言編寫的，高級鍵值(key-value)緩存和支持永久存儲NoSQL數據庫產品。 Redis採用內存(In-Memory)數據集(DataSet) 。 支持多種數據類型。 運行於大多數POSIX系統，如Linux、*BSD、OS X等。 做者： Salvatore Sanfilippo
Redis.io 官網
Download/redis.io 下載
Redisdoc.com 文檔
redis.cn 中文網
核心特性
- 高速讀寫
- 數據類型豐富：常見5種
- 支持持久化
- 多種內存分配及回收策略
- 支持事務-弱事務
- 消息隊列、消息訂閱
- 支持高可用
- 支持分佈式分片集羣
和Memcache的區別：支持事務、數據類型豐富、支持高可用、支持分佈式分片集羣node
優勢python
優點： 透明性：分佈式系統對用戶來講是透明的，一個分佈式系統在用戶面前的表現就像一個傳統的單處理機分時系統，可以讓用戶沒必要了解內部結構就能夠使用。 擴展性：分佈式系統的最大特色就是可擴展性，他能夠根據需求的增長而擴展，能夠經過橫向擴展使集羣的總體性能獲得線性提高，也能夠經過縱向擴展單臺服務器的性能使服務器集羣的性能獲得提高。 可靠性：分佈式系統不容許單點失效的問題存在，它的基本思想是：若是一臺服務器壞了，其餘服務器接替它的工做，具備持續服務的特性 高性能：高性能是人們設計分佈式系統的一個初衷，若是創建了一個透明，靈活，可靠的分佈式系統，但他運行起來像蝸牛同樣慢，那這個系統就是失敗的。 分佈式系統的缺點： 1.在節點通訊部分的開銷比較大，線程安全也變得複雜，須要保證在完整數據的同時兼顧性能。 2.過度依賴網絡，網絡信息的丟失或飽和將會抵消分佈式的大部分優點。 3.有潛在的數據安全和網絡安全問題。
企業緩存數據庫解決方案對比
Memcached:
優勢：高性能讀寫、單一數據類型、支持客戶端式分佈式集羣、一致性hash
多核結構、多線程讀寫性能高。
缺點：無持久化、節點故障可能出現緩存穿透、分佈式須要客戶端實現、跨機房數據同步困難、
架構擴容複雜度高
Redis:
優勢：高性能讀寫、多數據類型支持、數據持久化、高可用架構、支持自定義虛擬內存、
支持分佈式分片集羣、單線程讀寫性能極高
缺點：多線程讀寫較Memcached慢
Tair：
優勢：高性能讀寫、支持三種存儲引擎（ddb、rdb、ldb）、支持高可用、支持分佈式分片集羣、
支撐了幾乎全部淘寶業務的緩存。
缺點：單機狀況下，讀寫性能較其餘兩種產品較慢
對比測試
總結：mysql
對三款產品的單用戶和多用戶的操做的性能的對比，差別git
Memcache是多核的處理模式，能夠支持更多的併發能力github
Redis支持少許的併發，而且發起屢次修改或者讀取的能力web
在單臺主機上裝單個redis，並不具有優點！能夠在單臺機器上裝多實例實現更高的併發！！面試
redis應用場景
數據高速緩存
web會話緩存（Session Cache）
排行榜應用
消息隊列
發佈訂閱
等
Redis安裝及基本配置
安裝
有兩個要求：一、去官網下載；二、下載6-12月的版本redis
下載： 解壓： 上傳至 /data 或者你喜歡的目錄 tar xzf redis-3.2.12.tar.gz mv redis-3.2.12 redis 安裝： cd redis make 修改環境變量，將src加入到文件中 vim /etc/profile export PATH=/application/mysql/bin/:/data/redis/src:$PATH
使生效 source /etc/profile
啓動和簡易鏈接： redis-server & redis-cli
配置文件
手動建立一個目錄，建立配置文件
mkdir /data/6379 vim /data/6379/redis.conf daemonize yes port 6379 logfile /data/6379/redis.log dir /data/6379 dbfilename dump.rdb 127.0.0.1:6379> shutdown 關閉 not connected> exit [root@db01 6379]# redis-server /data/6379/redis.conf 重啓，帶上配置文件 [root@db03 ~]# netstat -lnp|grep 63 redis-cli shutdown 在命令行關閉 +++++++++++配置文件說明++++++++++++++ redis.conf 是否後臺運行： daemonize yes 默認端口： port 6379 日誌文件位置 logfile /var/log/redis.log 持久化文件存儲位置 dir /data/6379 RDB持久化數據文件: dbfilename dump.rdb +++++++++++++++++++++++++ ------------------------- redis安全配置 （1）redis沒有用戶概念，redis只有密碼 （2）redis默認工做在保護模式下。不容許遠程任何用戶登陸的（protected-mode） protected-mode yes/no （保護模式，是否只容許本地訪問，遠程能夠登陸，可是沒法操做） ---------------------- DENIED Redis is running in protected mode because protected mode is enabled, no bind address was specified, no authentication password is requested to clients. In this mode connections are only accepted from the loopback interface. If you want to connect from external computers to Redis you may adopt one of the following solutions: 1)Just disable protected mode sending the command 'CONFIG SET protected-mode no' from the loopback interface by connecting to Redis from the same host the server is running, however MAKE SURE Redis is not publicly accessible from internet if you do so. Use CONFIG REWRITE to make this change permanent. 2) Alternatively you can just disable the protected mode by editing the Redis configuration file, and setting the protected mode option to 'no', and then restarting the server. 3) If you started the server manually just for testing, restart it with the '--protected-mode no' option. 4) Setup a bind address or an authentication password. NOTE: You only need to do one of the above things in order for the server to start accepting connections from the outside. ---------------------- (1)Bind :指定IP進行監聽 vim /data/6379/redis.conf bind 10.0.0.52 127.0.0.1 (2)增長requirepass {password} vim /data/6379/redis.conf requirepass root 重啓生效： redis-cli shutdown 關閉 redis-server /data/6379/redis.conf 帶上配置文件啓動 ----------驗證--------- 方法一： [root@db03 ~]# redis-cli -a root 127.0.0.1:6379> set name zhangsan OK 127.0.0.1:6379> exit 方法二： [root@db03 ~]# redis-cli 127.0.0.1:6379> auth root OK 127.0.0.1:6379> set a b ------------------------ 在線查看和修改配置 CONFIG GET * 獲取全部配置信息 ，兩行是一個參數 在先修改，不用重啓redis，下次登陸就生效，但也不是全部的參數都能在線修改 CONFIG GET requirepass CONFIG SET requirepass 123456 ------------------
Redis持久化
RDB 持久化 能夠在指定的時間間隔內生成數據集的時間點快照（point-in-time snapshot）。
優勢：速度快，適合於用作備份，主從複製也是基於RDB持久化功能實現的。
缺點：會有數據丟失 AOF 持久化 記錄服務器執行的全部寫操做命令，並在服務器啓動時，經過從新執行這些命令來還原數據集。
AOF 文件中的命令所有以 Redis 協議的格式來保存，新命令會被追加到文件的末尾。
優勢：能夠最大程度保證數據不丟
缺點：日誌記錄量級比較大
RDB的優勢算法
RDB是一種表示某個即時點的Redis數據的緊湊文件。
RDB文件適合用於備份。
例如，你可能想要每小時歸檔最近24小時的RDB文件，天天保存近30天的RDB快照。
這容許你很容易的恢復不一樣版本的數據集以容災。
RDB很是適合於災難恢復，做爲一個緊湊的單一文件，能夠被傳輸到遠程的數據中心。
RDB最大化了Redis的性能，由於Redis父進程持久化時惟一須要作的是啓動(fork)一個子進程，
由子進程完成全部剩餘工做。父進程實例不須要執行像磁盤IO這樣的操做。
RDB在重啓保存了大數據集的實例時比AOF要快。
RDB缺點sql
當你須要在Redis中止工做(例如停電)時最小化數據丟失，RDB可能不太好。
你能夠配置不一樣的保存點(save point)來保存RDB文件(例如，至少5分鐘和對數據集100次寫以後，
可是你能夠有多個保存點)。然而，你一般每隔5分鐘或更久建立一個RDB快照，
因此一旦Redis由於任何緣由沒有正確關閉而中止工做，你就得作好最近幾分鐘數據丟失的準備了。
RDB須要常常調用fork()子進程來持久化到磁盤。
若是數據集很大的話，fork()比較耗時，
結果就是，當數據集很是大而且CPU性能不夠強大的話，Redis會中止服務客戶端幾毫秒甚至一秒。
AOF也須要fork()，可是你能夠調整多久頻率重寫日誌而不會有損(trade-off)持久性(durability)。
RDB普通配置參數
vim /data/6379/redis.conf dir /data/6379 dbfilename dump.rdb save 900 1 save 300 10 save 60 10000 配置分別表示： 900秒（15分鐘）內有1個更改 300秒（5分鐘）內有10個更改 60秒內有10000個更改
若是不設置上面的條件配置，何時使用save命令，何時纔會持久化
RDB持久化高級配置
stop-writes-on-bgsave-error yes rdbcompression yes rdbchecksum yes dbfilename dump.rdb dir ./
以上配置分別表示： 後臺備份進程出錯時,主進程停不中止寫入? 主進程不中止容易形成數據不一致 導出的rdb文件是否壓縮 若是rdb的大小很大的話建議這麼作 導入rbd恢復時數據時,要不要檢驗rdb的完整性 驗證版本是否是一致 導出來的rdb文件名 rdb的放置路徑
AOF持久化配置
appendonly yes
appendfsync always
appendfsync everysec
appendfsync no
是否打開aof日誌功能
每1個命令,都當即同步到aof
每秒寫1次
寫入工做交給操做系統,由操做系統判斷緩衝區大小,統一寫入到aof.
vim /data/6379/redis.conf
appendonly yes
appendfsync everysec
AOF持久化高級配置
no-appendfsync-on-rewrite yes/no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 配置分別表示： 正在導出rdb快照的過程當中,要不要中止同步aof aof文件大小比起上次重寫時的大小,增加率100%時重寫,缺點:業務開始的時候，會重複重寫屢次。 aof文件,至少超過64M時,重寫
RDB到AOF的切換
在 Redis 2.2 或以上版本，能夠在不重啓的狀況下，從 RDB 切換到 AOF ： 1、爲最新的 dump.rdb 文件建立一個備份。 2、將備份放到一個安全的地方。 3、執行如下兩條命令： redis-cli> CONFIG SET appendonly yes redis-cli> CONFIG SET save "" 4、確保命令執行以後，數據庫的鍵的數量沒有改變。 5、確保寫命令會被正確地追加到 AOF 文件的末尾
步驟 3 執行的第一條命令開啓了 AOF 功能，Redis 會阻塞直到初始 AOF 文件建立完成爲止， 以後 Redis 會繼續處理命令請求，並開始將寫入命令追加到 AOF 文件末尾。
步驟 3 執行的第二條命令用於關閉 RDB 功能。這一步是可選的，若是你願意的話，也能夠同時使用 RDB 和 AOF 這兩種持久化功能。
注意：別忘了在 redis.conf 中打開 AOF 功能！ 不然的話， 服務器重啓以後， 以前經過 CONFIG SET 設置的配置就會被遺忘， 程序會按原來的配置來啓動服務器。
面試題
redis 持久化方式有哪些？有什麼區別？
rdb：基於快照的持久化，速度更快，通常用做備份，主從複製也是依賴於rdb持久化功能
aof：以追加的方式記錄redis操做日誌的文件。能夠最大程度的保證redis數據安全，
相似於mysql的binlog
Redis多數據類型開發（瞭解）
數據類型（value）種類
- String
- Hash
- List
- Set
- Sorted set
經常使用的key（自主定製名字）操做
KEYS * 查看KEY支持通配符
DEL 刪除給定的一個或多個key
EXISTS 檢查是否存在
TYPE 返回鍵所存儲值的類型
EXPIRE\ PEXPIRE 以秒\毫秒設定生存時間
TTL\ PTTL 以秒\毫秒爲單位返回生存時間
PERSIST 取消生存實現設置
刪
flushdb 清空當前選擇的數據庫
del mykey mykey2 刪除了兩個 Keys
改
move mysetkey 1 將當前數據庫中的 mysetkey 鍵移入到 ID 爲 1 的數據庫中
rename mykey mykey1 將 mykey 更名爲 mykey1
renamenx oldkey newkey 若是 newkey 已經存在，則無效
expire mykey 100 將該鍵的超時設置爲 100 秒
persist mykey 將該 Key 的超時去掉,變成持久化的鍵
查
keys my* 獲取當前數據庫中全部以my開頭的key
exists mykey 若不存在,返回0;存在返回1
select 0 打開 ID 爲 0 的數據庫
ttl mykey 查看存貨時間還剩下多少秒
type mykey 返回mykey對應的值的類型
randomkey 返回數據庫中的任意鍵
string（字符串）
形式比喻：name 「張山」
定義：
string是redis最基本的類型，一個key對應一個value。
一個鍵最大能存儲512MB。
String類型有以下基本操做（官網）：
set
get
incr 計數+1
incrby 能夠指定數量，一次性添加
decr 計數-1
decrby 指定數量
mset 同時設置多個鍵值對
mget
append
getset
setex
setnx
del
setrange
strlen
getrange
應用場景
基本的鍵值對存儲
常規計數：微博數，粉絲數等
遊戲應用，如血量、魔法值
增
set mykey "test" 爲鍵設置新值，並覆蓋原有值
getset mycounter 0 設置值,取值同時進行
setex mykey 10 "hello" 設置指定 Key 的過時時間爲10秒,在存活時間能夠獲取value
setnx mykey "hello" 若該鍵不存在，則爲鍵設置新值
mset key3 "zyx" key4 "xyz" 批量設置鍵
刪
del mykey 刪除已有鍵
改
append mykey "hello" 若該鍵並不存在,返回當前 Value 的長度
該鍵已經存在，返回追加後 Value的長度
incr mykey 值增長1,若該key不存在,建立key,初始值設爲0,增長後結果爲1
decrby mykey 5 值減小5
setrange mykey 20 dd 把第21和22個字節,替換爲dd, 超過value長度,自動補0
查
exists mykey 判斷該鍵是否存在，存在返回 1，不然返回0
get mykey 獲取Key對應的value
strlen mykey 獲取指定 Key 的字符長度
ttl mykey 查看一下指定 Key 的剩餘存活時間(秒數)
getrange mykey 1 20 獲取第2到第20個字節,若20超過value長度,則截取第2個和後面全部的
mget key3 key4 批量獲取鍵
Hash（字典）
最接近MySQL表結構的數據類型
形式比喻：stu：{id:101,name:zhangsan}
定義：
咱們能夠將Redis中的Hashes類型當作具備String Key和String Value的map容器。
因此該類型很是適合於存儲值對象的信息。如Username、Password和Age等。
若是Hash中包含不多的字段，那麼該類型的數據也將僅佔用不多的磁盤空間。
每個Hash能夠存儲4294967295個鍵值對。
hash類型有以下操做：
hset
hsetnx
hmset
hdel
del
hincrby
hget
hmget
hlen
hexists
hgetall
hkeys
hvals
應用場景：
存儲部分變動的數據，如用戶信息等。
127.0.0.1:6379> hset zhangsan name zs 插入
(integer) 1
127.0.0.1:6379> hmset student id 101 name zs age 20 gender male 插入多個
OK
127.0.0.1:6379> hmset stu id 102 name lisi age 21 gender male
OK
127.0.0.1:6379> hmget stu id name age gender 獲取指定值
1) "102"
2) "lisi"
3) "21"
4) "male"
127.0.0.1:6379> hgetall stu 獲取所有鍵值對
1) "id"
2) "102"
3) "name"
4) "lisi"
5) "age"
6) "21"
7) "gender"
8) "male"
做業：
MySQL 中 city表中前10行數據，灌入到redis
mysql> select concat("hmset stu_",name," id ",id," name ",name) from t1;
+---------------------------------------------------+
| concat("hmset stu_",name," id ",id," name ",name) |
+---------------------------------------------------+
| hmset stu_zhang3 id 1 name zhang3 |
| hmset stu_li4 id 2 name li4 |
| hmset stu_wang5 id 3 name wang5 |
+---------------------------------------------------+
增
hset myhash field1 "s"
若字段field1不存在,建立該鍵及與其關聯的Hashes, Hashes中,key爲field1 ,並設value爲s ，若存在會覆蓋原value
hsetnx myhash field1 s
若字段field1不存在,建立該鍵及與其關聯的Hashes, Hashes中,key爲field1 ,並設value爲s， 若字段field1存在,則無效
hmset myhash field1 "hello" field2 "world 一次性設置多個字段
刪
hdel myhash field1 刪除 myhash 鍵中字段名爲 field1 的字段
del myhash 刪除鍵
改
hincrby myhash field 1 給field的值加1
查
hget myhash field1 獲取鍵值爲 myhash,字段爲 field1 的值
hlen myhash 獲取myhash鍵的字段數量
hexists myhash field1 判斷 myhash 鍵中是否存在字段名爲 field1 的字段
hmget myhash field1 field2 field3 一次性獲取多個字段
hgetall myhash 返回 myhash 鍵的全部字段及其值
hkeys myhash 獲取myhash 鍵中全部字段的名字
hvals myhash 獲取 myhash 鍵中全部字段的值
LIST(列表)
形式比喻：webchat [m1,m2,m3]
定義：
List類型是按照插入順序排序的字符串鏈表。
和數據結構中的普通鏈表同樣，咱們能夠在其頭部(left)和尾部(right)添加新的元素。
在插入時，若是該鍵並不存在，Redis將爲該鍵建立一個新的鏈表。
與此相反，若是鏈表中全部的元素均被移除，那麼該鍵也將會被從數據庫中刪除。
List中能夠包含的最大元素數量是4294967295。
經常使用操做： lpush lpushx linsert rpush rpushx rpoplpush del lrem ltrim lset rpoplpush lrange lpop lindex 應用場景
微信朋友圈
首先看到的是最新的 消息隊列系統 好比sina微博: 在Redis中咱們的最新微博ID使用了常駐緩存，這是一直更新的。
可是作了限制不能超過5000個ID，所以獲取ID的函數會一直詢問Redis。
只有在start/count參數超出了這個範圍的時候，才須要去訪問數據庫。
系統不會像傳統方式那樣「刷新」緩存，Redis實例中的信息永遠是一致的。
SQL數據庫（或是硬盤上的其餘類型數據庫）只是在用戶須要獲取「很遠」的數據時纔會被觸發，
而主頁或第一個評論頁是不會麻煩到硬盤上的數據庫了。
127.0.0.1:6379> LPUSH wechat "today is 1"
(integer) 1
127.0.0.1:6379> LPUSH wechat "today is 2"
(integer) 2
127.0.0.1:6379> LPUSH wechat "today is 3"
(integer) 3
127.0.0.1:6379> LPUSH wechat "today is 4"
(integer) 4
127.0.0.1:6379> LPUSH wechat "today is 5"
127.0.0.1:6379> LRANGE wechat 0 -1 第一個到最後一個
1) "today is 5"
2) "today is 4"
3) "today is 3"
4) "today is 2"
5) "today is 1"
增
lpush mykey a b 若key不存在,建立該鍵及與其關聯的List,依次插入a ,b， 若List類型的key存在,則插入value中
lpushx mykey2 e 若key不存在,此命令無效， 若key存在,則插入value中
linsert mykey before a a1 在 a 的前面插入新元素 a1
linsert mykey after e e2 在e 的後面插入新元素 e2
rpush mykey a b 在鏈表尾部先插入b,在插入a
rpushx mykey e 若key存在,在尾部插入e, 若key不存在,則無效
rpoplpush mykey mykey2 將mykey的尾部元素彈出,再插入到mykey2 的頭部(原子性的操做)
刪
del mykey 刪除已有鍵
lrem mykey 2 a 從頭部開始找,按前後順序,值爲a的元素,刪除數量爲2個,若存在第3個,則不刪除
ltrim mykey 0 2 從頭開始,索引爲0,1,2的3個元素,其他所有刪除
改
lset mykey 1 e 從頭開始, 將索引爲1的元素值,設置爲新值 e,若索引越界,則返回錯誤信息
rpoplpush mykey mykey 將 mykey 中的尾部元素移到其頭部
查
lrange mykey 0 -1 取鏈表中的所有元素，其中0表示第一個元素,-1表示最後一個元素。
lrange mykey 0 2 從頭開始,取索引爲0,1,2的元素
lrange mykey 0 0 從頭開始,取第一個元素,從第0個開始,到第0個結束
lpop mykey 獲取頭部元素,而且彈出頭部元素,出棧
lindex mykey 6 從頭開始,獲取索引爲6的元素 若下標越界,則返回nil
SET（集合）
形式比喻：weibo (m1,m2,m3)
定義：
Set類型看做爲沒有排序的字符集合。
Set可包含的最大元素數量是4294967295。
若是屢次添加相同元素，Set中將僅保留該元素的一份拷貝。
經常使用操做：
sadd 建立
spop
srem
smove
sismember
smembers
scard
srandmember
sdiff 差集
sdiffstore
sinter 交集
sinterstore
sunion 並集
sunionstore
應用場景：
案例： 在微博應用中，能夠將一個用戶全部的關注人存在一個集合中，將其全部粉絲存在一個集合。
Redis還爲集合提供了求交集、並集、差集等操做，
能夠很是方便的實現如共同關注、共同喜愛、二度好友等功能，
對上面的全部集合操做，你還能夠使用不一樣的命令選擇將結果返回給客戶端仍是存集到一個新的集合中。
127.0.0.1:6379> sadd lxl pg1 pg2 baoqiang masu marong
(integer) 5
127.0.0.1:6379> sadd jnl baoqiang yufan baobeier zhouxingchi
(integer) 4
127.0.0.1:6379> SUNION lxl jnl 並集
1) "zhouxingchi"
2) "baobeier"
3) "pg2"
4) "yufan"
5) "masu"
6) "baoqiang"
7) "pg1"
8) "marong"
127.0.0.1:6379>
127.0.0.1:6379> SINTER lxl jnl 交集
1) "baoqiang"
127.0.0.1:6379> SDIFF lxl jnl 差集
1) "masu"
2) "pg1"
3) "marong"
4) "pg2"
127.0.0.1:6379> SDIFF jnl lxl 差集
1) "yufan"
2) "zhouxingchi"
3) "baobeier"
增
sadd myset a b c
若key不存在,建立該鍵及與其關聯的set,依次插入a ,b,若key存在,則插入value中,若a 在myset中已經存在,則插入了 d 和 e 兩個新成員。
刪
spop myset 尾部的b被移出,事實上b並非以前插入的第一個或最後一個成員
srem myset a d f 若f不存在, 移出 a、d ,並返回2
改
smove myset myset2 a 將a從 myset 移到 myset2，
查
sismember myset a 判斷 a 是否已經存在，返回值爲 1 表示存在。
smembers myset 查看set中的內容
scard myset 獲取Set 集合中元素的數量
srandmember myset 隨機的返回某一成員
sdiff myset1 myset2 myset3 1和2獲得一個結果,拿這個集合和3比較,得到每一個獨有的值
sdiffstore diffkey myset myset2 myset3 3個集和比較,獲取獨有的元素,並存入diffkey 關聯的Set中
sinter myset myset2 myset3 得到3個集合中都有的元素
sinterstore interkey myset myset2 myset3 把交集存入interkey 關聯的Set中
sunion myset myset2 myset3 獲取3個集合中的成員的並集
sunionstore unionkey myset myset2 myset3 把並集存入unionkey 關聯的Set中
SortedSet（有序集合）
形式比喻：weibo (socre m1,score m2,score m3)
定義：
Sorted-Sets中的每個成員都會有一個分數(score)與之關聯，
Redis正是經過分數來爲集合中的成員進行從小到大的排序。
成員是惟一的，可是分數(score)倒是能夠重複的。 經常使用操做 zadd zrem zincrby zrange zrank zcard zcount zscore zrangebyscore zremrangebyscore zremrangebyrank zrevrange zrevrangebyscore zrevrangebyscore 應用場景： 排行榜應用，
取TOP N操做 這個需求與上面需求的不一樣之處在於，前面操做以時間爲權重，
這個是以某個條件爲權重，好比按頂的次數排序，這時候就須要咱們的sorted set出馬了，
將你要排序的值設置成sorted set的score，將具體的數據設置成相應的value，
每次只須要執行一條ZADD命令便可。
127.0.0.1:6379> zadd music 0 fskl 0 fshkl 0 lzlsfs 0 tm 0 ass
(integer) 5
127.0.0.1:6379> ZINCRBY music 1000 fskl
"1000"
127.0.0.1:6379> ZINCRBY music 10000 fshkl
"10000"
127.0.0.1:6379> ZINCRBY music 100000 lzlsfs
"100000"
127.0.0.1:6379> ZINCRBY music 1000000 tm
"1000000"
127.0.0.1:6379> ZINCRBY music 100 ass
"100"
127.0.0.1:6379> ZREVRANGE music 0 -1 withscores
1) "tm"
2) "1000000"
3) "lzlsfs"
4) "100000"
5) "fshkl"
6) "10000"
7) "fskl"
8) "1000"
9) "ass"
10) "100"
127.0.0.1:6379> ZREVRANGE music 0 -1
1) "tm"
2) "lzlsfs"
3) "fshkl"
4) "fskl"
5) "ass"
增
zadd myzset 2 "two" 3 "three" 添加兩個分數分別是 2 和 3 的兩個成員
刪
zrem myzset one two 刪除多個成員變量,返回刪除的數量
改
zincrby myzset 2 one 將成員 one 的分數增長 2，並返回該成員更新後的分數
查
zrange myzset 0 -1 WITHSCORES 返回全部成員和分數,不加WITHSCORES,只返回成員
zrank myzset one 獲取成員one在Sorted-Set中的位置索引值。0表示第一個位置
zcard myzset 獲取 myzset 鍵中成員的數量
zcount myzset 1 2 獲取分數知足表達式 1 <= score <= 2 的成員的數量
zscore myzset three 獲取成員 three 的分數
zrangebyscore myzset 1 2 獲取分數知足表達式 1 < score <= 2 的成員
#-inf 表示第一個成員，+inf最後一個成員
#limit限制關鍵字
#2 3 是索引號
zrangebyscore myzset -inf +inf limit 2 3 返回索引是2和3的成員
zremrangebyscore myzset 1 2 刪除分數 1<= score <= 2 的成員，並返回實際刪除的數量
zremrangebyrank myzset 0 1 刪除位置索引知足表達式 0 <= rank <= 1 的成員
zrevrange myzset 0 -1 WITHSCORES 按位置索引從高到低,獲取全部成員和分數
#原始成員:位置索引從小到大
one 0
two 1
#執行順序:把索引反轉
位置索引:從大到小
one 1
two 0
#輸出結果: two
one
zrevrange myzset 1 3 獲取位置索引,爲1,2,3的成員
#相反的順序:從高到低的順序
zrevrangebyscore myzset 3 0 獲取分數 3>=score>=0的成員並以相反的順序輸出
zrevrangebyscore myzset 4 0 limit 1 2 獲取索引是1和2的成員,並反轉位置索引
生產消費者模型
消息模式
Redis發佈消息一般有兩種模式： 隊列模式（queuing） 發佈-訂閱模式(publish-subscribe) 任務隊列的好處： 鬆耦合。 易於擴展。
Redis 發佈--訂閱
其實從Pub/Sub的機制來看，它更像是一個廣播系統，多個Subscriber能夠訂閱多個Channel，
多個Publisher能夠往多個Channel中發佈消息。能夠這麼簡單的理解：
Subscriber：收音機，能夠收到多個頻道，並以隊列方式顯示
Publisher：電臺，能夠往不一樣的FM頻道中發消息
Channel：不一樣頻率的FM頻道
一個Publisher，多個Subscriber模型
以下圖所示，能夠做爲消息隊列或者消息管道。
主要應用：通知、公告
多個Publisher，一個Subscriber模型
能夠將PubSub作成獨立的HTTP接口，各應用程序做爲Publisher向Channel中發送消息，
Subscriber端收到消息後執行相應的業務邏輯，好比寫數據庫，顯示等等。
主要應用：排行榜、投票、計數。
多個Publisher，多個Subscriber模型
故名思議，就是能夠向不一樣的Channel中發送消息，由不一樣的Subscriber接收。
主要應用：羣聊、聊天。
發佈訂閱實踐
PUBLISH channel msg 將信息 message 發送到指定的頻道 channel SUBSCRIBE channel [channel ...] 訂閱頻道，能夠同時訂閱多個頻道 UNSUBSCRIBE [channel ...] 取消訂閱指定的頻道, 若是不指定頻道，則會取消訂閱全部頻道 PSUBSCRIBE pattern [pattern ...] 訂閱一個或多個符合給定模式的頻道，每一個模式以 * 做爲匹配符，
好比 it* 匹配所 有以 it 開頭的頻道( it.news 、 it.blog 、 it.tweets 等等)，
news.* 匹配全部 以 news. 開頭的頻道( news.it 、 news.global.today 等等)，
諸如此類 PUNSUBSCRIBE [pattern [pattern ...]] 退訂指定的規則, 若是沒有參數則會退訂全部規則 PUBSUB subcommand [argument [argument ...]] 查看訂閱與發佈系統狀態 注意：使用發佈訂閱模式實現的消息隊列，當有客戶端訂閱channel後只能收到後續發佈到該頻道的消息，
以前發送的不會緩存，必須Provider和Consumer同時在線。
發佈訂閱例子：
窗口1：
127.0.0.1:6379> SUBSCRIBE baodi
窗口2：
127.0.0.1:6379> PUBLISH baodi "jin tian zhen kaixin!"
訂閱多頻道：
窗口1：
127.0.0.1:6379> PSUBSCRIBE wang*
窗口2：
127.0.0.1:6379> PUBLISH wangbaoqiang "jintian zhennanshou
消息隊列系統對比
客戶端在執行訂閱命令以後進入了訂閱狀態
只能接收 SUBSCRIBE 、PSUBSCRIBE、 UNSUBSCRIBE 、PUNSUBSCRIBE 四個命令。
開啓的訂閱客戶端，沒法收到該頻道以前的消息，由於 Redis 不會對發佈的消息進行持久化。
和不少專業的消息隊列系統（例如Kafka、RocketMQ）相比，Redis的發佈訂閱略顯粗糙，
例如：沒法實現消息堆積和回溯。
但勝在足夠簡單，若是當前場景能夠容忍的這些缺點，也不失爲一個不錯的選擇。
redis事務管理
redis中的事務跟關係型數據庫中的事務是一個類似的概念，可是有不一樣之處。
關係型數據庫事務執行失敗後面的sql語句不在執行，而redis中的一條命令執行失敗，其他的命令照常執行
redis中開啓一個事務是使用multi，至關於begin\start transaction，
exec提交事務，discard取消隊列命令（非回滾操做）。
事務命令
DISCARD
取消事務，放棄執行事務塊內的全部命令。
EXEC
執行全部事務塊內的命令。
MULTI
標記一個事務塊的開始。
UNWATCH
取消 WATCH 命令對全部 key 的監視。
WATCH key [key ...] -- 樂觀鎖
監視一個(或多個) key ，若是在事務執行以前這個(或這些) key 被其餘命令所改動，
那麼事務將被打斷。
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set a 1
QUEUED 放入了隊列中，並無執行
127.0.0.1:6379> set b 2
QUEUED
127.0.0.1:6379> set c 3
QUEUED
127.0.0.1:6379> exec 提交纔回執行
1) OK
2) OK
3) OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set a 10
QUEUED
127.0.0.1:6379> set b 20
QUEUED
127.0.0.1:6379> set c 30
QUEUED
127.0.0.1:6379> DISCARD 取消後，就不執行了
OK
redis事務中的鎖機制
舉例：我正在買票 Ticket -1 , money -100 而票只有1張, 若是在我multi以後,和exec以前, 票被別人買了，即ticket變成0了. 我該如何觀察這種情景,並再也不提交 悲觀的想法: 世界充滿危險,確定有人和我搶, 給ticket上鎖, 只有我能操做. [悲觀鎖] 樂觀的想法: 沒有那麼多人和我搶,所以,我只須要注意,有沒有人更改ticket的值就能夠了 [樂觀鎖]
redis就是樂觀鎖的機制
服務器管理命令
Info 數據庫狀態信息
重點關注Memory和Replication Clinet list Client kill ip:port config get * CONFIG GET/SET 動態修改 Dbsize 查看當前庫key的個數 FLUSHALL 清空全部數據 包括已經持久化的信息 select 1 根據索引進入相應的庫 redis中有16個庫， FLUSHDB 清空當前庫 MONITOR 監控實時指令 SHUTDOWN 關閉服務器 save將當前數據保存 SLAVEOF host port 主從配置 SLAVEOF NO ONE SYNC 主從同步 ROLE返回主從角色
Redis複製及高可用
使用異步複製。
一個主服務器能夠有多個從服務器。
從服務器也能夠有本身的從服務器。
複製功能不會阻塞主服務器。
能夠經過複製功能來讓主服務器免於執行持久化操做，由從服務器去執行持久化操做便可。
但仍是建議打開，防止雪崩災難致使數據丟失
當配置Redis複製功能時，強烈建議打開主服務器的持久化功能。
不然的話，因爲延遲等問題，部署的服務應該要避免自動拉起。 爲了幫助理解主服務器關閉持久化時自動拉起的危險性，參考如下會致使主從服務器數據所有丟失的例子： 1. 假設節點A爲主服務器，而且關閉了持久化。 而且節點B和節點C從節點A複製數據 2. 節點A崩潰，而後由自動拉起服務重啓了節點A. 因爲節點A的持久化被關閉了，
因此重啓以後沒有任何數據 3. 節點B和節點C將從節點A複製數據，可是A的數據是空的， 因而就把自身保存的數據副本刪除。 在關閉主服務器上的持久化，
並同時開啓自動拉起進程的狀況下，即使使用Sentinel來實現Redis的高可用性，也是很是危險的。
由於主服務器可能拉起得很是快，
以致於Sentinel在配置的心跳時間間隔內沒有檢測到主服務器已被重啓，
而後仍是會執行上面的數據丟失的流程。 不管什麼時候，數據安全都是極其重要的，因此應該禁止主服務器關閉持久化的同時自動拉起。
如下是關於 Redis 複製功能的幾個重要方面：
Redis 使用異步複製。 從 Redis 2.8 開始， 從服務器會以每秒一次的頻率向主服務器報告複製流（replication stream）的處理進度。
一個主服務器能夠有多個從服務器。
不只主服務器能夠有從服務器， 從服務器也能夠有本身的從服務器， 多個從服務器之間能夠構成一個圖狀結構。
複製功能不會阻塞主服務器： 即便有一個或多個從服務器正在進行初次同步， 主服務器也能夠繼續處理命令請求。
複製功能也不會阻塞從服務器： 只要在 redis.conf 文件中進行了相應的設置， 即便從服務器正在進行初次同步，
服務器也能夠使用舊版本的數據集來處理命令查詢。
不過， 在從服務器刪除舊版本數據集並載入新版本數據集的那段時間內， 鏈接請求會被阻塞。
你還能夠配置從服務器， 讓它在與主服務器之間的鏈接斷開時， 向客戶端發送一個錯誤。
複製功能能夠單純地用於數據冗餘（data redundancy）， 也能夠經過讓多個從服務器處理只讀命令請求來提高擴展性（scalability）：
好比說， 繁重的 SORT 命令能夠交給附屬節點去運行。
能夠經過複製功能來讓主服務器免於執行持久化操做： 只要關閉主服務器的持久化功能， 而後由從服務器去執行持久化操做便可。
主從複製原理
1. 從服務器向主服務器發送 SYNC 命令。 2. 接到 SYNC 命令的主服務器會調用BGSAVE 命令，建立一個 RDB 文件，並使用緩衝區記錄接下來執行的全部寫命令。 3. 當主服務器執行完 BGSAVE 命令時，它會向從服務器發送 RDB 文件，而從服務器則會接收並載入這個文件。 4. 主服務器將緩衝區儲存的全部寫命令發送給從服務器執行。
1、在開啓主從複製的時候，使用的是RDB方式的，同步主從數據的 2、同步開始以後，經過主庫命令傳播的方式，主動的複製方式實現 3、2.8之後實現PSYNC的機制，實現斷線重連
SYNC命令執行過程
在主從服務器完成同步以後，
主服務器每執行一個寫命令，它都會將被執行的寫命令發送給從服務器執行，
這個操做被稱爲「命令傳播」（command propagate）。
命令傳播是一個持續的過程：只要複製仍在繼續，命令傳播就會一直進行，使得主從服務器的狀態能夠一直保持一致。
複製中的SYNC和PSYNC
在 Redis 2.8 版本以前，
斷線以後重連的從服務器總要執行一次完整重同步（full resynchronization）操做。 從 Redis 2.8 開始，Redis 使用 PSYNC命令代替 SYNC 命令。 PSYNC 比起 SYNC 的最大改進在於 PSYNC 實現了部分重同步（partial resync）
特性：在主從服務器斷線而且從新鏈接的時候，只要條件容許，PSYNC 可讓主服務器只向從服務器同步斷線期間缺失的數據，
而不用從新向從服務器同步整個數據庫。
SYNC處理斷線重連方式
PSYNC處理斷線重連
複製的一致性的問題
爲了實現主從複製，讀寫分離的結構，同時，也產生了數據一致性的問題
固然，不止是redis，mysql也會有這個問題
一、在讀寫分離環境下，客戶端向主服務器發送寫命令 SET n 10086，
主服務器在執行這個寫命令以後，向客戶端返回回覆，並將這個寫命令傳播給從服務器。
二、接到回覆的客戶端繼續向從服務器發送讀命令 GET n
而且因爲網絡狀態的緣由，客戶端的 GET命令比主服務器傳播的 SET 命令更快到達了從服務器。 三、由於從服務器鍵 n 的值還未被更新，因此客戶端在從服務器讀取到的將是一個錯誤（過時）的 n值。
複製安全性提高
主服務器只在有至少 N 個從服務器的狀況下，才執行寫操做 從 Redis 2.8 開始， 爲了保證數據的安全性， 能夠經過配置， 讓主服務器只在有至少 N 個當前已鏈接從服務器的狀況下， 才執行寫命令。 不過， 由於 Redis 使用異步複製， 因此主服務器發送的寫數據並不必定會被從服務器接收到， 所以， 數據丟失的可能性仍然是存在的。 經過如下兩個參數保證數據的安全： min-slaves-to-write <number of slaves>
最少寫入的從庫數量，默認沒有開啓，最少有幾臺從庫完完整整的接收成功了，
不然阻塞 min-slaves-max-lag <number of seconds>
最小延遲時間，從庫的網絡延遲時間在範圍內，才認定是執行成功的
這個特性的運做原理：
從服務器以每秒一次的頻率 PING 主服務器一次， 並報告複製流的處理狀況。
主服務器會記錄各個從服務器最後一次向它發送 PING 的時間。
用戶能夠經過配置， 指定網絡延遲的最大值 min-slaves-max-lag ，
以及執行寫操做所需的至少從服務器數量 min-slaves-to-write 。
若是至少有 min-slaves-to-write 個從服務器， 而且這些服務器的延遲值都少於 min-slaves-max-lag秒，
那麼主服務器就會執行客戶端請求的寫操做。
你能夠將這個特性看做 CAP 理論中的 C 的條件放寬版本： 儘管不能保證寫操做的持久性，
但起碼丟失數據的窗口會被嚴格限制在指定的秒數中。
另外一方面， 若是條件達不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的條件， 那麼寫操做就不會被執行
主服務器會向請求執行寫操做的客戶端返回一個錯誤。
主從複製實踐
1、環境： 準備兩個或兩個以上redis實例 mkdir /data/638{0..2} 配置文件示例： vim /data/6380/redis.conf port 6380 daemonize yes pidfile /data/6380/redis.pid loglevel notice logfile "/data/6380/redis.log" dbfilename dump.rdb dir /data/6380 protected-mode no vim /data/6381/redis.conf port 6381 daemonize yes pidfile /data/6381/redis.pid loglevel notice logfile "/data/6381/redis.log" dbfilename dump.rdb dir /data/6381 protected-mode no vim /data/6382/redis.conf port 6382 daemonize yes pidfile /data/6382/redis.pid loglevel notice logfile "/data/6382/redis.log" dbfilename dump.rdb dir /data/6382 protected-mode no 啓動： redis-server /data/6380/redis.conf redis-server /data/6381/redis.conf redis-server /data/6382/redis.conf 主節點：6380 從節點：6381、6382 2、開啓主從： 6381/6382命令行:
構建 redis-cli -p 6381 SLAVEOF 127.0.0.1 6380 redis-cli -p 6382 SLAVEOF 127.0.0.1 6380
Redis主從複製管理和切換
主從複製狀態監控： info replication 主從切換： slaveof no one
模擬主庫故障
redis-cli -p 6380 shutdown
登錄從庫
redis-cli -p 6381
info replication 發現主庫down了
選擇最完整的一臺從庫，取消從庫角色
slaveof no one
將另一臺從新構建
6382鏈接到6381：
[root@db03 ~]# redis-cli -p 6382
127.0.0.1:6382> SLAVEOF no one
127.0.0.1:6382> SLAVEOF 127.0.0.1 6381
Redis高可用
在以前，主庫宕機以後，咱們經過一系列的手動操做完成了主從的切換
可是，在咱們手動實現的時候有不少不足的地方
一、純手工--- 咱們不能24小時盯着全部的服務器，在使用監控軟件時也會有一系列的等待和延遲
二、選主的問題---不夠嚴謹
三、手工指定新主從後，客戶端還不能知道新主，要修改APP中的配置
Redis Sentinel（哨兵）
Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis作Master-slave的高可用方案時，
假如master宕機了，Redis自己(包括它的不少客戶端)都沒有實現自動進行主備切換，
而Redis-sentinel自己也是一個獨立運行的進程，它能監控多個master-slave集羣，發現master宕機後能進行自動切換。
Sentinel的構造
Sentinel 是一個監視器，它能夠根據被監視實例的身份和狀態來判斷應該執行何種動做。
Sentinel的功能
監控（Monitoring）：
Sentinel 會不斷地檢查你的主服務器和從服務器是否運做正常。
提醒（Notification）：
當被監控的某個 Redis 服務器出現問題時， Sentinel 能夠經過 API 向管理員或者其餘應用程序發送通知。
自動故障遷移（Automatic failover）：
當一個主服務器不能正常工做時， Sentinel 會開始一次自動故障遷移操做，
它會將失效主服務器的其中一個從服務器升級爲新的主服務器， 並讓失效主服務器的其餘從服務器改成複製新的主服務器；
當客戶端試圖鏈接失效的主服務器時， 集羣也會向客戶端返回新主服務器的地址， 使得集羣能夠使用新主服務器代替失效服務器。
發現並鏈接主服務器
Sentinel 經過用戶給定的配置文件來發現主服務器。
Sentinel 會與被監視的主服務器建立兩個網絡鏈接：
命令鏈接用於向主服務器發送命令。
訂閱鏈接用於訂閱指定的頻道，從而發現監視同一主服務器的其餘 Sentinel （細節立刻會介紹）。
redis-sentinel sentinel.conf
############ master1 configure ##############
sentinel monitor master1 127.0.0.1 6379 2
sentinel down-after-milliseconds master1 30000
sentinel parallel-syncs master1 1
sentinel failover-timeout master1 900000
############ master2 configure ##############
sentinel monitor master2 127.0.0.1 12345 5
sentinel down-after-milliseconds master2 50000
sentinel parallel-syncs master2 5
sentinel failover-timeout master2 450000
發現並鏈接從服務器
Sentinel 經過向主服務器發送 INFO 命令來自動得到全部從服務器的地址。
跟主服務器同樣，Sentinel 會與每一個被發現的從服務器建立命令鏈接和訂閱鏈接。
發現其餘sentinel
多個sentinel保證系統的高可用，防止一個sentinel宕機
sentinel1 經過發送HELLO 信息來讓sentinel2 和 sentinel3發現本身，其餘兩個sentinel 也會進行相似的操做。
Sentinel 會經過命令鏈接向被監視的主從服務器發送 「HELLO」 信息，該消息包含 Sentinel 的 IP、端口號、ID 等內容，
以此來向其餘 Sentinel 宣告本身的存在。與此同時Sentinel 會經過訂閱鏈接接收其餘 Sentinel 的「HELLO」 信息，
以此來發現監視同一個主服務器的其餘 Sentinel 。 一個 Sentinel 能夠與其餘多個 Sentinel 進行鏈接，
各個 Sentinel 之間能夠互相檢查對方的可用性， 並進行信息交換。 你無須爲運行的每一個 Sentinel 分別設置其餘 Sentinel 的地址，
由於 Sentinel 能夠經過發佈與訂閱功能來自動發現正在監視相同主服務器的其餘 Sentinel ，
這一功能是經過向頻道 __sentinel__:hello 發送信息來實現的。 與此相似， 你也沒必要手動列出主服務器屬下的全部從服務器， 由於 Sentinel 能夠經過詢問主服務器來得到全部從服務器的信息。 每一個 Sentinel 會以每兩秒一次的頻率， 經過發佈與訂閱功能，
向被它監視的全部主服務器和從服務器的 __sentinel__:hello 頻道發送一條信息，
信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID （runid）。 每一個 Sentinel 都訂閱了被它監視的全部主服務器和從服務器的 __sentinel__:hello 頻道，
查找以前未出現過的 sentinel （looking for unknown sentinels）。
當一個 Sentinel 發現一個新的 Sentinel 時， 它會將新的 Sentinel 添加到一個列表中，
這個列表保存了 Sentinel 已知的， 監視同一個主服務器的全部其餘 Sentinel 。 Sentinel 發送的信息中還包括完整的主服務器當前配置（configuration）。
若是一個 Sentinel 包含的主服務器配置比另外一個 Sentinel 發送的配置要舊， 那麼這個 Sentinel 會當即升級到新配置上。 在將一個新 Sentinel 添加到監視主服務器的列表上面以前，
Sentinel 會先檢查列表中是否已經包含了和要添加的 Sentinel 擁有相同運行 ID 或者相同地址（包括 IP 地址和端口號）的 Sentinel ，
若是是的話， Sentinel 會先移除列表中已有的那些擁有相同運行 ID 或者相同地址的 Sentinel ， 而後再添加新 Sentinel 。
多個sentinel之間的連接
Sentinel 之間只會互相建立命令鏈接，用於進行通訊。由於已經有主從服務器做爲發送和接收 HELLO 信息的中介，因此 Sentinel之間不會建立訂閱鏈接。
檢測實例狀態
Sentinel 使用 PING 命令來檢測實例的狀態：若是實例在指定的時間內沒有返回回覆，或者返回錯誤的回覆，那麼該實例會被 Sentinel 判斷爲下線。 Redis 的 Sentinel 中關於下線（down）有兩個不一樣的概念： 主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器作出的下線判斷。 客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器作出 SDOWN 判斷，
而且經過 SENTINEL is-master-down-by-addr 命令互相交流以後， 得出的服務器下線判斷。
（一個 Sentinel 能夠經過向另外一個 Sentinel 發送 SENTINEL is-master-down-by-addr 命令來詢問對方是否定爲給定的服務器已下線。） 若是一個服務器沒有在 master-down-after-milliseconds 選項所指定的時間內，
對向它發送 PING 命令的 Sentinel 返回一個有效回覆（valid reply）， 那麼 Sentinel 就會將這個服務器標記爲主觀下線。 服務器對 PING 命令的有效回覆能夠是如下三種回覆的其中一種： 返回 +PONG 。 返回 -LOADING 錯誤。 返回 -MASTERDOWN 錯誤。 若是服務器返回除以上三種回覆以外的其餘回覆， 又或者在指定時間內沒有回覆 Ping命令， 那麼 Sentinel 認爲服務器返回的回覆無效（non-valid）。 注意， 一個服務器必須在 master-down-after-milliseconds 毫秒內， 一直返回無效回覆纔會被 Sentinel 標記爲主觀下線。 舉個例子， 若是 master-down-after-milliseconds 選項的值爲 30000 毫秒（30 秒），
那麼只要服務器能在每 29 秒以內返回至少一次有效回覆， 這個服務器就仍然會被認爲是處於正常狀態的。 從主觀下線狀態切換到客觀下線狀態並無使用嚴格的法定人數算法（strong quorum algorithm），
而是使用了流言協議： 若是 Sentinel 在給定的時間範圍內， 從其餘 Sentinel 那裏接收到了足夠數量的主服務器下線報告，
那麼 Sentinel 就會將主服務器的狀態從主觀下線改變爲客觀下線。 若是以後其餘 Sentinel 再也不報告主服務器已下線， 那麼客觀下線狀態就會被移除。 客觀下線條件只適用於主服務器： 對於任何其餘類型的 Redis 實例， Sentinel 在將它們判斷爲下線前不須要進行協商，
因此從服務器或者其餘 Sentinel 永遠不會達到客觀下線條件。 只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其餘 Sentinel 推選出，
並對失效的主服務器執行自動故障遷移操做。
故障轉移FAILOVER
一次故障轉移操做由如下步驟組成： 一、發現主服務器已經進入客觀下線狀態。 二、基於Raft leader election 協議 ，進行投票選舉 三、若是當選失敗，那麼在設定的故障遷移超時時間的兩倍以後，從新嘗試當選。 若是當選成功， 那麼執行如下步驟。 四、選出一個從服務器，並將它升級爲主服務器。 五、向被選中的從服務器發送 SLAVEOF NO ONE 命令，讓它轉變爲主服務器。 六、經過發佈與訂閱功能， 將更新後的配置傳播給全部其餘 Sentinel ，其餘 Sentinel 對它們本身的配置進行更新。 七、向已下線主服務器的從服務器發送 SLAVEOF 命令，讓它們去複製新的主服務器。 八、當全部從服務器都已經開始複製新的主服務器時， leader Sentinel 終止此次故障遷移操做。 每當一個 Redis 實例被從新配置（reconfigured）
—— 不管是被設置成主服務器、從服務器、又或者被設置成其餘主服務器的從服務器
—— Sentinel 都會向被從新配置的實例發送一個 CONFIG REWRITE 命令， 從而確保這些配置會持久化在硬盤裏。 Sentinel 使用如下規則來選擇新的主服務器： 在失效主服務器屬下的從服務器當中， 那些被標記爲主觀下線、已斷線、或者最後一次回覆 PING 命令的時間大於五秒鐘的從服務器都會被淘汰。 在失效主服務器屬下的從服務器當中， 那些與失效主服務器鏈接斷開的時長超過 down-after 選項指定的時長十倍的從服務器都會被淘汰。 在經歷了以上兩輪淘汰以後剩下來的從服務器中， 咱們選出複製偏移量（replication offset）最大的那個從服務器做爲新的主服務器；
若是複製偏移量不可用， 或者從服務器的複製偏移量相同， 那麼帶有最小運行 ID 的那個從服務器成爲新的主服務器。 Sentinel 自動故障遷移的一致性特質 Sentinel 自動故障遷移使用 Raft 算法來選舉領頭（leader） Sentinel ， 從而確保在一個給定的週期（epoch）裏， 只有一個領頭產生。 這表示在同一個週期中， 不會有兩個 Sentinel 同時被選中爲領頭， 而且各個 Sentinel 在同一個節點中只會對一個領頭進行投票。 更高的配置節點老是優於較低的節點， 所以每一個 Sentinel 都會主動使用更新的節點來代替本身的配置。 簡單來講， 咱們能夠將 Sentinel 配置看做是一個帶有版本號的狀態。
一個狀態會以最後寫入者勝出（last-write-wins）的方式（也便是，最新的配置老是勝出）傳播至全部其餘 Sentinel 。 舉個例子， 當出現網絡分割（network partitions）時，
一個 Sentinel 可能會包含了較舊的配置， 而當這個 Sentinel 接到其餘 Sentinel 發來的版本更新的配置時，
Sentinel 就會對本身的配置進行更新。 若是要在網絡分割出現的狀況下仍然保持一致性， 那麼應該使用 min-slaves-to-write 選項，
讓主服務器在鏈接的從實例少於給定數量時中止執行寫操做， 與此同時， 應該在每一個運行 Redis 主服務器或從服務器的機器上運行 Redis Sentinel 進程。 Sentinel 狀態的持久化 Sentinel 的狀態會被持久化在 Sentinel 配置文件裏面。 每當 Sentinel 接收到一個新的配置， 或者當領頭 Sentinel 爲主服務器建立一個新的配置時， 這個配置會與配置節點一塊兒被保存到磁盤裏面。 這意味着中止和重啓 Sentinel 進程都是安全的。 Sentinel 在非故障遷移的狀況下對實例進行從新配置 即便沒有自動故障遷移操做在進行， Sentinel 總會嘗試將當前的配置設置到被監視的實例上面。 特別是： 根據當前的配置， 若是一個從服務器被宣告爲主服務器， 那麼它會代替原有的主服務器， 成爲新的主服務器，
而且成爲原有主服務器的全部從服務器的複製對象。 那些鏈接了錯誤主服務器的從服務器會被從新配置， 使得這些從服務器會去複製正確的主服務器。 不過， 在以上這些條件知足以後， Sentinel 在對實例進行從新配置以前仍然會等待一段足夠長的時間，
確保能夠接收到其餘 Sentinel 發來的配置更新， 從而避免自身由於保存了過時的配置而對實例進行了沒必要要的從新配置。
santinel配置
mkdir /data/26380 cp /usr/local/redis/src/redis-sentinel /data/26380 cd /data/26380 Vim sentinel.conf port 26380 dir "/data/26380" sentinel monitor mymaster 127.0.0.1 6380 1 sentinel down-after-milliseconds mymaster 60000 sentinel config-epoch mymaster 0 啓動 ./redis-sentinel ./sentinel.conf & 停主庫測試
[root@db01 ~]# redis-cli -p 6380
shutdown
[root@db01 ~]# redis-cli -p 6381
info replication
啓動原主庫（6380），再看狀態。
運行一個 Sentinel 所需的最少配置以下所示： sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1 sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5 第一行配置指示 Sentinel 去監視一個名爲 mymaster 的主服務器，
這個主服務器的 IP 地址爲 127.0.0.1 ， 端口號爲 6379 ，
而將這個主服務器判斷爲失效至少須要 2 個 Sentinel 贊成 （只要贊成 Sentinel 的數量不達標，自動故障遷移就不會執行）。 不過要注意， 不管你設置要多少個 Sentinel 贊成才能判斷一個服務器失效，
一個 Sentinel 都須要得到系統中多數（majority） Sentinel 的支持， 才能發起一次自動故障遷移，
並預留一個給定的配置節點 （configuration Epoch ，一個配置節點就是一個新主服務器配置的版本號）。 換句話說， 在只有少數（minority） Sentinel 進程正常運做的狀況下， Sentinel 是不能執行自動故障遷移的。 其餘選項的基本格式以下： sentinel <選項的名字> <主服務器的名字> <選項的值> 各個選項的功能以下： down-after-milliseconds 選項指定了 Sentinel 認爲服務器已經斷線所需的毫秒數。 若是服務器在給定的毫秒數以內， 沒有返回 Sentinel 發送的 Ping 命令的回覆， 或者返回一個錯誤，
那麼 Sentinel 將這個服務器標記爲主觀下線（subjectively down，簡稱 SDOWN ）。 不過只有一個 Sentinel 將服務器標記爲主觀下線並不必定會引發服務器的自動故障遷移：
只有在足夠數量的 Sentinel 都將一個服務器標記爲主觀下線以後， 服務器纔會被標記爲客觀下線（objectively down， 簡稱 ODOWN ），
這時自動故障遷移纔會執行。將服務器標記爲客觀下線所需的 Sentinel 數量由對主服務器的配置決定。 parallel-syncs 選項指定了在執行故障轉移時， 最多能夠有多少個從服務器同時對新的主服務器進行同步，
這個數字越小， 完成故障轉移所需的時間就越長。 若是從服務器被設置爲容許使用過時數據集（參見對 redis.conf 文件中對 slave-serve-stale-data 選項的說明），
那麼你可能不但願全部從服務器都在同一時間向新的主服務器發送同步請求，
由於儘管複製過程的絕大部分步驟都不會阻塞從服務器， 但從服務器在載入主服務器發來的 RDB 文件時，
仍然會形成從服務器在一段時間內不能處理命令請求： 若是所有從服務器一塊兒對新的主服務器進行同步，
那麼就可能會形成全部從服務器在短期內所有不可用的狀況出現。
你能夠經過將這個值設爲 1 來保證每次只有一個從服務器處於不能處理命令請求的狀態。
配置文件
指定監控master {2表示多少個sentinel贊成} sentinel monitor mymaster 127.0.0.1 6370 2 安全信息 sentinel auth-pass mymaster root 超過15000毫秒後認爲主機宕機 sentinel down-after-milliseconds mymaster 15000 當主從切換多久後認爲主從切換失敗 sentinel failover-timeout mymaster 900000 這兩個配置後面的數量主從機須要同樣，epoch爲master的版本 sentinel leader-epoch mymaster 1 sentinel config-epoch mymaster 1
sentinel命令
PING ：返回 PONG 。 SENTINEL masters ：列出全部被監視的主服務器 SENTINEL slaves <master name> SENTINEL get-master-addr-by-name <master name> ： 返回給定名字的主服務器的 IP 地址和端口號。 SENTINEL reset <pattern> ： 重置全部名字和給定模式 pattern 相匹配的主服務器。 SENTINEL failover <master name> ： 當主服務器失效時， 在不詢問其餘 Sentinel 意見的狀況下， 強制開始一次自動故障遷移。
Redis 集羣分片（cluster）
redis集羣
Redis 集羣是一個能夠在多個 Redis 節點之間進行數據共享的設施（installation）。 Redis 集羣不支持那些須要同時處理多個鍵的 Redis 命令，
由於執行這些命令須要在多個 Redis 節點之間移動數據， 而且在高負載的狀況下，
這些命令將下降 Redis 集羣的性能， 並致使不可預測的行爲。 Redis 集羣經過分區（partition）來提供必定程度的可用性（availability）：
即便集羣中有一部分節點失效或者沒法進行通信， 集羣也能夠繼續處理命令請求。 將數據自動切分（split）到多個節點的能力。 當集羣中的一部分節點失效或者沒法進行通信時， 仍然能夠繼續處理命令請求的能力。
高性能
基於KEY進行數據拆分 1、在多分片節點中，將16384個槽位，均勻分佈到多個分片節點中 2、存數據時，將key作crc16(key),而後和16384進行取模，得出槽位值（0-16383之間） 3、根據計算得出的槽位值，找到相對應的分片節點的主節點，存儲到相應槽位上 4、若是客戶端當時鏈接的節點不是未來要存儲的分片節點，分片集羣會將客戶端鏈接切換至真正存儲節點進行數據存儲
高可用
在搭建集羣時，會爲每個分片的主節點，對應一個從節點，實現slaveof的功能，同時當主節點down，實現相似於sentinel的自動failover的功能。
集羣數據共享
Redis 集羣使用數據分片（sharding）而非一致性哈希（consistency hashing）來實現：
一個 Redis 集羣包含 16384 個哈希槽（hash slot），
數據庫中的每一個鍵都屬於這 16384 個哈希槽的其中一個，
集羣使用公式 CRC16(key) % 16384 來計算鍵 key 屬於哪一個槽，
其中 CRC16(key) 語句用於計算鍵 key 的 CRC16 校驗和 。 節點 A 負責處理 0 號至 5500 號哈希槽。 節點 B 負責處理 5501 號至 11000 號哈希槽。 節點 C 負責處理 11001 號至 16384 號哈希槽。
Redis Cluster
運行機制
全部的redis節點彼此互聯(PING-PONG機制),內部使用二進制協議優化傳輸速度和帶寬. 節點的fail是經過集羣中超過半數的master節點檢測失效時才生效. 客戶端與redis節點直連,不須要中間proxy層.客戶端不須要鏈接集羣全部節點,鏈接集羣中任何一個可用節點便可 把全部的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->key
集羣的複製
爲了使得集羣在一部分節點下線或者沒法與集羣的大多數（majority）節點進行通信的狀況下， 仍然能夠正常運做，
Redis 集羣對節點使用了主從複製功能：
集羣中的每一個節點都有 1 個至 N 個複製品（replica），
其中一個複製品爲主節點（master），
而其他的 N-1 個複製品爲從節點（slave）。 在以前列舉的節點 A 、B 、C 的例子中， 若是節點 B 下線了， 那麼集羣將沒法正常運行，
由於集羣找不到節點來處理 5501 號至 11000 號的哈希槽。 假如在建立集羣的時候（或者至少在節點 B 下線以前）， 咱們爲主節點 B 添加了從節點 B1 ，
那麼當主節點 B 下線的時候， 集羣就會將 B1 設置爲新的主節點， 並讓它代替下線的主節點 B ，
繼續處理 5501 號至 11000 號的哈希槽， 這樣集羣就不會由於主節點 B 的下線而沒法正常運做了。 不過若是節點 B 和 B1 都下線的話， Redis 集羣仍是會中止運做。 集羣的複製特性重用了 SLAVEOF 命令的代碼，因此集羣節點的複製行爲和 SLAVEOF 命令的複製行爲徹底相同。
集羣的故障轉移
在集羣裏面，節點會對其餘節點進行下線檢測。
當一個主節點下線時，集羣裏面的其餘主節點負責對下線主節點進行故障移。
換句話說，集羣的節點集成了下線檢測和故障轉移等相似 Sentinel 的功能。
由於 Sentinel 是一個獨立運行的監控程序，而集羣的下線檢測和故障轉移等功能是集成在節點裏面的，
它們的運行模式很是地不一樣，因此儘管這二者的功能很類似，但集羣的實現沒有重用 Sentinel 的代碼。
在集羣裏面執行命令的另種狀況
命令發送到了正確的節點：命令要處理的鍵所在的槽正好是由接收命令的節點負責，那麼該節點執行命令，
就像單機 Redis 服務器同樣。
命令發送到了錯誤的節點：接收到命令的節點並不是處理鍵所在槽的節點，那麼節點將向客戶端返回一個轉向（redirection）錯誤，
告知客戶端應該到哪一個節點去執行這個命令，客戶端會根據錯誤提示的信息，從新向正確的節點發送命令。
轉向錯誤的實現
一、集羣中的節點會互相告知對方，本身負責處理哪些槽。
二、集羣中的每一個節點都會記錄 16384 個槽分別由哪一個節點負責，從而造成一個「槽表」（slot table）。
節點在接收到命令請求時，會經過槽表檢查鍵所在的槽是否由本節點處理：
- 若是是的話，那麼節點直接執行命令；
- 若是不是的話，那麼節點就從槽表裏面提取出正確節點的地址信息，而後返回轉向錯誤
Redis Cluter配置插件安裝
EPEL源安裝ruby支持 yum install ruby rubygems -y 使用國內源 gem sources --add https://gems.ruby-china.org/ --remove https://rubygems.org/ gem install redis -v 3.3.3 gem sources -l 若是沒法使用，能夠使用aliyun gem sources -a http://mirrors.aliyun.com/rubygems/ gem sources --remove http://rubygems.org/
配置文件
Redis 集羣由多個運行在集羣模式（cluster mode）下的 Redis 實例組成， 實例的集羣模式須要經過配置來開啓， 開啓集羣模式的實例將能夠使用集羣特有的功能和命令。 如下是一個包含了最少選項的集羣配置文件示例： port 7000 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes 文件中的 cluster-enabled 選項用於開實例的集羣模式，
而 cluster-conf-file 選項則設定了保存節點配置文件的路徑， 默認值爲 nodes.conf 。 節點配置文件無須人爲修改， 它由 Redis 集羣在啓動時建立， 並在有須要時自動進行更新。 要讓集羣正常運做至少須要三個主節點， 不過在剛開始試用集羣功能時，
強烈建議使用六個節點： 其中三個爲主節點， 而其他三個則是各個主節點的從節點。 cd /data mkdir cluster-test cd cluster-test mkdir 7000 7001 7002 7003 7004 7005
建立應用
mkdir cluster-test cd cluster-test mkdir 7000 7001 7002 7003 7004 7005 拷貝應用 cp redis.conf redis-server ./7000 啓動應用 cd 7000 ./redis-server ./redis.conf
建立集羣
{redis_src_home}/src/redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
給定 redis-trib.rb 程序的命令是 create ， 這表示咱們但願建立一個新的集羣。
選項 --replicas 1
表示咱們但願爲集羣中的每一個主節點建立一個從節點。
集羣客戶端
redis-cli -c -p 7000 set foo bar get foo 從新分片 ./redis-trib.rb reshard 127.0.0.1:7000
集羣管理
集羣主節點狀態 redis-cli -p 7000 cluster nodes | grep master 集羣從節點狀態 redis-cli -p 7000 cluster nodes | grep slave 增長新的節點 ./redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000 刪除一個節點 redis-trib del-node ip:port '<node-id>' 刪除master節點以前首先要使用reshard移除master的所有slot,而後再刪除當前節點 添加一個從節點 ./redis-trib.rb add-node --slave --master-id $[nodeid] 127.0.0.1:7008 127.0.0.1:7000
規劃和搭建的實踐過程
6個redis實例，通常會放到3臺硬件服務器 注：在企業規劃中，一個分片的兩個節點，分到不一樣的物理機，防止硬件主機宕機形成的整個分片數據丟失。 端口號：7000-7005 1、安裝集羣插件 EPEL源安裝ruby支持 yum install ruby rubygems -y 使用國內源 gem sources -l gem sources -a http://mirrors.aliyun.com/rubygems/ gem sources --remove http://rubygems.org/ gem install redis -v 3.3.3 gem sources -l 或者： gem sources -a http://mirrors.aliyun.com/rubygems/ --remove http://rubygems.org/ --- 2、集羣節點準備 mkdir /data/700{0..5} vim /data/7000/redis.conf port 7000 daemonize yes pidfile /data/7000/redis.pid loglevel notice logfile "/data/7000/redis.log" dbfilename dump.rdb dir /data/7000 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes vim /data/7001/redis.conf port 7001 daemonize yes pidfile /data/7001/redis.pid loglevel notice logfile "/data/7001/redis.log" dbfilename dump.rdb dir /data/7001 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes vim /data/7002/redis.conf port 7002 daemonize yes pidfile /data/7002/redis.pid loglevel notice logfile "/data/7002/redis.log" dbfilename dump.rdb dir /data/7002 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes vim /data/7003/redis.conf port 7003 daemonize yes pidfile /data/7003/redis.pid loglevel notice logfile "/data/7003/redis.log" dbfilename dump.rdb dir /data/7003 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes vim /data/7004/redis.conf port 7004 daemonize yes pidfile /data/7004/redis.pid loglevel notice logfile "/data/7004/redis.log" dbfilename dump.rdb dir /data/7004 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes vim /data/7005/redis.conf port 7005 daemonize yes pidfile /data/7005/redis.pid loglevel notice logfile "/data/7005/redis.log" dbfilename dump.rdb dir /data/7005 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes 啓動節點： redis-server /data/7000/redis.conf redis-server /data/7001/redis.conf redis-server /data/7002/redis.conf redis-server /data/7003/redis.conf redis-server /data/7004/redis.conf redis-server /data/7005/redis.conf [root@db01 ~]# ps -ef |grep redis root 8854 1 0 03:56 ? 00:00:00 redis-server *:7000 [cluster] root 8858 1 0 03:56 ? 00:00:00 redis-server *:7001 [cluster] root 8860 1 0 03:56 ? 00:00:00 redis-server *:7002 [cluster] root 8864 1 0 03:56 ? 00:00:00 redis-server *:7003 [cluster] root 8866 1 0 03:56 ? 00:00:00 redis-server *:7004 [cluster] root 8874 1 0 03:56 ? 00:00:00 redis-server *:7005 [cluster] 3、將節點加入集羣管理 redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \ 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 4、集羣狀態查看 集羣主節點狀態 redis-cli -p 7000 cluster nodes | grep master 集羣從節點狀態 redis-cli -p 7000 cluster nodes | grep slave 5、集羣節點管理 5.1 增長新的節點 mkdir /data/7006 mkdir /data/7007 vim /data/7006/redis.conf port 7006 daemonize yes pidfile /data/7006/redis.pid loglevel notice logfile "/data/7006/redis.log" dbfilename dump.rdb dir /data/7006 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes vim /data/7007/redis.conf port 7007 daemonize yes pidfile /data/7007/redis.pid loglevel notice logfile "/data/7007/redis.log" dbfilename dump.rdb dir /data/7007 protected-mode no cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes redis-server /data/7006/redis.conf redis-server /data/7007/redis.conf 5.2 添加主節點： redis-trib.rb add-node 127.0.0.1:7006 127.0.0.1:7000 5.3 轉移slot（從新分片） redis-trib.rb reshard 127.0.0.1:7000
執行以後，會交互提示，輸入想移動的槽位：經過本身從新計算得到數值，而後輸入
提示輸入nodeID （惟一的）：
輸入從哪些節點上分配：輸入all 5.4 添加從節點 redis-trib.rb add-node --slave --master-id bff7d6e603578033f53865de3e55fb2b8c526b60 127.0.0.1:7007 127.0.0.1:7000 6.刪除節點 6.1 將須要刪除節點slot移動走 redis-trib.rb reshard 127.0.0.1:7000 交互提示輸入
一、數量
二、接收者node
三、源節點node
四、輸入done，結束 刪除一個節點 刪除master節點以前首先要使用reshard移除master的所有slot,而後再刪除當前節點 主節點刪除： redis-trib.rb del-node 127.0.0.1:7006 bff7d6e603578033f53865de3e55fb2b8c526b60 從節點刪除： redis-trib.rb del-node 127.0.0.1:7007 2af3da4252ad1a7334d476e1b56498b85a1b488c
Redis API支持（Python篇）
注：不一樣的架構須要不一樣的API支持，因此要先了解使用的是哪一種架構
Redis提供了各種開發語言的API，方便開發語言鏈接使用Redis。 https://redis.io/clients 官方網站提供了不一樣開發語言的API程序。
python連接redis
https://redis.io/clients#python 官網中，給咱們提供了不少種Python鏈接redis的API，咱們一般選擇有「笑臉」而且帶有「星號」的使用 這裏咱們推薦使用redis-py.
redis-py提供的，python 鏈接及操做redis方式：
redis-py提供兩個類Redis和StrictRedis用於實現Redis的命令。
StrictRedis用於實現大部分官方的命令，並使用官方的語法和命令（好比，SET命令對應與StrictRedis.set方法）。
Redis是StrictRedis的子類，用於向後兼容舊版本的redis-py。
簡單說，官方推薦使用StrictRedis方法。不推薦Redis類，緣由是他和我們在redis-cli操做有些不同，主要不同是下面這三個方面。
redis-py單機驅動安裝
安裝python3
tar xf Python-3.5.2.tar.xz cd Python-3.5.2 ./configure make && make install https://redis.io/clients 下載redis-py-master.zip unzip redis-py-master.zip cd redis-py-master python3 setup.py install 安裝redis-cluser的客戶端程序 cd redis-py-cluster-unstable python3 setup.py install
單實例連接操做
python3 >>>import redis >>>r = redis.StrictRedis(host='localhost', port=6379, db=0,password='root') >>>r.set('lufei', 'guojialei') True >>>r.get('lufei') 'bar'
sentinel集羣連接並操做
[root@db01 ~]# redis-server /data/6380/redis.conf [root@db01 ~]# redis-server /data/6381/redis.conf [root@db01 ~]# redis-server /data/6382/redis.conf [root@db01 ~]# redis-sentinel /data/26380/sentinel.conf & -------------------------------- ## 導入redis sentinel包 >>> from redis.sentinel import Sentinel ##指定sentinel的地址和端口號 >>> sentinel = Sentinel([('localhost', 26380)], socket_timeout=0.1) ##測試，獲取如下主庫和從庫的信息
## mymaster 是咱們在配置文件中指定的名字
>>> sentinel.discover_master('mymaster')
>>> sentinel.discover_slaves('mymaster')
##配置讀寫分離
#寫節點
>>> master = sentinel.master_for('mymaster', socket_timeout=0.1)
#讀節點
>>> slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
###讀寫分離測試 key
>>> master.set('oldboy', '123')
>>> slave.get('oldboy')
'123'
cluster分片集羣連接測試
(1) redis-py並無提供redis-cluster的支持，去github找了一下，有個叫redis-py-cluster的源碼， 可是和redis-py不是一個做者，地址爲:https://github.com/Grokzen/redis-py-cluster watch,star,fork還算能夠。 (2) 安裝 Latest stable release from pypi $ pip install redis-py-cluster or from source $ python setup.py install (3) 使用 >>> from rediscluster import StrictRedisCluster >>> startup_nodes = [{"host": "127.0.0.1", "port": "7000"}] >>> # Note: decode_responses must be set to True when used with python3 >>> rc = StrictRedisCluster(startup_nodes=startup_nodes, decode_responses=True) >>> rc.set("foo", "bar") True >>> print(rc.get("foo")) 'bar' 官方的建立redis的時候，均可以添加什麼參數。 class redis.StrictRedis(host=‘localhost‘, port=6379, db=0, password=None, socket_timeout=None, connection_pool=None, charset=‘utf-8‘, errors=‘strict‘, decode_responses=False, unix_socket_path=None) connection pool方式 使用connection pool來管理對一個redis server的全部鏈接，避免每次創建、釋放鏈接的開銷。 默認，每一個Redis實例都會維護一個本身的鏈接池。 能夠直接創建一個鏈接池，而後做爲參數 Redis，這樣就能夠實現多個Redis實例共享一個鏈接池 StrictRedis Pipeline 是 StrictRedis 類的子類，支持在一個請求裏發送緩衝的多個命令。 經過減小客戶端和服務器之間往來的數據包，能夠大大提升命令組的性能
做業
一、實現Redis Cluseter並實現Python連接集羣
實現Redis Cluseter並實現Python連接集羣 要求：畫出實驗拓撲圖，標準清楚IP/hostname/做用 （1）實現redis Cluseter高可用分片集羣 （2）實現python連接redis Cluster
相關文章
- 1. Linux雲計算運維-MySQL
- 2. Linux雲計算運維工程師day02
- 3. Linux 雲計算運維之路
- 4. 雲計算學習基礎，Linux雲計算運維及開發
- 5. 雲計算linux運維課程學習，雲計算面試題庫
- 6. 雲計算課程大綱，Linux雲計算運維課程視頻
- 7. 雲計算運維學習---sudo提權
- 8. 雲計算運維需給技能
- 9. 雲計算運維學習---ansible劇本
- 10. 雲計算運維課程大綱
- 更多相關文章...
- • PHP 運算符 - PHP教程
- • Scala 運算符 - Scala教程
- • 使用Rxjava計算圓周率
- • 三篇文章瞭解 TiDB 技術內幕 —— 說計算
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章