Redis入门教程

redis基础知识汇总.png

1、Redis简介

• Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

  
  
  

• 它通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)等类型。

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。

• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。

• Redis支持数据的备份，即master-slave模式的数据备份。

2、Redis常见的业务场景

• 定时器、计数器。
• 发布、订阅消息系统。
• 模拟类似于HttpSession这种需要设定过期时间的功能。
• 取最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面。
• 内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务。

3、Redis 优势

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
• 原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。

4、Redis与其他key-value存储有什么不同？

• Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。

• Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是，相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。

下边我们将重点介绍：

5、 RedisAPI的理解和使用。

• 字符串的存取

  

  • 字典的存取

    
    
    

  • list的存取

    
    
    
  
  

• set的存取

  
  
  
  
  
  

  • 1.Sorted-Set和Set的区别

    • sorted-set：每个成员都有一个分数与之关联，成员唯一，可以对应多个分数
    • 2.Sorted-Set中的成员在集合中的位置是有序的。

  • 存储Sorted-Set常用命令：

    • 1.添加元素：zadd
      zadd sort 10 a 20 b 30 c #a的分数是10、b的分数是20、c的分数是30
    • 2.获得元素：zscore获得分数、zcard获得成员数量
      zscore sort a #获得a的分数
    • 3.删除元素：zrem、zremrangebyrank按照排名范围删除、zremrangebyscore按照分数范围删除
      zrem sort a b #删除成员a、b
      zremrangebyrank sort 0 4 #删除排名0-4的成员
      zremrangebyscore sort 10 30 #删除分数10-30的成员
    • 4.范围查询：zrange
      zrange sort 0 -1 #所有成员
      zrange sort 0 -1 withscores #查询成员及分数，从小到大
      zrevrange sort 0 -1 withscores #从大到小
    • 5.扩展命令：
      zrangebyscore sort 0 100 withscores #显示0-100分数的成员
      zrangebyscore sort 0 100 withscores limit 0 2 #显示0-100分数的成员的前两名
      zincrby sort 10 c #给c加上10
      zcount sort 80 100 # 显示80-100分数的成员个数

  • Sorted-Set使用场景：

    • 如大型在线游戏积分排行榜
    • 构建索引数据
  

6、Redis keys的通用操作

• 1:所有键列：keys *

• 2:指定开头键列：keys [*]?

• 3:删：del 键...

• 4:判断存在：exists 键

• 5:重命名：rename 旧键名 新键名

• 6:设过期时间：expire 键 [seconds]

• 7:查过期时间：ttl 键

• 8:键的值类型：type 键

• 9:清空缓存：flushall

  

7、Redis特性

• 多数据库

• Redis事务

• Redis一个实例包含多个数据库：默认16个 。

  客户端默认连接0号数据库
  select 1 #选择1号数据库
  move name 1 #移动 name 到1号数据库

• 事务：

  • 事务是用户定义的一个数据库操作序列，这些操作要么全做要么全不做,是一个不可分割的工作单位。

  • 事务具有四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持续性（Durability）。这个四个特性也简称为ACID特性。
    　　原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。
    　　一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。
    　　隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
    提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。

  • 为什么事务非正常结束时会影响数据库数据的正确性，请列举一例说明之。
    　　答：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

  • 例如某工厂的库存管理系统中，要把数量为Q的某种零件从仓库1移到仓库2存放。则可以定义一个事务T，T包括两个操作；Q1=Q1-Q，Q2=Q2+Q。如果T非正常终止时只做了第一个操作，则数据库就处于不一致性状态，库存量无缘无故少了Q。

  • multi：开启事务

  • exec：提交，执行的命令被原子化执行

  • discard：回滚

8、 Redis的持久化

• Redis的持久化实现方式主要有两种：RDB和AOF

• 1.RDB和AOF两种持久化机制的介绍

• RDB持久化机制，对Redis中的数据执行周期性的持久化。

• AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集。

RDB和AOF的优缺点

RDB持久化机制的优点

• 1、RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备（就是停止数据库服务来作数据备份），可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据。

• 2、RDB也可以做冷备，生成多个文件，每个文件都代表了某一个时刻的完整的数据快照。AOF也可以做冷备，只有一个文件，但是你可以，每隔一定时间，去copy一份这个文件出来（实际上很少人会用AOF作冷备，因为还需要自己写一些脚本去做这个事情，各种定时，很麻烦。RDB做冷备，优势在哪儿呢？由redis去控制固定时长生成快照文件的事情，RDB数据做冷备，在最坏的情况下，提供数据恢复的时候，速度比AOF快）。

• 3、RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可。

• 4、RDB，每次写，都是直接写redis内存，只是在一定的时候，才会将数据写入磁盘中。AOF，每次都是要写文件的，虽然可以快速写入os cache中，但是还是有一定的时间开销的,速度肯定比RDB略慢一些。

• 5、相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速。

• 6、AOF，存放的指令日志，做数据恢复的时候，其实是要回放和执行所有的指令日志，来恢复出来内存中的所有数据。

• 7、RDB，就是一份数据文件（二进制），恢复的时候，直接加载到内存中即可。

• 结合上述优点，RDB特别适合做冷备份。

• RDB持久化机制的缺点

  • 1、如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。

  • 2、这个问题，也是RDB最大的缺点，就是不适合做第一优先的恢复方案，如果你依赖RDB做第一优先恢复方案，会导致数据丢失的比较多。

  • 3、RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒。

  • 4、一般不要让RDB的间隔太长，否则每次生成的RDB文件太大了，对redis本身的性能可能会有影响的。

• AOF持久化机制的优点

  • 1、AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据。

  • 2、AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复

  • 3、AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。

  • 4、AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据。

• AOF持久化机制的缺点

  • 1、对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大。

  • 2、AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的（如果fsync的频率过高，性能就会大幅度下降）。

  • 3、比如，如果你要保证一条数据都不丢，也是可以的，AOF的fsync设置成没写入一条数据，fsync一次，那就完蛋了，redis的QPS大降。

  • 4、以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

  • 5、唯一的比较大的缺点，其实就是做数据恢复的时候，会比较慢，还有做冷备，定期的备份，不太方便，可能要自己手写复杂的脚本去做，做冷备不太合适。

  • 6、如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制。

  • 7、通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云等一些云服务上。

  • 8、如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务。

  • 9、如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会默认使用AOF来重新构建数据，因为AOF中的数据更加完整（因为AOF默认每隔一秒往AOF文件里面写入一条写操作，和RDB是每隔一段时间生成一个快照）。

打开Redis.conf文件

第一句的意思是 每隔15分钟，有一个发生变化，保存一次。

redis数据保存在硬盘上的地址

微信扫码关注java架构，获取Java面试题和架构师相关题目和视频。