Redis系列一
一、初识Redis
1,什么是redis
使用C语言编写，遵守BSD协议的一个高性能key-value分布式内存数据库并提供持久化的NoSQL数据库
2,redis特性：速度快
Redis官方给出的数据是10W QPS（每秒可以操作数据10W次），这个数据会根据电脑性能和Redis的使用方式不同而略微不同，但是在万级数据中操作没有压力。
redis为什么那么快呢？
(1)纯内存操作
数据存放在内存中，内存的响应时间大约是 100纳秒 ，这是Redis每秒万亿级别访问的重要基础。
(2)编程语言
纯ANSI C编写，不依赖第三方类库。
(3)线程模型
Redis使用单线程操作，避免了频繁的上下文切换，也不存在多进程或者多线程导致的切换而消耗 CPU。
3,redis支持5种数据类型
3.1 String类型
一个 key 对应一个 value。value可以是简单字符串，也可以是复杂的字符串比如JSON，XML等，也可以是数字（小数、整数）
string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。
String类型的使用场景：用来做缓存、计数器、分布式锁等。
3.2 List类型
list 列表是简单的字符串列表，按照插入顺序排序，数据可以重复。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。
List应用场景：好友列表，粉丝列表，消息队列，最新消息排行等。
3.3 Set类型
set是string类型的无序集合，set中的元素是没有顺序并且不可重复。
Set应用场景：共同关注、共同喜好、二度好友、分类标签等。
3.4 hash类型
一个key对应一个HashMap。
Hash应用场景：用一个对象来存储用户信息，商品信息，订单信息等。
3.5 sorted set
sorted set 是有序集合， 它在 set 的基础上增加了一个顺序属性（score），这一属性在添加，修改元素的时候可以指定， 每次指定后， 会自动重新按新的值调整顺序。 可以理解了有两列的mysql 表，一列存 value，一列存score。
4，redis具体使用场景
4.1 缓存系统
我们要获取数据先从cache（缓存）中获取，如没有在从数据库中获取，以减轻数据库的压力。
4.2 计数器和计时器
我们可以使用redis的incr来记录转发数，评论数，视频播放数等，而不会发生错误，这个功能对公司项目的决策是很重要的， 计时，比如验证码一分钟内有效。可以使用 Redis 的 setex 命令设置验证码只保存一分钟，一分钟后失效
4,3 消息队列系统
成熟的消息队列有ActiveMQ，RabbitMQ、Kafka等。Redis 的 List 类型能够很轻松的实现一个消息队列。
4,4 排行榜
Redis提供的有序集合（Zset），可以实现排行榜
4.5 实时系统
比如垃圾邮件过滤，电商秒杀等系统就可以使用Redis实现。
5，redis的持久化
5.1 redis默认持久化RDB
RDB其实就是把数据以快照的形式保存在磁盘上。什么是快照呢，你可以理解成把当前时刻的数据拍成一张照片保存下来。
RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘。也是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb
1.当redis节点因为断电或者关机.这是内存释放,数据丢失.
2.当redis再次启动时首先会根据配置文件查找当前节点的rdb文件,自动的读取rdb文件中的内容.自动的实现数据恢复.
5.1.1 三种触发方式
save触发方式(已被弃用)
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。具体流程如下：
执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。
bgsave触发方式
执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：
具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
自动触发
自动触发是由我们的配置文件来完成的。在redis.conf配置文件中，里面有如下配置，我们可以去设置
save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
默认如下配置：
#表示900 秒内如果至少有 1 个 key 的值变化，则保存save 900 1#表示300 秒内如果至少有 10 个 key 的值变化，则保存save 300 10#表示60 秒内如果至少有 10000 个 key 的值变化，则保存save 60 10000
不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。
一般采用 bgsave触发方式持久化
RDB 的优势和劣势
优势：
(1) RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复
(2) 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。
(3) RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
劣势：
当进行快照持久化时，会开启一个子进程专门负责快照持久化，子进程会拥有父进程的内存数据，父进程修改内存子进程不会反应出来，所以在快照持久化期间修改的数据不会被保存，可能丢失数据。
5.2 redis持久化AOF
全量备份总是耗时的，有时候我们提供一种更加高效的方式AOF，工作机制很简单，redis会将每一个收到的写命令都通过write函数追加到文件中。通俗的理解就是日志记录。
持久化原理：
文件重写原理：
AOF的方式也同时带来了另一个问题。持久化文件会变的越来越大。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写。
重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
5.2.1 三种触发方式
redis的默认持久化策略采用RDB形式,如果想使用AOF形式,需要进行额外的配置。
appendonly no（默认）改成 yes
Everysec方式：
每秒数据备份一次 效率相对于RDB接近效率。
Always方式：
只要执行set操作,则redis就会备份,该操作的效率很低。
No方式：(弃用)
将备份的策略交个操作系统完成(30分钟备份一次) 一般很少使用。
appendfsync everysec 默认采用每秒备份一次.
对比这三种方式：
总结：RDB方式可能造成数据的丢失，但效率高于AOF。如果对数据的完整性要求非常高，则使用AOF方式。