您好,登錄后才能下訂單哦!
這篇文章將為大家詳細講解有關Redis哨兵模式高可用的示例分析,小編覺得挺實用的,因此分享給大家做個參考,希望大家閱讀完這篇文章后可以有所收獲。
Redis高可用有兩種模式:哨兵模式
和集群模式
,本文基于哨兵模式搭建一主兩從三哨兵
Redis高可用服務。
一主兩從三哨兵
Redis服務,基本能夠滿足中小型項目的高可用要求,使用Supervisor監控并管理Redis實例。通過本文將完成如下目標:
哨兵模式服務規劃與搭建
哨兵模式服務相比于單機版服務更加可靠,適合讀寫分離、數據量不是很大、要求可靠穩定性的場景。
客戶端整合與讀寫分離
通過Spring框架對哨兵模式進行連接,完成生產環境的常見操作。
端口規劃是完成本方案的第一步。
單機模擬是指在單臺物理機或者虛擬機上模擬操作,最大化還原本方案中間過程,適用于學習或者開發階段使用。
為了簡化操作,Redis服務做如下約定:數據不持久化到磁盤;服務實例以前臺進程方式運行;節點的配置文件以默認配置文件為模版;無密碼驗證。
服務在第一次啟動時明確知道第幾個節點是master節點,當服務在長期運行并發生主從切換時,無法顯示知道第幾個節點是master節點,需要通過命令行間接查詢。
節點 | 主機 | 端口 | 角色 | 額外配置 |
---|---|---|---|---|
node01 | 127.0.0.1 | 6380 | 第一次啟動時作為master服務 | |
node02 | 127.0.0.1 | 6381 | 第一次啟動時作為slave服務 | replicaof 127.0.0.1 6380 |
node03 | 127.0.0.1 | 6382 | 第一次啟動時作為slave服務 | replicaof 127.0.0.1 6380 |
額外配置指第一次啟動Redis服務實例時,節點配置文件中新增配置。
哨兵服務節點之間沒有主從的區別,所有節點處于平等地位。當主服務異常時,哨兵服務之間會喚醒投票策略,從Redis實例從節點選擇主服務的候選人。
節點 | 主機 | 端口 | 額外配置 |
---|---|---|---|
node01 | 127.0.0.1 | 26380 | sentinel monitor mymaster 127.0.0.1 6380 2 |
node02 | 127.0.0.1 | 26381 | sentinel monitor mymaster 127.0.0.1 6380 2 |
node03 | 127.0.0.1 | 26382 | sentinel monitor mymaster 127.0.0.1 6380 2 |
節點的初始配置文件以默認配置文件為模版。
node01、node02初始化配置文件之后,顯示指明節點間的主從關系,增加如下配置:
replicaof 127.0.0.1 6380
節點的初始配置文件以默認配置文件為模版。
node01、node02、node03初始化配置文件后,增加如下配置:
sentinel monitor mymaster 127.0.0.1 6381 2
測試或者學習時,建議采用前臺進程管理服務,便于模擬單點故障、查看日志觀察主從切換。
生產條件下建議使用Supervisor管理服務,不僅易于管理而且能夠實現服務異常終止后自動重啟。高可用場景下使用的是三臺物理機。
/usr/local/redis/bin/redis-server /usr/local/redis/conf/ms/redis80.conf --port 6380 --save '' --daemonize no /usr/local/redis/bin/redis-server /usr/local/redis/conf/ms/redis81.conf --port 6381 --save '' --daemonize no /usr/local/redis/bin/redis-server /usr/local/redis/conf/ms/redis82.conf --port 6382 --save '' --daemonize no
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/ms/sentinel280.conf --port 26380 --daemonize no /usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/ms/sentinel281.conf --port 26381 --daemonize no /usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/ms/sentinel282.conf --port 26382 --daemonize no
客戶端實現是指基于SpringBoot的整合分為兩步實現:一是完成作為基礎的整合;二是結合生產需要補充新特性。
基礎整合的內容是以Java客戶端連接高可用哨兵模式Redis服務,實現單節點故障服務正常運行的要求。
全局配置文件添加的配置信息有:master
參數為哨兵服務名,此處為默認值;nodes
參數為哨兵服務列表(不是Redis實例服務列表);database
參數為數據庫。
spring: redis: database: 0 sentinel: nodes: 192.168.181.171:26380,192.168.181.171:26381,192.168.181.171:26382 master: mymaster
集成進SpringBoot體系,最核心的是創建LettuceConnectionFactory
連接工廠,通過Redis連接工廠,能夠順利繼承進Spring體系下其他框架。
@Configuration public class RedisSentinelConfig { @Autowired private RedisProperties redisProperties; @Bean public RedisConnectionFactory lettuceConnectionFactory() { RedisProperties.Sentinel sentinel = redisProperties.getSentinel(); HashSet<String> nodes = new HashSet<>(sentinel.getNodes()); String master = sentinel.getMaster(); RedisSentinelConfiguration config = new RedisSentinelConfiguration(master, nodes); config.setDatabase(redisProperties.getDatabase()); return new LettuceConnectionFactory(config); } }
基礎整合僅僅是實現了高可用Redis服務的流程,生產環境下仍需要增加其他配置:修改自定義連接數據庫序號;授權連接;連接池配置;讀寫分離。
在高可用前提下,衍生出讀寫分離的特性,主庫完成寫請求;從庫完成讀請求(從庫不允許寫)。
@Bean public LettuceClientConfigurationBuilderCustomizer lettuceClientCustomizer() { // 配置讀寫分離 return builder -> builder.readFrom(ReadFrom.REPLICA); }
關于“Redis哨兵模式高可用的示例分析”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,使各位可以學到更多知識,如果覺得文章不錯,請把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。