Redis(二)

零 、 目錄

• 將緩存引入電商項目
• 主從復(fù)制
• 哨兵模式
• 集群容忍度
• CAP理論

十、 將緩存引入電商項目

使用Spring框架維護Jedis池對象

引入一個配置文件 application-redis.config

<beans xmlns="http://www.springframework.org/schema/beans"xmlns:context="http://www.springframework.org/schema/context" xmlns:p="http://www.springframework.org/schema/p"xmlns:aop="http://www.springframework.org/schema/aop" xmlns:tx="http://www.springframework.org/schema/tx"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.0.xsdhttp://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-4.0.xsdhttp://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-4.0.xsd http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-4.0.xsdhttp://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-4.0.xsd"><!-- 構(gòu)建連接池配置信息 --><bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig"><!-- 最大連接數(shù) --><property name="maxTotal" value="${redis.maxTotal}" /></bean><bean id="jedisShardInfo1" class="redis.clients.jedis.JedisShardInfo"><constructor-arg index="0" value="${redis.node1.ip}" /><constructor-arg index="1" value="${redis.node1.port}"type="int" /></bean><!-- bean id="jedisShardInfo2" class="redis.clients.jedis.JedisShardInfo"><constructor-arg index="0" value="${redis.node2.ip}" /><constructor-arg index="1" value="${redis.node2.port}"type="int" /></bean><bean id="jedisShardInfo3" class="redis.clients.jedis.JedisShardInfo"><constructor-arg index="0" value="${redis.node3.ip}" /><constructor-arg index="1" value="${redis.node3.port}"type="int" /></bean--><!-- 定義集群連接池 --><bean id="shardedJedisPool" class="redis.clients.jedis.ShardedJedisPool"destroy-method="close"><constructor-arg index="0" ref="jedisPoolConfig" /><constructor-arg index="1"><list><ref bean="jedisShardInfo1" /><!--ref bean="jedisShardInfo2" /><ref bean="jedisShardInfo3" /--></list></constructor-arg></bean></beans>

需要加載配置文件 ， 在application.xml（Spring核心配置文件中配置加載application-redis.xml中所需要的配置信息）

redis.maxTotal=200 redis.node1.ip=106.75.85.179 redis.node1.port=6379 redis.node2.ip=106.75.85.179 redis.node2.port=6380 redis.node3.ip=106.75.85.179 redis.node3.port=6381

使用注解自動注入shardedjedidpool對象 ， 即可使用 。

十一、 主從復(fù)制

當(dāng)前redis結(jié)構(gòu)可用性非常低， 當(dāng)其中某個結(jié)點宕機之后 ， 數(shù)據(jù)不可查 ， 需要機器重啟后才能恢復(fù) 。

解決不可用問題需要引入高可用的結(jié)構(gòu)（高可用 ， 即使宕機任然不影響當(dāng)前功能）

具體實現(xiàn) ， 引入三臺機器 ， 將主節(jié)點的數(shù)據(jù)全部復(fù)制 。 （主從復(fù)制 ， 數(shù)據(jù)備份）

當(dāng)主節(jié)點（master）宕機之后 ， 從節(jié)點（slave）能夠頂替主節(jié)點來接收接下來的求情 ， 這種結(jié)構(gòu)就叫做高可用

分布式架構(gòu)中 ， 必不可少高可用特性

主從結(jié)構(gòu)：

redis可以提供主從復(fù)制的結(jié)構(gòu)

redis提供的主從結(jié)構(gòu)支持多級復(fù)制

在redis中配置了主從結(jié)構(gòu)之后 ，主節(jié)點的數(shù)據(jù)操作（贈 、 刪 、 改）將實時同步到從節(jié)點中

操作：

準備主節(jié)點 、 從節(jié)點的配置文件

分別 編輯配置文件的bind（注掉） 、 port （不要與其他端口沖突即可） 、 protected-modo no 、 diamonize yes（后臺守護） 、 pid文件 （pidfile_與端口對應(yīng) ）

分別啟動這三個redis文件對應(yīng)的reids服務(wù)

再打開三個終端 ， 分別開啟redis客戶端（redis-cli -p 端口號） 執(zhí)行info replication ， 查看信息

