Redis(二)

零 、 目錄

• 將緩存引入電商項目
• 主從復制
• 哨兵模式
• 集群容忍度
• 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"><!-- 構建連接池配置信息 --><bean id="jedisPoolConfig" class="redis.clients.jedis.JedisPoolConfig"><!-- 最大連接數 --><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對象 ， 即可使用 。

十一、 主從復制

當前redis結構可用性非常低， 當其中某個結點宕機之后 ， 數據不可查 ， 需要機器重啟后才能恢復 。

解決不可用問題需要引入高可用的結構（高可用 ， 即使宕機任然不影響當前功能）

具體實現 ， 引入三臺機器 ， 將主節點的數據全部復制 。 （主從復制 ， 數據備份）

當主節點（master）宕機之后 ， 從節點（slave）能夠頂替主節點來接收接下來的求情 ， 這種結構就叫做高可用

分布式架構中 ， 必不可少高可用特性

主從結構：

redis可以提供主從復制的結構

redis提供的主從結構支持多級復制

在redis中配置了主從結構之后 ，主節點的數據操作（贈 、 刪 、 改）將實時同步到從節點中

操作：

準備主節點 、 從節點的配置文件

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

分別啟動這三個redis文件對應的reids服務

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

在客戶端中操作 ， 實現一主兩從結構 6382（主） 、 6383 、 6384（從） ， 需要在6383 、 和6384 的客戶端執行 slaveof 127.0.0.1（主節點主機IP ， 如果在同一臺機器中 ，最好使用內網地址 ） 主節點端口

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

主節點信息

從節點信息

十二、 哨兵模式

完成上面的操作（構建一主兩從結構）之后 ， 測試該結構的高可用

把直接點kill（或在主節點的客戶端shutdown）掉 ， 查看某一個從節點是否主動擔任了主節點的角色 ， 并且將另一個從節點掛載在自己身上繼續完成主從復制（主從結構的目的）

操作：

在主節點6382的客戶端中執行shutdown ， 模擬主節點宕機 ，

觀察從節點的info replication ， 發現角色并沒有任何轉變 ， 高可用并沒有啟動

于是redis中引入了哨兵模式

哨兵是redis啟動的進程 ， 一個哨兵進程可以掛載一個主從的結構 ， 來管理當前主從結構的高可用,多個哨兵進程可以掛載多個主從結構,多個哨兵可以掛載一個主從

哨兵進程通過連接主從執行info命令,判斷當前主從結構是否正常,當發現主節點宕機,將會啟動內部邏輯,將從節點中的slave-priority數值較高的節點啟動替換主節點,將其他的從節點掛接到新的主節點上完成高可用主從替換

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

哨兵模式+主從復制的最終模式

操作步驟：

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

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

protected-mode no 關閉保護模式 （不需要密碼了）

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

修改監聽主從的掛接配置

sentinel monitor ： 開始監聽主從結構中的主節點

mymaster ： 給監聽的主從結構起個名字

ip ： 主節點的所在的ip

port ： 主節點的端口號

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

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

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

想要實現的效果：高可用結構啟動之后 ， 當主節點宕機之后 ， 從節點主動變為主節點 。

開啟需要監聽的主從結構 ， 開啟所有哨兵進程 、 開始監聽主從結構 開啟命令： redis-sentinel 哨兵的配置文件

測試： shutdown掉主節點 ， 看看哨兵是否啟動高可用new-epoch :邏輯時間數 ， 當前的日志步數

將宕機的主節點重啟 ， 發現哨兵將剛啟動的舊的主節點作為現在的主節點的從節點提供服務

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

注意： 當原本只有兩個哨兵時 ， 宕掉一個之后 ， 一個哨兵投票始終無法票數過半 ，導致陷入死循環 ， 導致一直在投票 。所以最好啟動奇數個哨兵

在Jedis中也是支持哨兵模式的 ， api配置內容就從配置具體的redis信息,到配置哨兵的節點信息和端口,3.0以后的redis引入了集群的技術,導致哨兵的高可用不在單獨使用集群里就包含了哨兵的高可用,包含了主從結構

十三、 集群容忍度：

選舉過半原則導致 ， 集群容忍度概念的引出

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

十二、 CAP理論

隨著數據量存儲增長需求 ， 業務的多元化 ， 分布式結構必不可少 ， CAP理論始終是分布式公認的基礎理論之一。

C ： consistency（一致性）

A ： avalibility（可用性）

P ： partition（分區） – tolerence to paetition（分區容忍度）

分區：

一個系統中 ， 多個系統組成網絡本來應該是互通的， 但是可能因為某種原因導致某兩個或某幾個結點間的數據通信斷開 ， 導致整個系統被分割成為了幾個獨立的數據區域（分區） 。 分區是一種常態 。

當分區出現時 ， 就需要考慮數據的一致性 。

一致性：

數據在某個查看的時間點上保持整體一致

如果在修改數據時 ， 對于查看數據的客戶端要求數據一致 ， 則必須加鎖 ， 實現數據整體性

如果在修改數據時 ， 對弈查看數據的客戶端不要求數據一致 ， 則沒有體現數據的一致性

分區容忍度：

如果對數據一致性要求高的話 ， 分區容忍度高 ， 一致性需要執行（即加鎖）

如果對數據一致性要求低 ， 則分區容忍度低

如果要求數據一致性高（加鎖）的查看數據的人 ， 在一段時間（修改數據的一段時間）內無法進行查看數據

可用性：

請求在一段時間都有回應（請求時立即返回請求數據）

總結：

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

cp理論： 分區容忍度高， 數據一致性高 ， 可用性降低

ap理論： 分區容忍度低 ， 數據一致性低， 可用性提升

分區導致一致性的要求 ， 要求高 ， 可用性低 ，要求低 ， 可用性高 。

隨中數據量存儲增長的需求 ， 數據多元化

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。