淺析Redis Sentinel 與 Redis Cluster

一、前言

互聯(lián)網(wǎng)高速發(fā)展的今天，對應用系統(tǒng)的抗壓能力要求越來越高，傳統(tǒng)的應用層+數(shù)據(jù)庫已經(jīng)不能滿足當前的需要。所以一大批內(nèi)存式數(shù)據(jù)庫和Nosql數(shù)據(jù)庫應運而生，其中redis,memcache,mongodb,hbase等被廣泛的使用來提高系統(tǒng)的吞吐性，所以如何正確使用cache是作為開發(fā)的一項基技能。本文主要介紹Redis Sentinel 及 Redis Cluster的區(qū)別及用法，Redis的基本操作可以自行去參看其官方文檔 。 其他幾種cache有興趣的可自行找資料去學習。

二、Redis Sentinel 及 Redis Cluster 簡介

1、Redis Sentinel

 Redis-Sentinel(哨兵模式)是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master宕機了，Redis本身(包括它的很多客戶端)都沒有實現(xiàn)自動進行主備切換，而Redis-sentinel本身也是一個獨立運行的進程，它能監(jiān)控多個master-slave集群，發(fā)現(xiàn)master宕機后能進行自懂切換。它的主要功能有以下幾點：

• 不時地監(jiān)控redis是否按照預期良好地運行;
• 如果發(fā)現(xiàn)某個redis節(jié)點運行出現(xiàn)狀況，能夠通知另外一個進程(例如它的客戶端);
• 能夠進行自動切換。當一個master節(jié)點不可用時，能夠選舉出master的多個slave(如果有超過一個slave的話)中的一個來作為新的master,其它的slave節(jié)點會將它所追隨的master的地址改為被提升為master的slave的新地址。
  

       Redis master-slave 模式如下圖：

從上圖片中可以看到，一個master 節(jié)點可以掛多個slave  ，Redis Sentinel 管理Redis 節(jié)點結(jié)構(gòu)如下：

上圖中可以得出Sentinel其實就是Client和Redis之間的橋梁，所有的客戶端都通過Sentinel程序獲取Redis的Master服務(wù)。首先Sentinel是集群部署的，Client可以鏈接任何一個Sentinel服務(wù)所獲的結(jié)果都是一致的。其次，所有的Sentinel服務(wù)都會對Redis的主從服務(wù)進行監(jiān)控，當監(jiān)控到Master服務(wù)無響應的時候，Sentinel內(nèi)部進行仲裁，從所有的 Slave選舉出一個做為新的Master。并且把其他的slave作為新的Master的Slave。最后通知所有的客戶端新的Master服務(wù)地址。如果舊的Master服務(wù)地址重新啟動，這個時候，它將被設(shè)置為Slave服務(wù)。

Sentinel 可以管理master-slave節(jié)點，看似Redis的穩(wěn)定性得到一個比較好的保障。但是如果Sentinel是單節(jié)點的話，如果Sentinel宕機了，那master-slave這種模式就不能發(fā)揮其作用了。幸好Sentinel也支持集群模式，Sentinel的集群模式主要有以下幾個好處：

• 即使有一些sentinel進程宕掉了，依然可以進行redis集群的主備切換；
• 如果只有一個sentinel進程，如果這個進程運行出錯，或者是網(wǎng)絡(luò)堵塞，那么將無法實現(xiàn)redis集群的主備切換（單點問題）;
• 如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關(guān)于redis集群中的信息。

     Redis Sentinel 集群模式可以增強整個Redis集群的穩(wěn)定性與可靠性，但是當某個節(jié)點的master節(jié)點掛了要重新選取出新的master節(jié)點時，Redis Sentinel的集群模式選取的復雜度顯然高于單點的Redis Sentinel 模式，此時需要一個比較靠譜的選取算法。下面就來介紹Redis Sentinel 集群模式的 “仲裁會”(多個Redis Sentinel共同商量誰是Redis 的 master節(jié)點)

