学习日志day65（2021-11-04）（1、Redis事务：秒杀案例 2、Redis持久化之RDB 3、Redis持久化之AOF 4、Redis主从复制）

最新推荐文章于 2024-08-15 07:00:00 发布

huzige_

最新推荐文章于 2024-08-15 07:00:00 发布

阅读量280

点赞数

分类专栏：学习日志文章标签： redis

本文链接：https://blog.csdn.net/huzige_/article/details/121138274

版权

学习日志专栏收录该内容

73 篇文章 2 订阅

订阅专栏

学习内容：学习Redis（Day65）

1、Redis事务：秒杀案例
2、Redis持久化之RDB
3、Redis持久化之AOF
4、Redis主从复制

1、Redis事务：秒杀案例

（1）使用工具ab模拟测试，CentOS6 默认安装，CentOS7需要手动安装。
联网：yum install httpd-tools

vim postfile 模拟表单提交参数,以&符号结尾;存放当前目录。内容：prodid=0101&
使用命令进行高并发提交测试

ab -n 2000 -c 200 -k -p ~/postfile -T application/x-www-form-urlencoded http://192.168.7.5:8081/Seckill/doseckill

（2）通过连接池得到jedis对象
节省每次连接redis服务带来的消耗，把连接好的实例反复利用。
//通过连接池得到jedis对象

JedisPool jedisPoolInstance = JedisPoolUtil.getJedisPoolInstance();
Jedis jedis = jedisPoolInstance.getResource();

通过参数管理连接的行为：
连接池参数
MaxTotal：控制一个pool可分配多少个jedis实例，通过pool.getResource()来获取；如果赋值为-1，则表示不限制；如果pool已经分配了MaxTotal个jedis实例，则此时pool的状态为exhausted。
maxIdle：控制一个pool最多有多少个状态为idle(空闲)的jedis实例；
MaxWaitMillis：表示当borrow一个jedis实例时，最大的等待毫秒数，如果超过等待时间，则直接抛JedisConnectionException；
testOnBorrow：获得一个jedis实例的时候是否检查连接可用性（ping()）；如果为true，则得到的jedis实例均是可用的；

public static JedisPool getJedisPoolInstance() {
   if (null == jedisPool) {
      synchronized (JedisPoolUtil.class) {
         if (null == jedisPool) {
            JedisPoolConfig poolConfig = new JedisPoolConfig();
            poolConfig.setMaxTotal(200);
            poolConfig.setMaxIdle(32);
            poolConfig.setMaxWaitMillis(100*1000);
            poolConfig.setBlockWhenExhausted(true);
            poolConfig.setTestOnBorrow(true);  // ping  PONG
          
            jedisPool = new JedisPool(poolConfig, "192.168.7.5", 6379, 60000 );
         }
      }
   }
   return jedisPool;
}

（3）解决库存遗留问题，库存在秒杀后可能会成为负数
LUA脚本：Lua 是一个小巧的脚本语言，Lua脚本可以很容易的被C/C++ 代码调用，也可以反过来调用C/C++的函数，Lua并没有提供强大的库，一个完整的Lua解释器不过200k，所以Lua不适合作为开发独立应用程序的语言，而是作为嵌入式脚本语言。
很多应用程序、游戏使用LUA作为自己的嵌入式脚本语言，以此来实现可配置性、可扩展性。

将复杂的或者多步的redis操作，写为一个脚本，一次提交给redis执行，减少反复连接redis的次数。提升性能。LUA脚本是类似redis事务，有一定的原子性，不会被其他命令插队，可以完成一些redis事务性的操作。但是注意redis的lua脚本功能，只有在Redis2.6以上的版本才可以使用。

利用lua脚本淘汰用户，解决超卖问题。redis 2.6版本以后，通过lua脚本解决争抢问题，实际上是redis利用其单线程的特性，用任务队列的方式解决多任务并发问题。

static String secKillScript ="local userid=KEYS[1];\r\n" + 
      "local prodid=KEYS[2];\r\n" + 
      "local qtkey='sk:'..prodid..\":qt\";\r\n" + 
      "local usersKey='sk:'..prodid..\":usr\";\r\n" + 
      "local userExists=redis.call(\"sismember\",usersKey,userid);\r\n" + 
      "if tonumber(userExists)==1 then \r\n" + 
      "   return 2;\r\n" + 
      "end\r\n" + 
      "local num= redis.call(\"get\" ,qtkey);\r\n" + 
      "if tonumber(num)<=0 then \r\n" + 
      "   return 0;\r\n" + 
      "else \r\n" + 
      "   redis.call(\"decr\",qtkey);\r\n" + 
      "   redis.call(\"sadd\",usersKey,userid);\r\n" + 
      "end\r\n" + 
      "return 1" ;