在客戶端中操作 ， 實現(xiàn)一主兩從結(jié)構(gòu) 6382（主） 、 6383 、 6384（從） ， 需要在6383 、 和6384 的客戶端執(zhí)行 slaveof 127.0.0.1（主節(jié)點主機IP ， 如果在同一臺機器中 ，最好使用內(nèi)網(wǎng)地址 ） 主節(jié)點端口

從節(jié)點掛接主節(jié)點完成之后 ， 查看三個客戶端的info replication信息中的role等信息 ， 查看是否掛載成功

主節(jié)點信息

從節(jié)點信息

十二、 哨兵模式

完成上面的操作（構(gòu)建一主兩從結(jié)構(gòu)）之后 ， 測試該結(jié)構(gòu)的高可用

把直接點kill（或在主節(jié)點的客戶端shutdown）掉 ， 查看某一個從節(jié)點是否主動擔(dān)任了主節(jié)點的角色 ， 并且將另一個從節(jié)點掛載在自己身上繼續(xù)完成主從復(fù)制（主從結(jié)構(gòu)的目的）

操作：

在主節(jié)點6382的客戶端中執(zhí)行shutdown ， 模擬主節(jié)點宕機 ，

觀察從節(jié)點的info replication ， 發(fā)現(xiàn)角色并沒有任何轉(zhuǎn)變 ， 高可用并沒有啟動

于是redis中引入了哨兵模式

哨兵是redis啟動的進程 ， 一個哨兵進程可以掛載一個主從的結(jié)構(gòu) ， 來管理當(dāng)前主從結(jié)構(gòu)的高可用,多個哨兵進程可以掛載多個主從結(jié)構(gòu),多個哨兵可以掛載一個主從

哨兵進程通過連接主從執(zhí)行info命令,判斷當(dāng)前主從結(jié)構(gòu)是否正常,當(dāng)發(fā)現(xiàn)主節(jié)點宕機,將會啟動內(nèi)部邏輯,將從節(jié)點中的slave-priority數(shù)值較高的節(jié)點啟動替換主節(jié)點,將其他的從節(jié)點掛接到新的主節(jié)點上完成高可用主從替換

哨兵集群 啟動后 ， 整個架構(gòu)就是高可用的最終模式

哨兵模式+主從復(fù)制的最終模式

操作步驟：

修改啟動哨兵的配置文件 sentinel.cong

bind注釋掉 ， 在測試中不需要綁定指定的ip ， 任何ip都可以訪問

protected-mode no 關(guān)閉保護模式 （不需要密碼了）

哨兵的默認端口是26379 ， 我們這里使用三個哨兵做示例 ， 所以使用26379 、 26380 、 26381 三個端口

修改監(jiān)聽主從的掛接配置

sentinel monitor ： 開始監(jiān)聽主從結(jié)構(gòu)中的主節(jié)點

mymaster ： 給監(jiān)聽的主從結(jié)構(gòu)起個名字

ip ： 主節(jié)點的所在的ip

port ： 主節(jié)點的端口號

2 ： 哨兵啟動后投票選舉新的主節(jié)點的最少哨兵的數(shù)量 ， 配置成1

修改選舉新節(jié)點失敗時的時間延遲（第一輪選舉和第二輪選舉的時間間隔）

復(fù)制配置好的哨兵配置文件 ， 并修改哨兵自己的的端口 26380 、 26381

想要實現(xiàn)的效果：高可用結(jié)構(gòu)啟動之后 ， 當(dāng)主節(jié)點宕機之后 ， 從節(jié)點主動變?yōu)橹鞴?jié)點 。

開啟需要監(jiān)聽的主從結(jié)構(gòu) ， 開啟所有哨兵進程 、 開始監(jiān)聽主從結(jié)構(gòu) 開啟命令： redis-sentinel 哨兵的配置文件

測試： shutdown掉主節(jié)點 ， 看看哨兵是否啟動高可用new-epoch :邏輯時間數(shù) ， 當(dāng)前的日志步數(shù)

將宕機的主節(jié)點重啟 ， 發(fā)現(xiàn)哨兵將剛啟動的舊的主節(jié)點作為現(xiàn)在的主節(jié)點的從節(jié)點提供服務(wù)