1.1、Redis Sentinel 集群模式的 “仲裁會”

 當一個master被sentinel集群監(jiān)控時，需要為它指定一個參數(shù)，這個參數(shù)指定了當需要判決master為不可用，并且進行failover時，所需要的sentinel數(shù)量，本文中我們暫時稱這個參數(shù)為票數(shù),不過，當failover主備切換真正被觸發(fā)后，failover并不會馬上進行，還需要sentinel中的大多數(shù)sentinel授權(quán)后才可以進行failover。當ODOWN時，failover被觸發(fā)。failover一旦被觸發(fā)，嘗試去進行failover的sentinel會去獲得“大多數(shù)”sentinel的授權(quán)（如果票數(shù)比大多數(shù)還要大的時候，則詢問更多的sentinel)這個區(qū)別看起來很微妙，但是很容易理解和使用。例如，集群中有5個sentinel，票數(shù)被設(shè)置為2，當2個sentinel認為一個master已經(jīng)不可用了以后，將會觸發(fā)failover，但是，進行failover的那個sentinel必須先獲得至少3個sentinel的授權(quán)才可以實行failover。如果票數(shù)被設(shè)置為5，要達到ODOWN狀態(tài)，必須所有5個sentinel都主觀認為master為不可用，要進行failover，那么得獲得所有5個sentinel的授權(quán)。

2、Redis Cluster

使用Redis Sentinel 模式架構(gòu)的緩存體系，在使用的過程中，隨著業(yè)務(wù)的增加不可避免的要對Redis進行擴容，熟知的擴容方式有兩種，一種是垂直擴容，一種是水平擴容。垂直擴容表示通過加內(nèi)存方式來增加整個緩存體系的容量比如將緩存大小由2G調(diào)整到4G,這種擴容不需要應用程序支持；水平擴容表示表示通過增加節(jié)點的方式來增加整個緩存體系的容量比如本來有1個節(jié)點變成2個節(jié)點，這種擴容方式需要應用程序支持。垂直擴容看似最便捷的擴容，但是受到機器的限制，一個機器的內(nèi)存是有限的，所以垂直擴容到一定階段不可避免的要進行水平擴容，如果預留出很多節(jié)點感覺又是對資源的一種浪費因為對業(yè)務(wù)的發(fā)展趨勢很快預測。Redis Sentinel 水平擴容一直都是程序猿心中的痛點，因為水平擴容牽涉到數(shù)據(jù)的遷移。遷移過程一方面要保證自己的業(yè)務(wù)是可用的，一方面要保證盡量不丟失數(shù)據(jù)所以數(shù)據(jù)能不遷移就盡量不遷移。針對這個問題，Redis Cluster就應運而生了，下面簡單介紹一下RedisCluster。

Redis Cluster是Redis的分布式解決方案，在Redis 3.0版本正式推出的，有效解決了Redis分布式方面的需求。當遇到單機內(nèi)存、并發(fā)、流量等瓶頸時，可以采用Cluster架構(gòu)達到負載均衡的目的。分布式集群首要解決把整個數(shù)據(jù)集按照分區(qū)規(guī)則映射到多個節(jié)點的問題，即把數(shù)據(jù)集劃分到多個節(jié)點上，每個節(jié)點負責整個數(shù)據(jù)的一個子集。Redis Cluster采用哈希分區(qū)規(guī)則中的虛擬槽分區(qū)。虛擬槽分區(qū)巧妙地使用了哈?？臻g，使用分散度良好的哈希函數(shù)把所有的數(shù)據(jù)映射到一個固定范圍內(nèi)的整數(shù)集合，整數(shù)定義為槽（slot）。Redis Cluster槽的范圍是0 ～ 16383。槽是集群內(nèi)數(shù)據(jù)管理和遷移的基本單位。采用大范圍的槽的主要目的是為了方便數(shù)據(jù)的拆分和集群的擴展，每個節(jié)點負責一定數(shù)量的槽。Redis Cluster采用虛擬槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到0 ～ 16383，計算公式：slot = CRC16(key)16383。每一個實節(jié)點負責維護一部分槽以及槽所映射的鍵值數(shù)據(jù)。下圖展現(xiàn)一個五個節(jié)點構(gòu)成的集群，每個節(jié)點平均大約負責3276個槽，以及通過計算公式映射到對應節(jié)點的對應槽的過程。

Redis Cluster節(jié)點相互之前的關(guān)系如下圖所示：

三、Redis Sentinel 及Redis Cluster 實踐

Redis Sentinel 與Redis Cluster 使用需要引入如下jar包

dependency>
    groupId>redis.clients/groupId>
    artifactId>jedis/artifactId>
    version>2.9.0/version>
/dependency>
 
dependency>
    groupId>org.apache.commons/groupId>
    artifactId>commons-pool2/artifactId>
    version>2.5.0/version>
