福州市做公司网站哪家好,wordpress访问量插件,网站建设功能最全的软件,建设个人网站流程Redis持久化 RDB快照#xff08;snapshot#xff09;
在默认情况下#xff0c; Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
你可以对 Redis 进行设置#xff0c; 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时#xff0c; 自动保存一次数…Redis持久化 RDB快照snapshot
在默认情况下 Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。
你可以对 Redis 进行设置 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时 自动保存一次数据集。
比如说 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时 自动保存一次数据集
# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可
还可以手动执行命令生成RDB快照进入redis客户端执行命令save或bgsave可以生成dump.rdb文件每次命令执行都会将所有redis内存快照到一个新的rdb文件里并覆盖原有rdb快照文件。
bgsave的写时复制(COW)机制
Redis 借助操作系统提供的写时复制技术Copy-On-Write, COW在生成快照的同时依然可以正常处理写命令。简单来说bgsave 子进程是由主线程 fork 生成的可以共享主线程的所有内存数据。bgsave 子进程运行后开始读取主线程的内存数据并把它们写入 RDB 文件。此时如果主线程对这些数据也都是读操作那么主线程和 bgsave 子进程相互不影响。但是如果主线程要修改一块数据那么这块数据就会被复制一份生成该数据的副本。然后bgsave 子进程会把这个副本数据写入 RDB 文件而在这个过程中主线程仍然可以直接修改原来的数据。
save与bgsave对比 命令 save bgsave IO类型 同步 异步 是否阻塞redis其它命令 是 否(在生成子进程执行调用fork函数时会有短暂阻塞) 复杂度 O(n) O(n) 优点 不会消耗额外内存 不阻塞客户端命令 缺点 阻塞客户端命令 需要fork子进程消耗内存
配置自动生成rdb文件后台使用的是bgsave方式。
AOFappend-only file
快照功能并不是非常耐久durable 如果 Redis 因为某些原因而造成故障停机 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。从 1.1 版本开始 Redis 增加了一种完全耐久的持久化方式 AOF 持久化将修改的每一条指令记录进文件appendonly.aof中(先写入os cache每隔一段时间fsync到磁盘)
比如执行命令“set hangzhou666”aof文件里会记录如下数据
*3
$3
set
$5
hangzhou
$3
666
这是一种resp协议格式数据星号后面的数字代表命令有多少个参数$号后面的数字代表这个参数有几个字符
注意如果执行带过期时间的set命令aof文件里记录的是并不是执行的原始命令而是记录key过期的时间戳
比如执行“set hangzhou 888 ex 1000”对应aof文件里记录如下
*3
$3
set
$6
hangzhou
$3
888
*3
$9
PEXPIREAT
$6
hangzhou
$13
1604249786301
你可以通过修改配置文件来打开 AOF 功能
# appendonly yes
从现在开始 每当 Redis 执行一个改变数据集的命令时比如 SET 这个命令就会被追加到 AOF 文件的末尾。
这样的话 当 Redis 重新启动时 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。
你可以配置 Redis 多久才将数据 fsync 到磁盘一次。
有三个选项
appendfsync always每次有新命令追加到 AOF 文件时就执行一次 fsync 非常慢也非常安全。
appendfsync everysec每秒 fsync 一次足够快并且在故障时只会丢失 1 秒钟的数据。
appendfsync no从不 fsync 将数据交给操作系统来处理。更快也更不安全的选择。
推荐并且也是默认的措施为每秒 fsync 一次 这种 fsync 策略可以兼顾速度和安全性。
AOF重写
AOF文件里可能有太多没用指令所以AOF会定期根据内存的最新数据生成aof文件
例如执行了如下几条命令
127.0.0.1:6379 incr readcount
(integer) 1
127.0.0.1:6379 incr readcount
(integer) 2
127.0.0.1:6379 incr readcount
(integer) 3
127.0.0.1:6379 incr readcount
(integer) 4
127.0.0.1:6379 incr readcount
(integer) 5
重写后AOF文件里变成
*3
$3
SET
$2
readcount
$1
5
如下两个配置可以控制AOF自动重写频率
# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写文件太小恢复速度本来就很快重写的意义不大# auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写
当然AOF还可以手动重写进入redis客户端执行命令bgrewriteaof重写AOF
注意AOF重写redis会fork出一个子进程去做(与bgsave命令类似)不会对redis正常命令处理有太多影响
RDB 和 AOF 我应该用哪一个 命令 RDB AOF 启动优先级 低 高 体积 小 大 恢复速度 快 慢 数据安全性 容易丢数据 根据策略决定
生产环境可以都启用redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据因为aof一般来说数据更全一点。
Redis 4.0 混合持久化 重启 Redis 时我们很少使用 RDB来恢复内存状态因为会丢失大量数据。我们通常使用 AOF 日志重放但是重放 AOF 日志性能相对 RDB来说要慢很多这样在 Redis 实例很大的情况下启动需要花费很长的时间。 Redis 4.0 为了解决这个问题带来了一个新的持久化选项——混合持久化。
通过如下配置可以开启混合持久化(必须先开启aof)
# aof-use-rdb-preamble yes 如果开启了混合持久化AOF在重写时不再是单纯将内存数据转换为RESP命令写入AOF文件而是将重写这一刻之前的内存做RDB快照处理并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起都写入新的AOF文件新的文件一开始不叫appendonly.aof等到重写完新的AOF文件才会进行改名覆盖原有的AOF文件完成新旧两个AOF文件的替换。 于是在 Redis 重启的时候可以先加载 RDB 的内容然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放因此重启效率大幅得到提升。
混合持久化AOF文件结构如下 Redis数据备份策略
写crontab定时调度脚本每小时都copy一份rdb或aof的备份到一个目录中去仅仅保留最近48小时的备份每天都保留一份当日的数据备份到一个目录中去可以保留最近1个月的备份每次copy备份的时候都把太旧的备份给删了每天晚上将当前机器上的备份复制一份到其他机器上以防机器损坏
Redis主从架构 redis主从架构搭建配置从节点步骤
1、复制一份redis.conf文件2、将相关配置修改为如下值
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.1bind绑定的是自己机器网卡的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 63806、测试在6379实例上写数据6380实例是否能及时同步新修改数据7、可以自己再配置一个6381的从节点
Redis主从工作原理 如果你为master配置了一个slave不管这个slave是否是第一次连接上Master它都会发送一个PSYNC命令给master请求复制数据。 master收到PSYNC命令后会在后台进行数据持久化通过bgsave生成最新的rdb快照文件持久化期间master会继续接收客户端的请求它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以后master会把这份rdb文件数据集发送给slaveslave会把接收到的数据进行持久化生成rdb然后再加载到内存中。然后master再将之前缓存在内存中的命令发送给slave。 当master与slave之间的连接由于某些原因而断开时slave能够自动重连Master如果master收到了多个slave并发连接请求它只会进行一次持久化而不是一个连接一次然后再把这一份持久化的数据发送给多个并发连接的slave。
主从复制(全量复制)流程图 数据部分复制
当master和slave断开重连后一般都会对整份数据进行复制。但从redis2.8版本开始redis改用可以支持部分数据复制的命令PSYNC去master同步数据slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。
master会在其内存中创建一个复制数据用的缓存队列缓存最近一段时间的数据master和它所有的slave都维护了复制的数据下标offset和master的进程id因此当网络连接断开后slave会请求master继续进行未完成的复制从所记录的数据下标开始。如果master进程id变化了或者从节点数据下标offset太旧已经不在master的缓存队列里了那么将会进行一次全量数据的复制。
主从复制(部分复制断点续传)流程图 如果有很多从节点为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)可以做如下架构让部分从节点与从节点(与主节点同步)同步数据 Jedis连接代码示例
1、引入相关依赖
dependencygroupIdredis.clients/groupIdartifactIdjedis/artifactIdversion2.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, hangzhou));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, hangzhou);}ListObject 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();}}
}
顺带讲下redis管道与调用lua脚本代码示例上面已经给出
管道Pipeline 客户端可以一次性发送多个请求而不用等待服务器的响应待所有命令都发送完后再一次性读取服务的响应这样可以极大的降低多条命令执行的网络传输开销管道执行多条命令的网络开销实际上只相当于一次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多缓存消耗内存也越多。所以并不是打包的命令越多越好。 pipeline中发送的每个command都会被server立即执行如果执行失败将会在此后的响应中得到信息也就是pipeline并不是表达“所有command都一起成功”的语义管道中前面命令失败后面命令不会有影响继续执行。
详细代码示例见上面jedis连接示例
Pipeline pl jedis.pipelined();
for (int i 0; i 10; i) {pl.incr(pipelineKey);pl.set(hangzhou i, zhuge);//模拟管道报错// pl.setbit(hangzhou, -1, true);
}
ListObject results pl.syncAndReturnAll();
System.out.println(results);
Redis Lua脚本(放在后面Redis高并发分布式锁实战课里详细讲)
Redis在2.6推出了脚本功能允许开发者使用Lua语言编写脚本传到Redis中执行。使用脚本的好处如下:
1、减少网络开销本来5次网络请求的操作可以用一个请求完成原先5次请求的逻辑放在redis服务器上完成。使用脚本减少了网络往返时延。这点跟管道类似。
2、原子操作Redis会将整个脚本作为一个整体执行中间不会被其他命令插入。管道不是原子的不过redis的批量操作命令(类似mset)是原子的。
3、替代redis的事务功能redis自带的事务功能很鸡肋而redis的lua脚本几乎实现了常规的事务功能官方推荐如果要使用redis的事务功能可以用redis lua替代。
官网文档上有这样一段话
A Redis script is transactional by definition, so everything you can do with a Redis transaction, you can also do with a script, and usually the script will be both simpler and faster.
从Redis2.6.0版本开始通过内置的Lua解释器可以使用EVAL命令对Lua脚本进行求值。EVAL命令的格式如下
EVAL script numkeys key [key ...] arg [arg ...]
script参数是一段Lua脚本程序它会被运行在Redis服务器上下文中这段脚本不必(也不应该)定义为一个Lua函数。numkeys参数用于指定键名参数的个数。键名参数 key [key ...] 从EVAL的第三个参数开始算起表示在脚本中所用到的那些Redis键(key)这些键名参数可以在 Lua中通过全局变量KEYS数组用1为基址的形式访问( KEYS[1] KEYS[2] 以此类推)。
在命令的最后那些不是键名参数的附加参数 arg [arg ...] 可以在Lua中通过全局变量ARGV数组访问访问的形式和KEYS变量类似( ARGV[1] 、 ARGV[2] 诸如此类)。例如
127.0.0.1:6379 eval return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]} 2 key1 key2 first second
1) key1
2) key2
3) first
4) second
其中 return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]} 是被求值的Lua脚本数字2指定了键名参数的数量 key1和key2是键名参数分别使用 KEYS[1] 和 KEYS[2] 访问而最后的 first 和 second 则是附加参数可以通过 ARGV[1] 和 ARGV[2] 访问它们。
在 Lua 脚本中可以使用redis.call()函数来执行Redis命令
Jedis调用示例详见上面jedis连接示例
jedis.set(product_stock_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_stock_10016), Arrays.asList(10));
System.out.println(obj);
注意不要在Lua脚本中出现死循环和耗时的运算否则redis会阻塞将不接受其他的命令 所以使用时要注意不能出现死循环、耗时的运算。redis是单进程、单线程执行脚本。管道不会阻塞redis。
Redis哨兵高可用架构 sentinel哨兵是特殊的redis服务不提供读写服务主要用来监控redis实例节点。
哨兵架构下client端第一次从哨兵找出redis的主节点后续就直接访问redis的主节点不会每次都通过sentinel代理访问redis的主节点当redis的主节点发生变化哨兵会第一时间感知到并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能订阅sentinel发布的节点变动消息)
redis哨兵架构搭建步骤
1、复制一份sentinel.conf文件
cp sentinel.conf sentinel-26379.conf2、将相关配置修改为如下值
port 26379
daemonize yes
pidfile /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.conf4、查看sentinel的info信息
src/redis-cli -p 26379
127.0.0.1:26379info
可以看到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;SetString sentinels new HashSetString();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连接代码见示例项目redis-sentinel-cluster
1、引入相关依赖
dependencygroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-data-redis/artifactId
/dependencydependencygroupIdorg.apache.commons/groupIdartifactIdcommons-pool2/artifactId
/dependency
springboot项目核心配置
server:port: 8080spring:redis:database: 0timeout: 3000sentinel: #哨兵模式master: mymaster #主服务器所在集群名称nodes: 192.168.0.60:26379,192.168.0.60:26380,192.168.0.60:26381lettuce:pool:max-idle: 50min-idle: 10max-active: 100max-wait: 1000
访问代码
RestController
public class IndexController {private static final Logger logger LoggerFactory.getLogger(IndexController.class);Autowiredprivate 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(zhugei, 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 ValueOperationsK, V valueOps;
private HashOperationsK, V hashOps;
private ListOperationsK, V listOps;
private SetOperationsK, V setOps;
private ZSetOperationsK, 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都是采用此策略序列化保存的。
Redis客户端命令对应的RedisTemplate中的方法列表
