目錄
- 一、前言
- 二、Redis Sentinel 及 Redis Cluster 簡介
- 1、Redis Sentinel
- 1.1、Redis Sentinel 集群模式的 “仲裁會”
- 2、Redis Cluster
- 三、Redis Sentinel 及Redis Cluster 實踐
- 四、Redis的過期淘汰策略
- 五、Redis 使用過程中踩過的坑
一、前言
互聯網高速發展的今天,對應用系統的抗壓能力要求越來越高,傳統的應用層+數據庫已經不能滿足當前的需要。所以一大批內存式數據庫和Nosql數據庫應運而生,其中redis,memcache,mongodb,hbase等被廣泛的使用來提高系統的吞吐性,所以如何正確使用cache是作為開發的一項基技能。本文主要介紹Redis Sentinel 及 Redis Cluster的區別及用法,Redis的基本操作可以自行去參看其官方文檔 。 其他幾種cache有興趣的可自行找資料去學習。
二、Redis Sentinel 及 Redis Cluster 簡介
1、Redis Sentinel
Redis-Sentinel(哨兵模式)是Redis官方推薦的高可用性(HA)解決方案,當用Redis做Master-slave的高可用方案時,假如master宕機了,Redis本身(包括它的很多客戶端)都沒有實現自動進行主備切換,而Redis-sentinel本身也是一個獨立運行的進程,它能監控多個master-slave集群,發現master宕機后能進行自懂切換。它的主要功能有以下幾點:
- 不時地監控redis是否按照預期良好地運行;
- 如果發現某個redis節點運行出現狀況,能夠通知另外一個進程(例如它的客戶端);
- 能夠進行自動切換。當一個master節點不可用時,能夠選舉出master的多個slave(如果有超過一個slave的話)中的一個來作為新的master,其它的slave節點會將它所追隨的master的地址改為被提升為master的slave的新地址。
Redis master-slave 模式如下圖:

從上圖片中可以看到,一個master 節點可以掛多個slave ,Redis Sentinel 管理Redis 節點結構如下:
上圖中可以得出Sentinel其實就是Client和Redis之間的橋梁,所有的客戶端都通過Sentinel程序獲取Redis的Master服務。首先Sentinel是集群部署的,Client可以鏈接任何一個Sentinel服務所獲的結果都是一致的。其次,所有的Sentinel服務都會對Redis的主從服務進行監控,當監控到Master服務無響應的時候,Sentinel內部進行仲裁,從所有的 Slave選舉出一個做為新的Master。并且把其他的slave作為新的Master的Slave。最后通知所有的客戶端新的Master服務地址。如果舊的Master服務地址重新啟動,這個時候,它將被設置為Slave服務。
Sentinel 可以管理master-slave節點,看似Redis的穩定性得到一個比較好的保障。但是如果Sentinel是單節點的話,如果Sentinel宕機了,那master-slave這種模式就不能發揮其作用了。幸好Sentinel也支持集群模式,Sentinel的集群模式主要有以下幾個好處:
- 即使有一些sentinel進程宕掉了,依然可以進行redis集群的主備切換;
- 如果只有一個sentinel進程,如果這個進程運行出錯,或者是網絡堵塞,那么將無法實現redis集群的主備切換(單點問題);
- 如果有多個sentinel,redis的客戶端可以隨意地連接任意一個sentinel來獲得關于redis集群中的信息。
Redis Sentinel 集群模式可以增強整個Redis集群的穩定性與可靠性,但是當某個節點的master節點掛了要重新選取出新的master節點時,Redis Sentinel的集群模式選取的復雜度顯然高于單點的Redis Sentinel 模式,此時需要一個比較靠譜的選取算法。下面就來介紹Redis Sentinel 集群模式的 “仲裁會”(多個Redis Sentinel共同商量誰是Redis 的 master節點)
1.1、Redis Sentinel 集群模式的 “仲裁會”
當一個master被sentinel集群監控時,需要為它指定一個參數,這個參數指定了當需要判決master為不可用,并且進行failover時,所需要的sentinel數量,本文中我們暫時稱這個參數為票數,不過,當failover主備切換真正被觸發后,failover并不會馬上進行,還需要sentinel中的大多數sentinel授權后才可以進行failover。當ODOWN時,failover被觸發。failover一旦被觸發,嘗試去進行failover的sentinel會去獲得“大多數”sentinel的授權(如果票數比大多數還要大的時候,則詢問更多的sentinel)這個區別看起來很微妙,但是很容易理解和使用。例如,集群中有5個sentinel,票數被設置為2,當2個sentinel認為一個master已經不可用了以后,將會觸發failover,但是,進行failover的那個sentinel必須先獲得至少3個sentinel的授權才可以實行failover。如果票數被設置為5,要達到ODOWN狀態,必須所有5個sentinel都主觀認為master為不可用,要進行failover,那么得獲得所有5個sentinel的授權。
2、Redis Cluster
使用Redis Sentinel 模式架構的緩存體系,在使用的過程中,隨著業務的增加不可避免的要對Redis進行擴容,熟知的擴容方式有兩種,一種是垂直擴容,一種是水平擴容。垂直擴容表示通過加內存方式來增加整個緩存體系的容量比如將緩存大小由2G調整到4G,這種擴容不需要應用程序支持;水平擴容表示表示通過增加節點的方式來增加整個緩存體系的容量比如本來有1個節點變成2個節點,這種擴容方式需要應用程序支持。垂直擴容看似最便捷的擴容,但是受到機器的限制,一個機器的內存是有限的,所以垂直擴容到一定階段不可避免的要進行水平擴容,如果預留出很多節點感覺又是對資源的一種浪費因為對業務的發展趨勢很快預測。Redis Sentinel 水平擴容一直都是程序猿心中的痛點,因為水平擴容牽涉到數據的遷移。遷移過程一方面要保證自己的業務是可用的,一方面要保證盡量不丟失數據所以數據能不遷移就盡量不遷移。針對這個問題,Redis Cluster就應運而生了,下面簡單介紹一下RedisCluster。
Redis Cluster是Redis的分布式解決方案,在Redis 3.0版本正式推出的,有效解決了Redis分布式方面的需求。當遇到單機內存、并發、流量等瓶頸時,可以采用Cluster架構達到負載均衡的目的。分布式集群首要解決把整個數據集按照分區規則映射到多個節點的問題,即把數據集劃分到多個節點上,每個節點負責整個數據的一個子集。Redis Cluster采用哈希分區規則中的虛擬槽分區。虛擬槽分區巧妙地使用了哈??臻g,使用分散度良好的哈希函數把所有的數據映射到一個固定范圍內的整數集合,整數定義為槽(slot)。Redis Cluster槽的范圍是0 ~ 16383。槽是集群內數據管理和遷移的基本單位。采用大范圍的槽的主要目的是為了方便數據的拆分和集群的擴展,每個節點負責一定數量的槽。Redis Cluster采用虛擬槽分區,所有的鍵根據哈希函數映射到0 ~ 16383,計算公式:slot = CRC16(key)16383。每一個實節點負責維護一部分槽以及槽所映射的鍵值數據。下圖展現一個五個節點構成的集群,每個節點平均大約負責3276
個槽,以及通過計算公式映射到對應節點的對應槽的過程。