/dependency>

1、Redis Sentinel 使用

package com.knowledge.cache.redis;
 
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisSentinelPool;
import redis.clients.jedis.exceptions.JedisConnectionException;
 
import org.apache.commons.lang3.StringUtils;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;
 
/**
 * @author hzwangjunqiang1@corp.netease.com
 * @desc redis sentinel 使用
 */
public class RedisSentinelClient {
    private static JedisSentinelPool pool = null;
    private static String redisHosts = "127.0.0.1:26378;127.0.0.1:26379;127.0.0.1:26380";
    private static String redisMaster = "";//master name
    private static String password = "";//密碼,可選
    private static final int MAX_IDLE = 200;//最大空閑數(shù)
    private static final int MAX_TOTAL = 400;//最大連接數(shù)
    private static final int MIN_IDLE = 200;//最小空閑數(shù)
 
    static {
        //redis 連接池配置
        GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
        poolConfig.setMaxIdle(MAX_IDLE);
        poolConfig.setMaxTotal(MAX_TOTAL);
        poolConfig.setMinIdle(MIN_IDLE);
        poolConfig.setTestOnBorrow(true);
        poolConfig.setTestOnReturn(true);
        SetString> hosts = new HashSetString>(Arrays.asList(redisHosts.split(";")));
        if (StringUtils.isBlank(password)) {
            pool = new JedisSentinelPool(redisMaster, hosts, poolConfig);
        } else {
            pool = new JedisSentinelPool(redisMaster, hosts, poolConfig, password);
        }
    }
 
    public String get(String key) throws JedisConnectionException {
        Jedis jedis = pool.getResource();
        try {
            return jedis.get(key);
        } catch (JedisConnectionException e) {
            throw e;
        } finally {
            jedis.close();
        }
    }
}

2、Redis Cluster 使用

package com.knowledge.cache.redis;
 
import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.exceptions.JedisConnectionException;
 
import org.apache.commons.lang3.StringUtils;
import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import java.util.Arrays;
import java.util.HashSet;
import java.util.LinkedHashSet;
import java.util.Set;
 
/**
 * @author hzwangjunqiang1@corp.netease.com
 * @desc Redis cluster 使用
 */
public class RedisClusterClient {
    private static JedisCluster jedisCluster = null;
    private static String redisHosts = "127.0.0.1:6378;127.0.0.1:6379;127.0.0.1:6380"; //如:127.0.0.1:26379;127.0.0.1:26378
    private static String password = "";//密碼,可選
    private static final int CONNECT_TIMEOUT = 1000;//連接超時時間
    private static final int SO_TIMEOUT = 1000;//響應超時時間
    private static final int MAX_ATTEMPTS = 5;//最大嘗試次數(shù)
    private static final int MAX_IDLE = 200;//最大空閑數(shù)
    private static final int MAX_TOTAL = 400;//最大連接數(shù)
    private static final int MIN_IDLE = 200;//最小空閑數(shù)
 
    static {
        //連接池配置
        GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
        poolConfig.setMaxIdle(MAX_IDLE);
        poolConfig.setMaxTotal(MAX_TOTAL);
        poolConfig.setMinIdle(MIN_IDLE);
        poolConfig.setTestOnBorrow(true);
        poolConfig.setTestOnReturn(true);
        //Redis Cluster 初始化
        SetString> hosts = new HashSetString>(Arrays.asList(redisHosts.split(";")));
        SetHostAndPort> nodes = new LinkedHashSetHostAndPort>();
        for (String host : hosts) {
            HostAndPort hostAndPort = new HostAndPort(host.split(":")[0], Integer.parseInt(host.split(":")[1]));
            nodes.add(hostAndPort);
        }
 
        if (StringUtils.isBlank(password)) {
            jedisCluster = new JedisCluster(nodes, CONNECT_TIMEOUT, SO_TIMEOUT, MAX_ATTEMPTS, poolConfig);
        } else {
            jedisCluster = new JedisCluster(nodes, CONNECT_TIMEOUT, SO_TIMEOUT, MAX_ATTEMPTS, password, poolConfig);
        }
    }
 
    /**
     * @param key
     * @return
     * @throws JedisConnectionException
     */
    public String get(String key) throws JedisConnectionException {
        try {
            return jedisCluster.get(key);
        } catch (JedisConnectionException e) {
            throw e;
        }
    }
 
