缓存数据库redis经典剖析

因为redis的基本操作及多种数据结构的支持比较的简洁易懂，故在此文不作赘述，本文主要解析一下redis面试常见问题应答。

目录 
1、redis介绍 
2、redis重要说明

• 1、redis介绍

  • 1.1 redis是什么 
    • Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value内存型数据库。

  • 1.2 redis主要特点

    • 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候自动再次加载进行使用。
    • 既支持key-value类型的数据操作，还提供list，set，zset，hash等数据结构的存储。
    • 支持数据的主从备份，采用master-slave模式的主从备份。
    • 新版3.x也支持分布式布署模式，真正实现了数据块的分布式存储与响应。
    • 性能极高 – Redis能读的速度是11万次/s,写的速度是8万次/s
    • 所有操作均为原子性操作
    • 丰富的实用特性，如订阅-发布模式，生产者消费者模式，key过期等常用易用的模式。
    • 三种运行模式 
      • 单机布署
      • 主备布署
      • 分布式布署

  • 1.3 竞品组件

    • MemoryCache-kv型缓存数据库 ：单进程多线程模型
    • Apache Ignite-分布式关系型缓存数据库
    • SSDB-kv型缓存数据库

• 3、redis重要说明

  • 3.1 redis架构设计说明 
    • 单进程单线程模型的KV数据库
    • 多线程处理可能涉及到锁
    • 多线程处理会涉及到线程切换而消耗CPU
    • 无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善
  • 完全基于内存
  • 数据结构简单，对数据操作也简单
  • 使用多路 I/O 复用模型（网络io事件模型-epoll） 
    • 网络IO都是通过Socket实现，Server在某一个端口持续监听，客户端通过Socket（IP+Port）与服务器建立连接（ServerSocket.accept），成功建立连接之后，就可以使用Socket中封装的InputStream和OutputStream进行IO交互了。针对每个客户端，Server都会创建一个新线程专门用于处理
    • 默认情况下，网络IO是阻塞模式，即服务器线程在数据到来之前处于【阻塞】状态，等到数据到达，会自动唤醒服务器线程，着手进行处理。阻塞模式下，一个线程只能处理一个流的IO事件
    • 5种网络IO模型 
      • 阻塞IO、非阻塞IO、IO复用模型、信号驱动IO、异步IO模型
      • IO复用模型中包括：select模式、poll模式、epoll模式（event poll模式），其中epoll是select和poll模型的升级优化，使得一个线程可以最大限度、最高效的监听和响应更多路客户端的IO请求。

• 3.2 redis持久化重要说明

  • redis数据存储模式只有两种 
    • cache-only 
      • 只做为“缓存”服务，数据均在内存中，不持久化数据，服务停掉则数据全部丢失，且无恢复方法，高速但安全性低；
    • persistence 
      • 数据不只是在内存中，还会以配置的持久化方式持久化到磁盘中，保证服务停止后数据还可以恢复。
      • 持久化方式选择 
        • Redis DataBase(简称RDB)：默认开启该种方法持久化数据 
          • 在某个条件满足后触发持久化操作，也称为一次快照(snapshot)操作，将所有数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复的效果。
          • snapshot触发的时机，是有”间隔时间”和”变更次数”共同决定，同时符合2个条件才会触发snapshot,否则“变更次数”会被继续累加到下一个“间隔时间”上。
          • snapshot过程是启动一个独立的子进程完成，故并不阻塞客户端请求。snapshot首先将数据写入临时文件，当成功结束后，将临时文件重名为dump.rdb。
          • rdb优缺点说明 
            • 优点 
              • 文件紧凑
              • 形式简单即单rdb文件
              • 由子进程完全独立搞定对主进程无影响
              • 恢复速度快
            • 缺点 
              • 每次保存都是保存一个完整数据集的操作，持续时间可长可短，对丢失数据控制力不佳。
              • 若数据量过大，造成CPU和IO压力大，会影响主线程服务性能。
        • Append-only file (简称AOF) 
          • 将”写操作+数据”以格式化指令的方式追加到操作日志文件的尾部,”日志文件”保存了历史所有的操作过程
          • 当server需要数据恢复时，可以直接replay此日志文件，即可还原所有的操作过程。
          • 由于aof操作是发生在后台异步线程执行，可以采用no文件模式同步(交给操作系统策略同步)、每秒钟fsync同步一次、每个写入发生时fsync同步一次，默认为每秒同步一次。
          • aof也不是绝对无数据丢失的：aof是写入内存cache，由后台线程按照aof策略执行fsync，极端情况下依然会丢失相应的数据。
          • aof优缺点说明 
            • 优点 
              • 数据持久化更及时、效果更好
              • 尾部追加方式，且为后台线程执行，效果很好，亦不影响主线程服务性能。
              • 自动进行aof日志重写和替换，达到适时瘦身的效果。
              • 日志文件为文本形式，易读易维护易修复。
            • 缺点 
              • aof日志文件体积一般比rdb方式要大。
              • 在数据恢复时，aof的恢复速度一般是慢于rdb。