Redis Cluster節點相互之前的關系如下圖所示:

三、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;//最大空閑數
private static final int MAX_TOTAL = 400;//最大連接數
private static final int MIN_IDLE = 200;//最小空閑數
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;//最大嘗試次數
private static final int MAX_IDLE = 200;//最大空閑數
private static final int MAX_TOTAL = 400;//最大連接數
private static final int MIN_IDLE = 200;//最小空閑數
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、定時刪除
- 含義:在設置key的過期時間的同時,為該key創建一個定時器,讓定時器在key的過期時間來臨時,對key進行刪除
- 優點:保證內存被盡快釋放
- 缺點:1)若過期key很多,刪除這些key會占用很多的CPU時間,在CPU時間緊張的情況下,CPU不能把所有的時間用來做要緊的事兒,還需要去花時間刪除這些key;2)定時器的創建耗時,若為每一個設置過期時間的key創建一個定時器(將會有大量的定時器產生),性能影響嚴重
2、懶漢式刪除
- 含義:key過期的時候不刪除,每次通過key獲取值的時候去檢查是否過期,若過期,則刪除,返回null。
- 優點:刪除操作只發生在通過key取值的時候發生,而且只刪除當前key,所以對CPU時間的占用是比較少的,而且此時的刪除是已經到了非做不可的地步(如果此時還不刪除的話,我們就會獲取到了已經過期的key了
- 缺點:若大量的key在超出超時時間后,很久一段時間內,都沒有被獲取過,那么可能發生內存泄露(無用的垃圾占用了大量的內存)
3、定期刪除
含義:每隔一段時間執行一次刪除過期key操作
優點:
1)通過限制刪除操作的時長和頻率,來減少刪除操作對CPU時間的占用--處理"定時刪除"的缺點;
2)定期刪除過期key--處理"懶漢式刪除"的缺點
缺點:
1)在內存友好方面,不如"定時刪除"(會造成一定的內存占用,但是沒有懶漢式那么占用內存);
2)在CPU時間友好方面,不如"懶漢式刪除"(會定期的去進行比較和刪除操作,cpu方面不如懶漢式,但是比定時好)
難點:
1)合理設置刪除操作的執行時長(每次刪除執行多長時間)和執行頻率(每隔多長時間做一次刪除)(這個要根據服務器運行情況來定了),每次執行時間太長,或者執行頻率太高對cpu都是一種壓力;
2) 每次進行定期刪除操作執行之后,需要記錄遍歷循環到了哪個標志位,以便下一次定期時間來時,從上次位置開始進行循環遍歷
memcached只是用了惰性刪除,而redis同時使用了惰性刪除與定期刪除,這也是二者的一個不同點(可以看做是redis優于memcached的一點);
五、Redis 使用過程中踩過的坑
1、在生產環境中一定要配置GenericObjectPoolConfig中的 maxIdle、maxTotal、minIdle.因為里面默認值太低了,如果生產環境中流量比較大的話,就會出現等待redis的連接的情況。
2、使用Redis Sentinel 一定要在最后執行jedis.close方法來釋放資源,這個close方法是表示將正常的連接放回去連接池中,將不正常的連接給關閉。之前jedis低版本中都是調用returnResource方法來釋放資源,如果連接不正常了會被重復使用,這時會出現很詭異的異常。所以建議使用比較高版本的jedis
3、為了更好的使用redis 連接池,建議采用 JedisPoolConfig來替代GenericObjectPoolConfig。JedisPoolConfig里面有一些默認的參數
4、maxIdle,maxTotal 最佳實踐為 maxIdle = maxTotal
到此這篇關于淺析Redis Sentinel 與 Redis Cluster的文章就介紹到這了,更多相關Redis Sentinel與Redis Cluster內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家!
您可能感興趣的文章:- Sentinel Dashboard限流規則保存方式
- Java之springcloud Sentinel案例講解
- Spring Cloud Alibaba之Sentinel實現熔斷限流功能
- Sentinel熔斷規則原理示例詳解分析