Redis 主从架构
集群架构图
集群搭建(主从架构的搭建,配置从节点步骤)
- 复制一份redis.conf 文件
# 开始修改配置
port 6380
pidfile /var/run/redis_6380.pid # 把pid进程号写入pidfile配置的文件
logfile "6380.log"
dir /usr/local/redis-5.0.3/data/6380 # 指定数据存放目录
# 需要注释掉bind# bind 127.0.0.1(bind绑定的是自己机器网卡的ip,如果有多块网卡可以配多个ip,代表允许客户端通过机器的哪些网卡ip去访问,内网一般可以不配置bind,注释掉即可)
3、配置主从复制
replicaof 192.168.0.60 6379 # 从本机6379的redis实例复制数据,Redis 5.0之前使用slaveof
replica-read-only yes # 配置从节点只读
4、启动从节点redis-server redis.conf # redis.conf文件务必用你复制并修改了之后的redis.conf文件
5、连接从节点redis-cli -p 6380
6、测试在6379实例上写数据,6380实例是否能及时同步新修改数据
7、可以自己再配置一个6381的从节点
工作原理
如果你为Master 节点配置了一个Slave 节点,不管这个节点是否是第一次连接到Master,他都会发送一个PSYNC 命令给Master 节点,请求复制数据.
在Master 节点收到PSYNC 的命令后,会在后台通过bgsave 生成最新的rdb 文件,而且在持久化期间,Master 节点会继续接受客户端的请求,他会把这些可能修改数据集的请求存放在内存中,当持久化完成后,Master会把这份rdb文件数据 发送给slave ,slave 会把接收到数据进行持久化生成的rdb,然后在加载到内存中.然后,master再将之前缓存在内存中的命令发送给slave.
当Master 与slave 之间的链路由于某些原因而断开时,slave 能够自动重连Master,如果Master 收到多个slave请求,它只会进行一次持久化,而不是一个连接一次,然后再把这一份持久化发送给多个并发链接的slave.
主从复制(全量复制)流程图
数据部分复制
当Master共和slave 断开重连后,一般都会对整个数据进行复制,但是从Redis 2.8版本之后,redis 改用可以支持部分数据复制的命令PSYNC 去Master同步数据,slave和Master 能够在网络断开重连后只进行部分数据复制(断点续传)
Master 会在其内存中创建一个辅助数据用的缓存队列,缓存最近一段时间的数据,Master 和它所有的slave 都维护了复制的数据下标offset和Master的进程ID,因此当网络连接断开后,slave 会请求Master 继续进行未完成的复制,从所记录的下标开始.如果Master进程ID 变化了,或者从节点的数据下标太旧,已经不再Master的缓存队列理论,那么将会进行一次全量数据的复制.
如图所示
如果有很多从节点,为了缓存主从复制风暴(多个节点同时复制主节点导致主节点压力过大),可以做如下架构,让部分从节点与从节点(与主节点同步数据)同步数据
如下图
下面是使用Jedis 连接Redis 数据的示例代码
- 添加Maven 依赖
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
- 添加访问代码
public class JedisSingleTest {
public static void main(String[] args) throws IOException {
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(20);
jedisPoolConfig.setMaxIdle(10);
jedisPoolConfig.setMinIdle(5);
// timeout,这里既是连接超时又是读写超时,从Jedis 2.8开始有区分connectionTimeout和soTimeout的构造函数
JedisPool jedisPool = new JedisPool(jedisPoolConfig, "192.168.0.60", 6379, 3000, null);
Jedis jedis = null;
try { //从redis连接池里拿出一个连接执行命令
jedis = jedisPool.getResource();
System.out.println(jedis.set("single", "zhuge"));
System.out.println(jedis.get("single"));
//管道示例
//管道的命令执行方式:cat redis.txt | redis-cli -h 127.0.0.1 -a password - p 6379 --pipe
/*Pipeline pl = jedis.pipelined();
for (int i = 0; i < 10; i++) {
pl.incr("pipelineKey");
pl.set("zhuge" + i, "zhuge");
}
List<Object> results = pl.syncAndReturnAll();
System.out.println(results);*/
//lua脚本模拟一个商品减库存的原子操作
//lua脚本命令执行方式:redis-cli --eval /tmp/test.lua , 10
/*jedis.set("product_count_10016", "15"); //初始化商品10016的库存
String script = " local count = redis.call('get', KEYS[1]) " +
" local a = tonumber(count) " +
" local b = tonumber(ARGV[1]) " +
" if a >= b then " +
" redis.call('set', KEYS[1], a-b) " +
" return 1 " +
" end " +
" return 0 ";
Object obj = jedis.eval(script, Arrays.asList("product_count_10016"), Arrays.asList("10"));
System.out.println(obj);*/
} catch (Exception e) {
e.printStackTrace();
} finally {
//注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
if (jedis != null)
jedis.close();
}
}
}
什么是管道(Pipline)
客户端可以一次性发送多个请求而不用等待服务器的响应,待所有命令都发送完成在一次性读取服务器的响应.这样可以极大的降低多条命令执行的网络传输开销.管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销.需要注意的是用Pipline 方式打包命令发送.redis 必须在处理完所有命令前先缓存起来所有命令的处理结果,打包的命令越多,缓存消耗的内存也就越多,所以并不是打包命令越多越好.
Pipline 中发送的每一个命令都会被server执行,如果执行失败,将会在此后的响应中得到信息,也就是Pipline 并不是表达 "所有command 都一起成功"的语义.管道中的前面命令失败,越后面命令不会有影响接续执行.
下面是示例代码
Pipeline pl = jedis.pipelined();
for (int i = 0; i < 10; i++) {
pl.incr("pipelineKey");
pl.set("zhuge" + i, "zhuge");
//模拟管道报错
// pl.setbit("zhuge", -1, true);
}
List<Object> results = pl.syncAndReturnAll();
System.out.println(results);
Redis Lua脚本
Redis 2.6之后推出了脚本功能,允许开发者使用Lua 语言编写脚本传到Redis 中执行,使用脚本可以由一下好处:
- 减少网络开销:本来多次的网络请求操作,可以用一个请求来完成.使用脚本,减少了网络的往返延迟,这点和管道比较类似
- 原子操作:Redis 会将整个脚本作为一个整体,中间不会被其他命令插入.管道他不是原子性的,不过Redis 的批量操作命令是原子的
- 替代Redis 的事务功能:Redis 自带的事务功能很鸡肋,而Redis 的Lua 脚本几乎实现了常规的事务功能,官方推荐如果要使用Redis的事务功能可以用Redis Lua 代替.
特别注意
不要在Lua 脚本中出现死循环和耗时的运算,否则Redis 会阻塞,将不接受其他命令,所以在使用时要注意不能出现死循环,好事匀速.Redis 是单进程的,单线程执行脚本,管道不会阻塞Redis
Redis 哨兵高可用架构
下图为Redis 哨兵架构的示意图
sentinel 哨兵他是特殊的Redis服务,因为它不提供读写服务,主要用来监控Redis的其他实例节点.
哨兵架构下Client 第一从哨兵找出Redis的主节点,后续就直接访问Redis的主节点,不会每次都通过sentinel代理访问Redis的主节点,当Redis的主节点发送变化,哨兵会第一时间感知,并且将新的Redis 主节点通知给Client端,(这里面Redis的Client端一般都实现了订阅功能,订阅Sentinel 发布的节点变动消息.)
下面是搭建哨兵架构的具体步骤
1、复制一份sentinel.conf文件
cp sentinel.conf sentinel-26379.conf
2、将相关配置修改为如下值:
port 26379daemonize yespidfile "/var/run/redis-sentinel-26379.pid"
logfile "26379.log"
dir "/usr/local/redis-5.0.3/data"
# sentinel monitor <master-redis-name> <master-redis-ip> <master-redis-port> <quorum>
# quorum是一个数字,指明当有多少个sentinel认为一个master失效时(值一般为:sentinel总数/2 + 1),master才算真正失效
sentinel monitor mymaster 192.168.0.60 6379 2 # mymaster这个名字随便取,客户端访问时会用到
3、启动sentinel哨兵实例
src/redis-sentinel sentinel-26379.conf
4、查看sentinel的info信息
src/redis-cli -p 26379
127.0.0.1:26379>info
可以看到Sentinel的info里已经识别出了redis的主从
5、可以自己再配置两个sentinel,端口26380和26381,注意上述配置文件里的对应数字都要修改
sentinel集群都启动完毕后,会将哨兵集群的元数据信息写入所有sentinel的配置文件里去(追加在文件的最下面),我们查看下如下配置文件sentinel-26379.conf,如下所示:
sentinel known-replica mymaster 192.168.0.60 6380 #代表redis主节点的从节点信息
sentinel known-replica mymaster 192.168.0.60 6381 #代表redis主节点的从节点信息
sentinel known-sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵节点
当redis主节点如果挂了,哨兵集群会重新选举出新的redis主节点,同时会修改所有sentinel节点配置文件的集群元数据信息,比如6379的redis如果挂了,假设选举出的新主节点是6380,则sentinel文件里的集群元数据信息会变成如下所示:
sentinel known-replica mymaster 192.168.0.60 6379 #代表主节点的从节点信息
sentinel known-replica mymaster 192.168.0.60 6381 #代表主节点的从节点信息
sentinel known-sentinel mymaster 192.168.0.60 26380 52d0a5d70c1f90475b4fc03b6ce7c3c56935760f #代表感知到的其它哨兵节点
sentinel known-sentinel mymaster 192.168.0.60 26381 e9f530d3882f8043f76ebb8e1686438ba8bd5ca6 #代表感知到的其它哨兵节点
同时还会修改sentinel文件里之前配置的mymaster对应的6379端口,改为6380
sentinel monitor mymaster 192.168.0.60 6380 2
当6379的redis实例再次启动时,哨兵集群根据集群元数据信息就可以将6379端口的redis节点作为从节点加入集群
哨兵模式下的Jedis 代码示例
public class JedisSentinelTest {
public static void main(String[] args) throws IOException {
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(20);
config.setMaxIdle(10);
config.setMinIdle(5);
String masterName = "mymaster";
Set<String> sentinels = new HashSet<String>();
sentinels.add(new HostAndPort("192.168.0.60",26379).toString());
sentinels.add(new HostAndPort("192.168.0.60",26380).toString());
sentinels.add(new HostAndPort("192.168.0.60",26381).toString());
//JedisSentinelPool其实本质跟JedisPool类似,都是与redis主节点建立的连接池
//JedisSentinelPool并不是说与sentinel建立的连接池,而是通过sentinel发现redis主节点并与其建立连接
JedisSentinelPool jedisSentinelPool = new JedisSentinelPool(masterName, sentinels, config, 3000, null);
Jedis jedis = null;
try {
jedis = jedisSentinelPool.getResource();
System.out.println(jedis.set("sentinel", "zhuge"));
System.out.println(jedis.get("sentinel"));
} catch (Exception e) {
e.printStackTrace();
} finally {
//注意这里不是关闭连接,在JedisPool模式下,Jedis会被归还给资源池。
if (jedis != null)
jedis.close();
}
}
}
哨兵的Spring Boot整合Redis连接代码
- 引入相关依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-pool2</artifactId>
</dependency>
- Springboot 配置文件
server:
port: 8080
spring:
redis:
database: 0
timeout: 3000
sentinel: #哨兵模式
master: mymaster #主服务器所在集群名称
nodes: 192.168.0.60:26379,192.168.0.60:26380,192.168.0.60:26381
lettuce:
pool:
max-idle: 50
min-idle: 10
max-active: 100
max-wait: 1000
- 访问代码
@RestController
public class IndexController {
private static final Logger logger = LoggerFactory.getLogger(IndexController.class);
@Autowired
private StringRedisTemplate stringRedisTemplate;
/**
* 测试节点挂了哨兵重新选举新的master节点,客户端是否能动态感知到
* 新的master选举出来后,哨兵会把消息发布出去,客户端实际上是实现了一个消息监听机制,
* 当哨兵把新master的消息发布出去,客户端会立马感知到新master的信息,从而动态切换访问的masterip
*
* @throws InterruptedException
*/
@RequestMapping("/test_sentinel")
public void testSentinel() throws InterruptedException {
int i = 1;
while (true){
try {
stringRedisTemplate.opsForValue().set("zhuge"+i, i+"");
System.out.println("设置key:"+ "zhuge" + i);
i++;
Thread.sleep(1000);
}catch (Exception e){
logger.error("错误:", e);
}
}
}
}
- StringRedisTemplate与RedisTemplate详解
spring 封装了 RedisTemplate 对象来进行对redis的各种操作,它支持所有的 redis 原生的 api。在RedisTemplate中提供了几个常用的接口方法的使用,分别是:
private ValueOperations<K, V> valueOps;
private HashOperations<K, V> hashOps;
private ListOperations<K, V> listOps;
private SetOperations<K, V> setOps;
private ZSetOperations<K, V> zSetOps;
RedisTemplate中定义了对5种数据结构操作
redisTemplate.opsForValue();//操作字符串
redisTemplate.opsForHash();//操作hash
redisTemplate.opsForList();//操作list
redisTemplate.opsForSet();//操作set
redisTemplate.opsForZSet();//操作有序set
StringRedisTemplate继承自RedisTemplate,也一样拥有上面这些操作。
StringRedisTemplate默认采用的是String的序列化策略,保存的key和value都是采用此策略序列化保存的。
RedisTemplate默认采用的是JDK的序列化策略,保存的key和value都是采用此策略序列化保存的。