Redis系列(十五)、Redis6新特性之集羣代理(Cluster Proxy)

在之前的文章中介紹了Redis6的集羣搭建和原理,我們可以使用dummy和smart客戶端連接集羣,本篇介紹Redis6新增的一個功能:集羣代理。客戶端不需要知道集羣中的具體節點個數和主從身份,可以直接通過代理訪問集羣,對於客戶端來說通過集羣代理訪問的集羣就和單機的Redis一樣,因此也能解決很多集羣的使用限制。


目錄

介紹

安裝

下載解壓

安裝gcc4.9+版本

編譯

安裝

使用

配置啓動

跨節點slot操作

故障轉移

尾巴


Redis6系列文章

Redis系列(一)、CentOS7下安裝Redis6.0.3穩定版

Redis系列(二)、數據類型之字符串String 

Redis系列(三)、數據類型之哈希Hash

Redis系列(四)、數據類型之列表List

Redis系列(五)、數據類型之無序集合Set

Redis系列(六)、數據類型之有序集合ZSet(sorted_set)

Redis系列(七)、常用key命令

Redis系列(八)、常用服務器命令 

Redis系列(九)、Redis的“事務”及Lua腳本操作

Redis系列(十)、詳解Redis持久化方式AOF、RDB以及混合持久化

Redis系列(十一)、Redis6新特性之ACL安全策略(用戶權限管理)

Redis系列(十二)、Redis6集羣搭建及原理(主從、哨兵、集羣)

Redis系列(十三)、pub/sub發佈與訂閱(對比List和Kafka)

Redis系列(十四)、Redis6新特性之RESP3與客戶端緩存(Client side caching)

 

介紹

在Redis6的release note中可以看到新功能中的ACL,RESP3,客戶端緩存我們在前面的文章中已經介紹過,本篇就看一下集羣代理。集羣代理與Redis在Github上是不同的項目,地址如下:

Github:https://github.com/RedisLabs/redis-cluster-proxy

集羣代理(Redis Cluster Proxy) 將集羣抽象爲單實例,客戶端不需要知道集羣中的具體節點個數和主從身份,通過代理訪問集羣,就像訪問單機Redis一樣。同時集羣代理也能解決在集羣模式下multiple操作的限制及跨slot操作限制(如mget,mset...)。

Redis集羣代理的特點

  • 自動化路由:每個查詢被自動路由到集羣的正確節點;
  • 多線程:多路複用通信模型,每個線程都有自己的集羣連接;
  • 順序性:多路複用上下文中,保證查詢的執行和應答順序;
  • 無感知更新集羣信息:當請求/重定向錯誤時會自動更新集羣信息,客戶端提交的查詢會在集羣信息更新完成後重新執行,對於客戶端來說這一切是無感的,客戶端不會收到請求/重定向的錯誤信息,而是直接收到查詢的結果;
  • 跨槽/節點查詢:支持跨slot或node的mutiple操作key,如mget,mset,del等。但由於mset,del會破壞原子性,因此該配置默認關閉;
  • ACL:支持連接開啓了ACL的Redis集羣;
  • DBSIZE:對於沒有指定節點的命令,將會合併所有的信息的總和並返回;

 

安裝

下載解壓

從github上下載解壓源碼(2020-06-30:目前最新版是unstable版本)

#git命令
git clone https://github.com/artix75/redis-cluster-proxy

#手動下載zip解壓
unzip redis-cluster-proxy-unstable.zip 

安裝gcc4.9+版本

在之前安裝Redis6的文章中有介紹,此處略過安裝gcc9.1:

#開啓gcc9.1
scl enable devtoolset-9 bash

#查看gcc版本
gcc -v

 

編譯

執行下面的命令編譯源碼,出現下圖表示安裝成功:

#進入目錄並編譯
cd redis-cluster-proxy-unstable
make

#如果編譯出錯之後再編譯可以先執行命令刪除之前的編譯文件
make distclean

如果遇到錯誤unknown type name ‘_Atomic’ ,請檢查gcc版本重新安裝;

安裝

編譯成功後使用下面的命令安裝Redis集羣代理服務,出現下圖表示安裝成功:

#安裝Redis集羣代理,可指定安裝目錄
make install PREFIX=/opt/app/redis-cluster-proxy