    /**
     * @param key
     * @param value
     * @return
     * @throws JedisConnectionException
     */
    public String set(String key, String value) throws JedisConnectionException {
 
        try {
            return jedisCluster.set(key, value);
        } catch (JedisConnectionException e) {
            throw e;
        }
    }
}
 

以上介紹了Redis Sentinel 及 Redis Cluster的初始化過程及簡單的使用，其他比較復雜的應用可以參考Redis 的官方API

四、Redis的過期淘汰策略

1、定時刪除

• 含義:在設(shè)置key的過期時間的同時，為該key創(chuàng)建一個定時器，讓定時器在key的過期時間來臨時，對key進行刪除
• 優(yōu)點:保證內(nèi)存被盡快釋放
• 缺點:1)若過期key很多，刪除這些key會占用很多的CPU時間，在CPU時間緊張的情況下，CPU不能把所有的時間用來做要緊的事兒，還需要去花時間刪除這些key;2)定時器的創(chuàng)建耗時,若為每一個設(shè)置過期時間的key創(chuàng)建一個定時器（將會有大量的定時器產(chǎn)生），性能影響嚴重
  

2、懶漢式刪除

• 含義:key過期的時候不刪除，每次通過key獲取值的時候去檢查是否過期，若過期，則刪除，返回null。
• 優(yōu)點:刪除操作只發(fā)生在通過key取值的時候發(fā)生，而且只刪除當前key，所以對CPU時間的占用是比較少的，而且此時的刪除是已經(jīng)到了非做不可的地步（如果此時還不刪除的話，我們就會獲取到了已經(jīng)過期的key了
• 缺點:若大量的key在超出超時時間后，很久一段時間內(nèi)，都沒有被獲取過，那么可能發(fā)生內(nèi)存泄露（無用的垃圾占用了大量的內(nèi)存）
  

3、定期刪除

含義:每隔一段時間執(zhí)行一次刪除過期key操作

優(yōu)點:
1)通過限制刪除操作的時長和頻率，來減少刪除操作對CPU時間的占用--處理"定時刪除"的缺點;
2)定期刪除過期key--處理"懶漢式刪除"的缺點

缺點:
1)在內(nèi)存友好方面，不如"定時刪除"（會造成一定的內(nèi)存占用，但是沒有懶漢式那么占用內(nèi)存）;
2)在CPU時間友好方面，不如"懶漢式刪除"（會定期的去進行比較和刪除操作，cpu方面不如懶漢式，但是比定時好）

難點:
1)合理設(shè)置刪除操作的執(zhí)行時長（每次刪除執(zhí)行多長時間）和執(zhí)行頻率（每隔多長時間做一次刪除）（這個要根據(jù)服務(wù)器運行情況來定了），每次執(zhí)行時間太長，或者執(zhí)行頻率太高對cpu都是一種壓力;
2) 每次進行定期刪除操作執(zhí)行之后，需要記錄遍歷循環(huán)到了哪個標志位，以便下一次定期時間來時，從上次位置開始進行循環(huán)遍歷

memcached只是用了惰性刪除，而redis同時使用了惰性刪除與定期刪除，這也是二者的一個不同點（可以看做是redis優(yōu)于memcached的一點）;

五、Redis 使用過程中踩過的坑

1、在生產(chǎn)環(huán)境中一定要配置GenericObjectPoolConfig中的 maxIdle、maxTotal、minIdle.因為里面默認值太低了，如果生產(chǎn)環(huán)境中流量比較大的話，就會出現(xiàn)等待redis的連接的情況。

2、使用Redis Sentinel 一定要在最后執(zhí)行jedis.close方法來釋放資源，這個close方法是表示將正常的連接放回去連接池中，將不正常的連接給關(guān)閉。之前jedis低版本中都是調(diào)用returnResource方法來釋放資源，如果連接不正常了會被重復使用，這時會出現(xiàn)很詭異的異常。所以建議使用比較高版本的jedis

3、為了更好的使用redis 連接池，建議采用 JedisPoolConfig來替代GenericObjectPoolConfig。JedisPoolConfig里面有一些默認的參數(shù)

4、maxIdle，maxTotal 最佳實踐為 maxIdle = maxTotal

到此這篇關(guān)于淺析Redis Sentinel 與 Redis Cluster的文章就介紹到這了,更多相關(guān)Redis Sentinel與Redis Cluster內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！