zoukankan      html  css  js  c++  java
  • Redis(三)Redis的高性能和持久化

    一、Redis的单线程问题

    Redis是单线程吗?

      Redis 的单线程主要是指 Redis 的网络 IO 和键值对读写是由一个线程来完成的,这也是 Redis 对外 提供键值存储服务的主要流程。

      但 Redis 的其他功能,比如持久化、异步删除、集群数据同步等,其实是由额外的线程执行的

      小结:命令是单线程执行,其他功能不是单线程的。

    Redis 单线程为什么还能这么快?

      因为它所有的数据都在内存中,所有的运算都是内存级别的运算,而且单线程避免了多线程的切换性能损耗问题

      PS:正因为 Redis 是单线程,所以要小心使用 Redis 指令,对于那些耗时的指令(比如 keys),一定要谨慎使用,一不小心就可能会导致 Redis 卡顿。

    二、Redis的高性能问题

      redis在执行命令的时候是单线程操作的,那么大并发场景redis是怎么保证高性能的呢:

    Redis 单线程如何处理那么多的并发客户端连接?

      Redis的IO多路复用:redis利用epoll来实现IO多路复用,将连接信息和事件放到队列中,依次放到文件事件分派器,事件分派器将事件分发给事件处理器。

    三、Redis持久化

    RDB快照方式(snapshot)

      默认情况下,Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

      我们可以在配置文件redis.conf下设置如下值,来设置dump.rdb保存的策略:

    //60秒内有1000个key被改动时,后台起一个进程来保存rdb文件
    save 60 1000
    
    //PS:可以保存多个策略,如:
    save 60 1000
    save 30 600
    save 10 200
    
    //PS:也可以链接上客户端后,使用命令savebgsave可以生成新的dump.rdb文件,并覆盖原有的

       PS:dump.rdb文件默认是生成在启动目录下的。

    save与bgsave对比

    bgsave的写时复制(COW)机制

      Redis借助操作系统提供的写时复制技术【Copy-On-Write, COW】,在生成快照的同时,依然可以正常处理写命令

      bgsave子进程是由主线程fork【派生】生成的,可以共享主线程的所有内存数据

      执行流程:

      PS:后台默认自动生成rdb文件使用的方式是bgsave

    AOF方式(append-only file)

      出现背景:rdb功能并不是非常耐久,如果 Redis 因为某些原因而造成故障停机, 那么服务器将丢失最近写入且仍未保存到快照中的那些数据。

      方式:修改的每一条指令记录进文件appendonly.aof中【先写入操作系统缓存(os cache),每隔一段时间异步写入(fsync)到磁盘

      开启方式:

    //配置文件内加入
    appendonly yes

      执行原理:每当 Redis 执行一个改变数据集的命令时(比如 SET), 这个命令就会被追加到AOF文件的末尾。 这样的话,当Redis重新启动时, 程序就可以通过重新执行AOF文件中的命令来重建数据。

      同步间隔配置:

    appendfsync always  //每次有新命令追加到 AOF 文件时就执行一次 fsync ,非常慢,也非常安全。 
    appendfsync everysec  //每秒 fsync 一次,足够快,并且在故障时只会丢失 1 秒钟的数据。 
    appendfsync no  //从不 fsync ,将数据交给操作系统来处理。更快,也更不安全的选择。

    //PS:也可以链接上客户端后,使用命令bgrewriteaof可以重写AOF

    AOF重写

      定义:AOF会定期根据内存的最新数据生成aof文件【把一些冗余的旧命令合并或者优化

      配置OF自动重写频率:

    auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写,文件太小恢复速度本来就 很快,重写的意义不大 
    auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写

      PS:AOF重写redis会fork出一个子进程去做(与bgsave命令类似),不会对redis正常命令处理有太多影响。

       PS:可以都启用,不过redis启动时如果既有rdb文件又有aof文件则优先选择aof文件恢复数据,因为aof一般来说数据更全一点。

    混合持久化方式

      我们从上面的图可以看到redis的两种持久化方式各有优劣,那么我们可不可以选取一个折中的方案呢?混合持久化就是为了对这两种持久化方式择其优点:

    appendonly yes  //必须先开启aof才可以混合持久化
    aof‐use‐rdb‐preamble yes  //开启混合持久化

      混合持久化的备份文件生成步骤:

    • 1、AOF开始重写,把这一刻之前存的命令行做RDB快照处理。【AOF->RDB】
    • 2、增量的修改内存数据命令存放为AOF命令行的形式,与第一步的内容一起写入一个新的AOF文件。
    • 3、第1、2步骤执行完毕后,新的aof文件改名为appendonly.aof,并覆盖原来的aof文件。

      效率提升原理:redis重启时默认加载AOF文件进行恢复,AOF命令执行起来相对会慢。而开启了混合持久化以后,AOF前面的内容是以快照形式保存的,执行起来就相对快了很多了。

      混合持久化AOF的文件结构:

    四、Redis持久化策略

    • 1. 写定时调度脚本,每小时都copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48小时的备份。
    • 2. 每天都保留一份当日的数据,并备份到一个目录中去,可以保留最近1个月的备份。
    • 3. 每次copy备份的时候,都把太旧的备份给删了。
    • 4. 每天晚上将当前机器上的备份复制一份到其他机器上,以防机器损坏。

     

  • 相关阅读:
    JavaSE第十五天20160823
    JavaSE第十四天20160822
    JavaSE第十三天20160819
    pojo和javabean的比较
    JavaSE第十二天20160818
    JavaSE第十一天20160817
    修正MyEclipse的SpellChecking
    JavaSE第十天20160816
    JavaSE第九天20160815
    Servlet中的init()方法如何才会在服务器启动时执行
  • 原文地址:https://www.cnblogs.com/riches/p/15059509.html
Copyright © 2011-2022 走看看