Redis功能的實現(主從複製、高可用、集羣)

1.Redis的介紹與安裝

1.1 Redis的介紹

Redis(Remote Dictionary Server ),即遠程字典服務。Redis是一個開放源代碼(BSD許可)的內存中數據結構存儲,用作數據庫,緩存和消息代理。 它支持數據結構,例如字符串,哈希,列表,集合,帶範圍查詢的排序集合,位圖,超日誌,帶有半徑查詢和流的地理空間索引。 Redis具有內置的複製,Lua腳本,LRU淘汰,事務和不同級別的磁盤持久性,並通過Redis Sentinel哨兵和Redis Cluster自動分區提供了高可用性。單線程,操作簡單。適用於將熱點數據和不長更新的數據放入緩存。

1.2 Redis的安裝

yum install -y gcc 安裝工具
tar zxf redis-5.0.3.tar.gz解壓
cd redis-5.0.3/
make && make install安裝
cd redis-5.0.3/utils/
./install_server.sh安裝配置
vim /etc/redis/6379.conf設置打開所有接口的6379端口

bind 0.0.0.0

/etc/init.d/redis_6379 restart重啓redis


在這裏插入圖片描述在這裏插入圖片描述
在這裏插入圖片描述在這裏插入圖片描述
在這裏插入圖片描述


2.Redis的主從複製

實驗環境:
server1:192.168.43.10,安裝有redis
server2:192.168.43.20,安裝有redis
實驗步驟:
1.server1與server2的Redis已打開
在這裏插入圖片描述
在這裏插入圖片描述


2.在server2中配置主從複製
vim /etc/redis/6379.conf

slaveof 192.168.43.10 6379

/etc/init.d/redis_6379 restart
在這裏插入圖片描述
在這裏插入圖片描述


3.測試
redis-cli

127.0.0.1:6379> set name redhat
OK
127.0.0.1:6379> get name
"redhat"

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述


3.Redis的高可用

Redis Sentinel是Redis官方的高可用性解決方案。

Redis 的 Sentinel 系統用於管理多個 Redis 服務器(instance), 該系統執行以下三個任務:
監控(Monitoring): Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
提醒(Notification): 當被監控的某個 Redis 服務器出現問題時, Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移(Automatic failover): 當一個主服務器不能正常工作時, Sentinel 會開始一次自動故障遷移操作, 它會將失效主服務器的其中一個從服務器升級爲新的主服務器, 並讓失效主服務器的其他從服務器改爲複製新的主服務器; 當客戶端試圖連接失效的主服務器時, 集羣也會向客戶端返回新主服務器的地址, 使得集羣可以使用新主服務器代替失效服務器。

Redis Sentinel 是一個分佈式系統, 你可以在一個架構中運行多個 Sentinel 進程(progress), 這些進程使用流言協議(gossip protocols)來接收關於主服務器是否下線的信息, 並使用投票協議(agreement protocols)來決定是否執行自動故障遷移, 以及選擇哪個從服務器作爲新的主服務器。

雖然 Redis Sentinel 釋出爲一個單獨的可執行文件 redis-sentinel , 但實際上它只是一個運行在特殊模式下的 Redis 服務器, 可以在啓動一個普通 Redis 服務器時通過給定 - -sentinel 選項來啓動 Redis Sentinel


Redis 的 Sentinel 中關於下線(down)有兩個不同的概念:
主觀下線(Subjectively Down, 簡稱 SDOWN) 指的是單個 Sentinel 實例對服務器做出的下線判斷。
如果一個服務器沒有在 master-down-after-milliseconds 選項所指定的時間內, 對向它發送 PING 命令的 Sentinel 在 master-down-after-milliseconds 毫秒內一直返回無效回覆, 那麼 Sentinel 就會將這個服務器標記爲主觀下線。

客觀下線(Objectively Down, 簡稱 ODOWN) 指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷, 並且通過 SENTINEL is-master-down-by-addr 命令互相交流之後, 得出的服務器下線判斷。 (一個 Sentinel 可以通過向另一個 Sentinel 發送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認爲給定的服務器已下線。)
如果 Sentinel 在給定的時間範圍內, 從其他 Sentinel 那裏接收到了足夠數量的主服務器下線報告, 那麼 Sentinel 就會將主服務器的狀態從主觀下線改變爲客觀下線。 如果之後其他 Sentinel 不再報告主服務器已下線, 那麼客觀下線狀態就會被移除。客觀下線條件只適用於主服務器。

只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態, 這個 Sentinel 就可能會被其他 Sentinel 推選出, 並對失效的主服務器執行自動故障遷移操作。


實驗環境:
server1(主服務器):192.168.43.10,安裝有redis
server2(從服務器):192.168.43.20,安裝有redis
server3(從服務器):192.168.43.30,安裝有redis

實驗步驟:
1.server1與server2、server3的Redis已打開,並在server2/3中配置主從複製

vim /etc/redis/6379.conf
/etc/init.d/redis_6379 restart

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述


2.在server1/2/3中編輯sentinel配置文件開啓哨兵
cp /soft/redis-5.0.3/sentinel.conf /etc/redis/
vim /etc/redis/sentinel.conf