使用

配置啓動

從源碼中將配置文件copy到安裝目錄:

cp /home/wyk/redis-cluster-proxy-unstable/proxy.conf /opt/app/redis-cluster-proxy/

修改配置文件:

vim /opt/app/redis-cluster-proxy/proxy.conf

#配置Redis集羣,這裏我使用前幾篇文章中配置的Redis6集羣,三主三從
cluster 127.0.0.1:6381  #主1
cluster 127.0.0.1:6382  #主2
cluster 127.0.0.1:6383  #主3
cluster 127.0.0.1:6391  #從1
cluster 127.0.0.1:6392  #從2
cluster 127.0.0.1:6393  #從3

#默認端口
port 7777

#線程數
threads 8

#後臺運行
daemonize yes

#日誌文件
logfile "/opt/app/redis-cluster-proxy/redis-cluster-proxy.log"

#允許跨slot查詢
enable-cross-slot yes

#最大客戶端連接數
max-clients 10000

#ACL用戶密碼(也可以在啓動服務時指定)
auth-user myuser #ACL用戶
auth mypassw    #ACL密碼

#連接池
connections-pool-size 10
connections-pool-min-size 10
connections-pool-spawn-every 50
connections-pool-spawn-rate 50

創建日誌文件並使用下面的命令指定配置文件啓動集羣代理:

#創建日誌文件
touch /opt/app/redis-cluster-proxy/redis-cluster-proxy.log
#啓動Redis集羣代理服務
/opt/app/redis-cluster-proxy/bin/redis-cluster-proxy -c /opt/app/redis-cluster-proxy/proxy.conf

連接集羣代理客戶端

Redis集羣代理服務監聽7777端口,我們可以使用Redis命令行指定7777端口啓動集羣代理客戶端:

#連接Redis集羣代理客戶端
/opt/app/redis6/bin/redis-cli -p 7777

跨節點slot操作

上面提到在集羣代理中,會將集羣抽象成一個Redis實例,對用戶來說跨slot/node操作是無感的,而在默認集羣中會重定向到對應slot所在的節點進行操作。

默認集羣模式: 

在之前的Redis集羣文章中演示了在dummy客戶端中操作集羣內的key時會重定向到該key存儲的slot所在的節點:

#使用-c進入集羣命令行模式
redis-cli -c -p 6381
 
#使用命令查看key所在的槽
cluster keyslot key1

 

集羣代理模式:

在集羣代理模式下,可以跨slot甚至跨節點操作key,而在集羣模式下鏈接客戶端是做不到的。下圖演示瞭如果在集羣代理中使用mset和mget跨slot跨node設置或查詢key,對於用戶來說彷彿是在使用一個單實例的Redis: 

故障轉移

手動的使集羣中一個主節點宕機,測試集羣代理能否感知到集羣的故障轉移:

#在6381主節點執行命令,手動的讓其宕機
#命令執行一個非法的內存訪問從而讓 Redis 崩潰,僅在開發時用於 BUG 調試,執行後需要重啓服務
debug segfault

情況一、主節點6381宕機,6391節點升級爲主節點,集羣恢復正常,但6381節點還沒啓動,此時集羣代理無法使用,需要啓動6381節點之後集羣代理才能恢復使用:

情況二、手動將6381主節點宕機,當從節點6391升級爲主節點後,重啓6381節點作爲6391的從節點,此時集羣的主從機器全部正常啓動,查詢集羣代理,不會收到影響:

尾巴

目前在Github上最新的版本仍是unstable版,畢竟是新功能,還是有很多BUG的,像集羣的故障轉移在集羣代理中就沒有做的很好,其次就是如果集羣代理服務本身沒有解決單點故障(可以嘗試配合HAProxy等代理服務做負載均衡)。

官方最後聲明中也提到【當前處於α版本,不推薦在生產環境使用]】:

This project is currently alpha code that is indented to be evaluated by the community in order to get suggestions and contributions. We discourage its usage in any production environment.

但不可否認的是集羣代理給redis集羣提供了輕量的代理層,也解決了很多在集羣模式中的使用限制,未來的潛力還很大,讓我們拭目以待吧!

 

希望本文對你有幫助,請點個贊鼓勵一下作者吧~ 謝謝!

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