【數據庫】Redis集羣篇

歡迎關注公衆號：【 愛編碼】
若是有須要後臺回覆 2019贈送 1T的學習資料哦！！

哨兵模式

背景

當主服務器宕機後，須要手動把一臺從服務器切換爲主服務器，這就須要人工干預，費事費力，還會形成一段時間內服務不可用。這不是一種推薦的方式，更多時候，咱們優先考慮哨兵模式。

定義

Sentinel（哨兵）是Redis 的高可用性解決方案：由一個或多個Sentinel 實例 組成的Sentinel 系統能夠監視任意多個主服務器，以及這些主服務器屬下的全部從服務器，並在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級爲新的主服務器。

實戰配置

1.首先配置Redis的主從服務器，修改redis.conf文件以下

# 使得Redis服務器能夠跨網絡訪問
bind 0.0.0.0
# 設置密碼
requirepass "123456"
# 指定主服務器，注意：有關slaveof的配置只是配置從服務器，主服務器不須要配置
slaveof 192.168.11.128 6379
# 主服務器密碼，注意：有關slaveof的配置只是配置從服務器，主服務器不須要配置
masterauth 123456

上述內容主要是配置Redis服務器，從服務器比主服務器多一個slaveof的配置和密碼。

1. 配置3個哨兵，每一個哨兵的配置都是同樣的。在Redis安裝目錄下有一個sentinel.conf文件，copy一份進行修改

# 禁止保護模式
protected-mode no
# 配置監聽的主服務器，這裏sentinel monitor表明監控，mymaster表明服務器的名稱，能夠自定義，192.168.11.128表明監控的主服務器，6379表明端口，2表明只有兩個或兩個以上的哨兵認爲主服務器不可用的時候，纔會進行failover操做。
sentinel monitor mymaster 192.168.11.128 6379 2
# sentinel author-pass定義服務的密碼，mymaster是服務名稱，123456是Redis服務器密碼
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456

1. 有了上述的修改，咱們能夠進入Redis的安裝目錄的src目錄，經過下面的命令啓動服務器和哨兵

# 啓動Redis服務器進程
./redis-server ../redis.conf
# 啓動哨兵進程
./redis-sentinel ../sentinel.conf

注意啓動的順序。首先是主機（192.168.11.128）的Redis服務進程，而後啓動從機的服務進程，最後啓動3個哨兵的服務進程。

參考文章：
https://www.jianshu.com/p/06a...

集羣

搭建集羣工做須要如下三個步驟：

1.準備節點

Redis集羣通常由多個節點組成，節點數量至少爲6個才能保證組成完整高可用的集羣。每一個節點須要開啓配置cluster-enabled yes，讓Redis運行在集羣模式下。建議爲集羣內全部節點統一目錄，通常劃分三個目錄：conf、data、log，分別存放配置、數據和日誌相關文件。把6個節點配置統一放在conf目錄下

#節點端口
port 6379
# 開啓集羣模式
cluster-enabled yes
# 節點超時時間，單位毫秒
cluster-node-timeout 15000
# 集羣內部配置文件
cluster-config-file "nodes-6379.conf"

其餘配置和單機模式一致便可，配置文件命名規則redis-{port}.conf，準備好配置後啓動全部節點，命令以下

redis-server conf/redis-6379.conf
redis-server conf/redis-6380.conf
redis-server conf/redis-6381.conf
redis-server conf/redis-6382.conf
redis-server conf/redis-6383.conf
redis-server conf/redis-6384.conf

2.節點握手

節點握手是指一批運行在集羣模式下的節點經過Gossip協議彼此通訊，達到感知對方的過程。節點握手是集羣彼此通訊的第一步，由客戶端發起命令：cluster meet{ip}{port}

圖中執行的命令是：cluster meet127.0.0.16380讓節點6379和6380節點進
行握手通訊。cluster meet命令是一個異步命令，執行以後馬上返回。內部發起與目標節點進行握手通訊。

127.0.0.1:6379>cluster meet 127.0.0.1 6381
127.0.0.1:6379>cluster meet 127.0.0.1 6382
127.0.0.1:6379>cluster meet 127.0.0.1 6383
127.0.0.1:6379>cluster meet 127.0.0.1 6384

最後執行cluster nodes命令確認6個節點都彼此感知並組成集羣

127.0.0.1:6379> cluster nodes
4fa7eac4080f0b667ffeab9b87841da49b84a6e4 127.0.0.1:6384 master - 0 1468073975551
5 connected
cfb28ef1deee4e0fa78da86abe5d24566744411e 127.0.0.1:6379 myself,master - 0 0 0 connected
be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 master - 0 1468073978579
4 connected
40622f9e7adc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 master - 0 1468073980598
3 connected
8e41673d59c9568aa9d29fb174ce733345b3e8f1 127.0.0.1:6380 master - 0 1468073974541
1 connected
40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 1468073979589
2 connected

節點創建握手以後集羣還不能正常工做，這時集羣處於下線狀態，全部的數據讀寫都被禁止。

3.分配槽

Redis集羣把全部的數據映射到16384個槽中。每一個key會映射爲一個固定的槽，只有當節點分配了槽，才能響應和這些槽關聯的鍵命令。經過cluster addslots命令爲節點分配槽。這裏利用bash特性批量設置槽（slots）

redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0...5461}
redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462...10922}
redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923...16383}

關於集羣伸縮、故障轉移、節點通訊等知識。
可參考《Redis開發與運維》

緩存設計

穿透優化