宕掉一個哨兵后再視圖宕掉一個主節(jié)點 ， 這時剩余的兩個哨兵會進行投票選舉 ， 如果單個從結(jié)點投票過半 ， 則被晉升為主節(jié)點 。

注意： 當(dāng)原本只有兩個哨兵時 ， 宕掉一個之后 ， 一個哨兵投票始終無法票數(shù)過半 ，導(dǎo)致陷入死循環(huán) ， 導(dǎo)致一直在投票 。所以最好啟動奇數(shù)個哨兵

在Jedis中也是支持哨兵模式的 ， api配置內(nèi)容就從配置具體的redis信息,到配置哨兵的節(jié)點信息和端口,3.0以后的redis引入了集群的技術(shù),導(dǎo)致哨兵的高可用不在單獨使用集群里就包含了哨兵的高可用,包含了主從結(jié)構(gòu)

十三、 集群容忍度：

選舉過半原則導(dǎo)致 ， 集群容忍度概念的引出

2個哨兵,多少算過半(2個)--,允許宕機的個數(shù)0,集群容忍度0, 3個哨兵,2個過半沒允許,宕機的個數(shù)是1,容忍度1 4個哨兵,3個過半,宕機個數(shù)允許1,容忍度1 2n個選舉法人,2n-1個選舉法人的容忍度一樣

十二、 CAP理論

隨著數(shù)據(jù)量存儲增長需求 ， 業(yè)務(wù)的多元化 ， 分布式結(jié)構(gòu)必不可少 ， CAP理論始終是分布式公認的基礎(chǔ)理論之一。

C ： consistency（一致性）

A ： avalibility（可用性）

P ： partition（分區(qū)） – tolerence to paetition（分區(qū)容忍度）

分區(qū)：

一個系統(tǒng)中 ， 多個系統(tǒng)組成網(wǎng)絡(luò)本來應(yīng)該是互通的， 但是可能因為某種原因?qū)е履硟蓚€或某幾個結(jié)點間的數(shù)據(jù)通信斷開 ， 導(dǎo)致整個系統(tǒng)被分割成為了幾個獨立的數(shù)據(jù)區(qū)域（分區(qū)） 。 分區(qū)是一種常態(tài) 。

當(dāng)分區(qū)出現(xiàn)時 ， 就需要考慮數(shù)據(jù)的一致性 。

一致性：

數(shù)據(jù)在某個查看的時間點上保持整體一致

如果在修改數(shù)據(jù)時 ， 對于查看數(shù)據(jù)的客戶端要求數(shù)據(jù)一致 ， 則必須加鎖 ， 實現(xiàn)數(shù)據(jù)整體性

如果在修改數(shù)據(jù)時 ， 對弈查看數(shù)據(jù)的客戶端不要求數(shù)據(jù)一致 ， 則沒有體現(xiàn)數(shù)據(jù)的一致性

分區(qū)容忍度：

如果對數(shù)據(jù)一致性要求高的話 ， 分區(qū)容忍度高 ， 一致性需要執(zhí)行（即加鎖）

如果對數(shù)據(jù)一致性要求低 ， 則分區(qū)容忍度低

如果要求數(shù)據(jù)一致性高（加鎖）的查看數(shù)據(jù)的人 ， 在一段時間（修改數(shù)據(jù)的一段時間）內(nèi)無法進行查看數(shù)據(jù)

可用性：

請求在一段時間都有回應(yīng)（請求時立即返回請求數(shù)據(jù)）

總結(jié)：

分區(qū)是常態(tài)（始終是存在的） ， 而一致性和可用性相互矛盾 只能滿足其一 ， 不可能達到三者共存的狀態(tài) 。

cp理論： 分區(qū)容忍度高， 數(shù)據(jù)一致性高 ， 可用性降低

ap理論： 分區(qū)容忍度低 ， 數(shù)據(jù)一致性低， 可用性提升

分區(qū)導(dǎo)致一致性的要求 ， 要求高 ， 可用性低 ，要求低 ， 可用性高 。

隨中數(shù)據(jù)量存儲增長的需求 ， 數(shù)據(jù)多元化

問題： 使用Jedis連接之前是否需要先打開redis客戶端？

總結(jié)

以上是生活随笔為你收集整理的大数据互联网架构阶段 Redis（二）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。