2、Redis持久化之RDB

（1）Redis 提供了2个不同形式的持久化方式，RDB和AOF。
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

在这里插入图片描述

（2）在redis.conf中配置临时文件名称，默认为dump.rdb，rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下。
命令save和bgsave：
save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
bgsave：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
可以通过lastsave 命令获取最后一次成功执行快照的时间。

（3）rdb的备份
先通过config get dir 查询rdb文件的目录，将*.rdb的文件拷贝到别的地方
rdb的恢复
关闭Redis，先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb，启动Redis, 备份数据会直接加载。

（4）rdb的优势：
1.适合大规模的数据恢复
2.对数据完整性和一致性要求不高更适合使用
3.节省磁盘空间
4.恢复速度快

rdb的劣势：
1.Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
2.虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
3.在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

（5）动态停止RDB：redis-cli config set save ""#save后给空值，表示禁用保存策略

3、Redis持久化之AOF

（1）以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作.

AOF持久化流程
1.客户端的请求写命令会被append追加到AOF缓冲区内；
2.AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
3.AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
4.Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

在这里插入图片描述

（2）AOF默认不开启，可以在redis.conf中配置文件名称，默认为 appendonly.aof。
AOF文件的保存路径，同RDB的路径一致。
AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复：
修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
恢复：重启redis然后重新加载
异常恢复：
修改默认的appendonly no，改为yes
如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
备份被写坏的AOF文件
恢复：重启redis，然后重新加载

（3）AOF同步频率设置
appendfsync always始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好
appendfsync everysec每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
appendfsync noredis不主动进行同步，把同步时机交给操作系统。

（4）AOF的优势：
1.备份机制更稳健，丢失数据概率更低。
2.可读的日志文本，通过操作AOF稳健，可以处理误操作。
AOF的劣势：
1.比起RDB占用更多的磁盘空间。
2.恢复备份速度要慢。
3.每次读写都同步的话，有一定的性能压力。
4.存在个别Bug，造成恢复不能。

（5）RDB和AOF
官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。

4、Redis主从复制

（1）主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。主从分离的好处：读写分离，性能扩展；容灾快速恢复。

（2）在/myredis路径下新建redis6379.conf，填写以下内容：

include /myredis/redis.conf
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

新建redis6380.conf和redis6381.conf，将redis6379.conf中的复制给这两个文件，并分别把6379改为6380和6381。
添加slave-priority 10可以设置从机的优先级，值越小，优先级越高，用于选举主机时使用。默认100。

启动三台redis服务器

redis-server /myredis/redis6379.conf
redis-server /myredis/redis6380.conf
redis-server /myredis/redis6381.conf

单独进入每台redis使用命令info replication查看三台服务器的主从复制的相关信息，在6380和6381上执行: slaveof 127.0.0.1 6379

在主机上写，在从机上可以读取数据，在从机上写数据会报错。主机挂掉，重启就行，一切如初。从机重启需重设：slaveof 127.0.0.1 6379

用 slaveof no one 可以将从机变为主机。

（3）复制原理
Slave启动成功连接到master后会发送一个sync命令。
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步。
但是只要是重新连接master,一次完全同步（全量复制）将被自动执行。

（4）哨兵模式：反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
调整为一主二仆模式，6379带着6380、6381，自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错。
配置哨兵，填写内容sentinel monitor mymaster 127.0.0.1 6379 1，其中mymaster为监控对象起的服务器名称，这里使用的是本机， 1 为至少有多少个哨兵同意迁移的数量。
回到/usr/local/bin目录，执行redis-sentinel /myredis/sentinel.conf ，当主机挂掉，从机选举中产生新的主机。大概10秒左右可以看到哨兵窗口日志，切换了新的主机。
选举主机是根据优先级别：slave-priority，原主机重启后会变为从机。
由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟。

（5）java开启哨兵模式

private static JedisSentinelPool jedisSentinelPool=null;
public static  Jedis getJedisFromSentinel(){
    if(jedisSentinelPool==null){
        Set<String>
        sentinelSet=new HashSet<>();
        sentinelSet.add("192.168.241.200:26379");
        JedisPoolConfig
        jedisPoolConfig =new JedisPoolConfig();
        jedisPoolConfig.setMaxTotal(10); //最大可用连接数
        jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
        jedisPoolConfig.setMinIdle(5); //最小闲置连接数
        jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
        jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
        jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong
        jedisSentinelPool=new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
        return jedisSentinelPool.getResource();
    }else{
        return jedisSentinelPool.getResource();
    }
}