緩存穿透是指查詢一個根本不存在的數據，緩存層和存儲層都不會命中，一般出於容錯的考慮，若是從存儲層查不到數據則不寫入緩存層。
整個過程分爲以下3步

1.緩存層不命中。
2.存儲層不命中，不將空結果寫回緩存。
3.返回空結果

解決辦法

1.緩存空對象
存儲層不命中後，仍然將空對象保留到緩存層中，以後再訪問這個數據將會從緩存中獲取，這樣就保護了後端數據源。

緩存空對象會有兩個問題：
第一，空值作了緩存，意味着緩存層中存了更多的鍵，須要更多的內存空間（若是是攻擊，問題更嚴重），比較有效的方法是針對這類數據設置一個較短的過時時間，讓其自動剔除。

第二，緩存層和存儲層的數據會有一段時間窗口的不一致，可能會對業務有必定影響。例如過時時間設置爲5分鐘，若是此時存儲層添加了這個數據，那此段時間就會出現緩存層和存儲層數據的不一致，此時能夠利用消息系統或者其餘方式清除掉緩存層中的空對象。

相似代碼實現以下：

String get(String key) {
// 從緩存中獲取數據
String cacheValue = cache.get(key);
// 緩存爲空
if (StringUtils.isBlank(cacheValue)) {
    // 從存儲中獲取
    String storageValue = storage.get(key);
    cache.set(key, storageValue);
    // 若是存儲數據爲空，須要設置一個過時時間(300秒)
    if (storageValue == null) {
      cache.expire(key, 60 * 5);
    }
    return storageValue;
} else {
    // 緩存非空
    return cacheValue;
  }
}

2.布隆過濾器攔截

bloomfilter就相似於一個hash set，用於快速判某個元素是否存在於集合中，其典型的應用場景就是快速判斷一個key是否存在於某容器，不存在就直接返回。布隆過濾器的關鍵就在於hash算法和容器大小，下面先來簡單的實現下看看效果，我這裏用guava實現的布隆過濾器：

<dependencies>  
     <dependency>  
         <groupId>com.google.guava</groupId>  
         <artifactId>guava</artifactId>  
         <version>23.0</version>  
     </dependency>  
</dependencies>

public class BloomFilterTest {
 
    private static final int capacity = 1000000;
    private static final int key = 999998;
 
    private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity);
 
    static {
        for (int i = 0; i < capacity; i++) {
            bloomFilter.put(i);
        }
    }
 
    public static void main(String[] args) {
        /*返回計算機最精確的時間，單位微妙*/
        long start = System.nanoTime();
 
        if (bloomFilter.mightContain(key)) {
            System.out.println("成功過濾到" + key);
        }
        long end = System.nanoTime();
        System.out.println("布隆過濾器消耗時間:" + (end - start));
        int sum = 0;
        for (int i = capacity + 20000; i < capacity + 30000; i++) {
            if (bloomFilter.mightContain(i)) {
                sum = sum + 1;
            }
        }
        System.out.println("錯判率爲:" + sum);
    }
}

成功過濾到999998
布隆過濾器消耗時間:215518
錯判率爲:318

能夠看到，100w個數據中只消耗了約0.2毫秒就匹配到了key，速度足夠快。而後模擬了1w個不存在於布隆過濾器中的key，匹配錯誤率爲318/10000，也就是說，出錯率大概爲3%，跟蹤下BloomFilter的源碼發現默認的容錯率就是0.03：

public String getByKey(String key) {
    // 經過key獲取value
    String value = redisService.get(key);
    if (StringUtil.isEmpty(value)) {
        if (bloomFilter.mightContain(key)) {
            value = userService.getById(key);
            redisService.set(key, value);
            return value;
        } else {
            return null;
        }
    }
    return value;
}

更多知識可參考文章：
https://blog.csdn.net/fanrenx...

雪崩優化

因爲緩存層承載着大量請求，有效地保護了存儲層，可是若是緩存層因爲某些緣由不能提供服務，因而全部的請求都會達到存儲層，存儲層的調用量會暴增，形成存儲層也會級聯宕機的狀況。緩存雪崩的英文原意是stampeding herd（奔逃的野牛），指的是緩存層宕掉後，流量會像奔逃的野牛同樣，打向後端存儲。

預防和解決緩存雪崩問題，能夠從如下三個方面進行着手

1.保證緩存層服務高可用性。
和飛機都有多個引擎同樣，若是緩存層設計成高可用的，即便個別節點、個別機器、甚至是機房宕掉，依然能夠提供服務，例如前面介紹過的Redis Sentinel和Redis Cluster都實現了高可用

2.依賴隔離組件爲後端限流並降級。

不管是緩存層仍是存儲層都會有出錯的機率，能夠將它們視同爲資源。做爲併發量較大的系統，假若有一個資源不可用，可能會形成線程所有阻塞（hang）在這個資源上，形成整個系統不可用。降級機制在高併發系統中是很是廣泛的：好比推薦服務中，若是個性化推薦服務不可用，能夠降級補充熱點數據，不至於形成前端頁面是開天窗。
推薦一個Java依賴隔離工具Hystrix

3. 提早演練。
在項目上線前，演練緩存層宕掉後，應用以及後端的負載狀況以及可能出現的問題，在此基礎上作一些預案設定。

總結

Redis的學習到此爲止。之後會總結一下Redis的面試篇。
接下來會學習netty相關知識，敬請期待。

最後

若是對 Java、大數據感興趣請長按二維碼關注一波，我會努力帶給大家價值。以爲對你哪怕有一丁點幫助的請幫忙點個贊或者轉發哦。
關注公衆號【愛編碼】，回覆2019有相關資料哦。