protected-mode no

sentinel monitor mymaster 192.168.43.10 6379 2

sentinel down-after-milliseconds mymaster 10000

redis-server /etc/redis/sentinel.conf --sentinel啓動一個運行在 Sentinel 模式下的 Redis 服務器
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述


redis-cli在server1中查看哨兵的狀態

127.0.0.1:6379> info ##注意:默認連接6379
127.0.0.1:26379> info

在這裏插入圖片描述
redis-cli -p 26379在server1中查看哨兵的狀態
在這裏插入圖片描述


3.測試
在server1中
在這裏插入圖片描述
在server2中
在這裏插入圖片描述
redis-cli

127.0.0.1:6379> info

在這裏插入圖片描述
在這裏插入圖片描述


再次啓動server1
/etc/init.d/redis_6379 start

在這裏插入圖片描述
在這裏插入圖片描述


4 Redis的集羣

4.1 Redis集羣的介紹

Redis 集羣是一個提供在多個Redis間節點間共享數據的程序集。Redis 集羣通過分區來提供一定程度的可用性,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令.

Redis 集羣的優勢:
自動分割數據到不同的節點上。
整個集羣的部分節點失敗或者不可達的情況下能夠繼續處理命令。


4.2 Redis集羣的搭建及主從複製

Redis 集羣的主從複製
假設具有A,B,C三個節點的集羣,在集羣創建的時候爲每個節點添加一個從節點A1,B1,C1,那麼整個集羣便有三個master節點和三個slave節點組成,這樣在節點B失敗後,集羣便會選舉B1爲新的主節點繼續服務,整個集羣便不會因爲槽找不到而不可用了。不過當B和B1 都失敗後,集羣是不可用的。

實驗環境: server1有redis,實現一臺主機多個實例

實驗步驟:
1.建立新目錄, 並創建六個以端口號爲名字的子目錄,在將每個目錄中運行一個 Redis 實例
mkdir /usr/local/rediscluster/建立新目錄
mkdir /usr/local/rediscluster/700{1..6}創建以端口號爲名字的子目錄

在這裏插入圖片描述
vim /usr/local/rediscluster/7001對每個目錄中運行一個 Redis 實例

port                     7001
cluster-enabled          yes
cluster-config-file      nodes.conf
cluster-node-timeout     5000
appendonly               yes
pidfile                  "/usr/local/rediscluster/7001/redis.pid"
logfile                  "/usr/local/rediscluster/7001/redis.log"
daemonize                yes
dir                      "/usr/local/rediscluster/7001"

redis-server /usr/local/rediscluster/7006/redis.conf運行實例


在這裏插入圖片描述
在這裏插入圖片描述在這裏插入圖片描述

[root@server1 rediscluster]# redis-cli -p 7001
127.0.0.1:7001> info

在這裏插入圖片描述


2.搭建集羣
redis-cli --cluster create --cluster-replicas 1 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 127.0.0.1:7006 爲集羣中的每個主節點創建一個從節點
在這裏插入圖片描述
在這裏插入圖片描述


3.測試:
redis-cli -c -p 7001
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述


掛掉主服務器7002
在這裏插入圖片描述
在這裏插入圖片描述


掛掉從服務器7004(已升級爲主服務器)
在這裏插入圖片描述


在這裏插入圖片描述


4.3 集羣重新分片

實驗環境:在上一個實驗的基礎上
Redis 集羣的數據分片
Redis 集羣引入了 哈希槽的概念.
Redis 集羣有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽.集羣的每個節點負責一部分hash槽,如當前集羣有3個節點,那麼:
節點 A 包含 0 到 5500號哈希槽.
節點 B 包含5501 到 11000 號哈希槽.
節點 C 包含11001 到 16384號哈希槽.
這種結構很容易添加或者刪除節點. 比如如果我想新添加個節點D, 我需要從節點 A, B, C中得部分槽到D上. 如果我想移除節點A,需要將A中的槽移到B和C節點上,然後將沒有任何槽的A節點從集羣中移除即可.由於從一個節點將哈希槽移動到另一個節點並不會停止服務,所以無論添加刪除或者改變某個節點的哈希槽的數量都不會造成集羣不可用的狀態.

實驗步驟:
1.建立新的節點
在這裏插入圖片描述
在這裏插入圖片描述


2. 添加節點到集羣中
redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7001將7007加入集羣
redis-cli --cluster add-node 127.0.0.1:7008 127.0.0.1:7007 --cluster-slave --cluster-master-id 0e011691bd77276feadd91c6316eb79717bb7043將7008加入集羣,並作爲7007的slave

在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述


3.分配hash槽

在這裏插入圖片描述
3.1 分配指定數量hash槽
redis-cli --cluster reshard 127.0.0.1:7001
在這裏插入圖片描述
redis-cli --cluster check 127.0.0.1:7001
在這裏插入圖片描述

3.2 平均分配hash槽
redis-cli --cluster rebalance --cluster-threshold 1 --cluster-use-empty-masters 127.0.0.1:7001
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述
在這裏插入圖片描述


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章