关于Redis的基础知识点整理

Redis的背景：

​   在互联网发展的开始，关系型数据库受到广泛的关注和应用，因为访问和并发不是很高，交互也很少，这个时候，关系型数据库出现了缺点和不足，引发这个问题的是在磁盘的I/O上，对性能有了更高的需要：

​     (1)读写速度要快，这样才能提高用的满意度，

​     (2)对大型应用，支持海量数据。

​     (3)集群和分布式的部署与管理。

​     (4)运行成本

为了解决以上4个问题，出现了NoSQL ，有高性能、高可用、可扩展性强。

这里提到了关系型数据库和非关系型数据库的联系区别：

​   1. 关系型数据库：二维表及其之间的联系所组成的一个数据组织，有（MySQL，Oracle，SQL Server）

​     优点：易于维护，格式是一致的、复杂的SQL也可以操作、方便使用，语言通用

​     缺点：是存储在磁盘上，性能低下，读写性能低下，表结构是一致的、不灵活。

​   2. 非关系型数据库：是一种数据结构化存储方法的集合，可以是文档或者键值对等

​     优点：存储在内存上，支持海量数据的读写，速度也较快，格式也比较灵活文档，图片、key-value的形式存储，高可扩展性

​     缺点：不提供SQL支持，没有事务处理，数据结构比较复杂。

存储的是：key-value的键值形式，key不能太长，也不能太短，是唯一的，太短降低可读性，太长降低查找效率

Redis的安装

使用软件环境：VMware Xshell5 Xftp5

首先下载redis，进入Redis的官网：https://redis.io/，下载压缩包

选择下载版本，直接下载既可，

使用Xshell5和Xftp5，将下载好的Redis的压缩包通过Xftp软件传输到服务器中，

创建一个目录：

mkdir /usr/local/redis

对redis压缩包解压，并且放在刚创建好的目录下：

tar -zxvf redis-5.0.5.tar.gz -C /usr/local/redis/

安装依赖

yum -y install gcc-c++ autoconf automake

安装：

make PREFIX=/usr/local/redis/ install

进入bin目录检查，是否安装成功：

redis-cli：客户端

redis-server：服务端

启动Redis：

进入bin目录下，启动 ./redis-server

这是前台启动，按ctrl+c 结束

对配置文件进行复制修改，复制的原因：如果在原有的配置文件上进行修改，出现问题，就无法解决

cp redis.conf /usr/local/redis/bin/

vi redis.conf 对配置文件进行修改：

改为后台启动：

注释掉 bind 127.0.0.1 可以使所有的ip访问redis，若是想指定多个ip访问，但并不是全部的ip访问，可以bind设置

关闭保护模式：

添加访问认证：

查看进程：ps -ef|grep redis

可以使用：kill -9 XXXX杀死进程

重新启动，使用后台启动，进入 cd /usr/local/redis/bin/下，./redis-server ./redis.conf

重新启动，查看进程，已经启动。

使用RedisDesktopManager图形用户界面，也可以进行操作，认证密码也就是配置文件中已经配置好的，就是上文的“添加访问认证”

Redis的数据类型：

string、set、list、hash、zset(sorted set)

使用客户端对五种数据类型进行操作：

string

默认的database有16个，可以随意选择0-15，这里选择的是8

set：添加一条string类型的数据。get：获取一条 mset：添加多条数据。mget：获取多条

list

lpush :左添加。rpush :右添加。lrange : 获取数据。llen :获取条数。lrem :删除数据

hash

hset :添加一条。hget :获取一条。hmset :添加多条。hmget :获取多条。hgetAll :获取指定数据。hdel :删除指定数据

set

sadd :添加。smembers :获取。scard :获取条数。srem :删除数据

zset

sorted set是通过分数值来进行排序的，分数值越大，越靠后。

zadd :添加。zrange :获取。zcard :获取条数。zrem :删除数据。

Redis持久化

Redis在内存中操作数据，比传统的数据库快。
  缺点：不能海量存储数据，内存没有磁盘大，可能会丢失数据。想办法存储在硬盘上，存在磁盘上，进行持久化操作。
Redis如果宕机，存储在内存中的数据，数据就会丢失，进行持久化操作。两种方式RDB和AOF


  RDB：快照，手动命令和配置
    bgsave：手动命令，保存在一个专门的快照文件中，持久化到磁盘上。简单，太频繁，太麻烦，敲一个命令就得保存一次
    rdb配置文件，dbfilename dump.rdb：持久化方式是RDB方式
    dir./：持久化数据到的目录
    save 900 1：900秒之内至少一个key发生了变化。
    save 60 10000：60秒之内至少10000个key发生变化。

​     以上“变化”是指：对数据进行的写入操作，指的是增删改，后台进程会保存在快照文件中

​     但是出现问题：假设59秒修改了8000个数据，发生了宕机。只有达到这个条件才会去执行，没有达到就无法执行，数据就会丢失。数据在dump.rdb中，只是存储数据。宕机之后，重启，会从dump.rdb文件中重新获取这些数据。


​    AOF：每条数据都不会丢失。Redis默认是rdb持久化数据
​     配置文件中：appendonly.aof appendonly yes:开启，改成yes之后默认的rdb就会失效。换成aof，rdb存储的数据就会丢失，rdb失效。aof是实时的数据进行存储，整个命令进行存储，占得空间很大， key value 命令都会保存，空间造成不足。

如何选择看业务需求，数据允许丢失，就选择rdb。如果要求数据不丢失选择aof。也可同时开启rdb和aof，配置文件进行修改既可。

Redis模式

单机------->主从复制------->哨兵模式------->集群

单机：只有Redis服务器，所有的业务都在上面

​   优点：部署简单、成本比较低下、高性能

​   缺点：随时可能宕机、数据存储的不安全，Redis是单线程的

主从复制：一个Redis可能解决不了问题，开始复制，被复制的是主节点，复制出来的都是从节点，多它们之间的数据还是保持一致的，数据只能是从主节点到从节点方向，不能反向。主节点可读可写，从节点只能读。主节点宕机，就会从其他的从节点中选择。

​   优点：主从节点进行扩展，降低了主节点的读功能，缓解压力，相当于主节点的备份，宕机之后，数据仍然存在

​   缺点：没有解决写功能，而且主从节点的数据一致，存在数据冗余，主节点宕机后，是需要人为的去让其中的一个从节点变成主节点，然后将数据复制在主节点。

哨兵模式：基于主从复制，解决了主从复制手动修改复制数据，哨兵实现了自动化故障恢复，哨兵模式由两部分组成，哨兵节点和数据节点。

​   哨兵节点：哨兵节点是特殊的 Redis 节点，不存储数据；

​    数据节点：主节点和从节点都是数据节点。

​   优点：它是基于主从复制，所以主从模式的优点它都有，主节点宕机之后，从节点会选举新的主节点，Sentinel 会随时监控着所有的主从节点，如果出现问题，则会第一时间通知程序。

​   缺点：主节点的写能力没有解决，主节点宕机之后，需要选举新的从节点成为主节点，那么需要时间，而且数据可能存在丢失的风险。

集群：解决写问题，利用分布式集群解决，具有高可用，可扩展性，分布式

​   优点：无中心架构，可扩展性，高可用性，分布式的

​   缺点：无法保证数据的强一致性，搭建环境复杂。

Redis可以做缓存，数据库，消息中间件，注册中心

缓存：用户查数据，首先从缓存中查询，如果缓存中没有，就从数据库查，如果查到数据，则返回数据给用户，并且会把数据添加到缓 存中，下次访问这些数据的时候，会直接从缓存中去查，不会再去数据库，减轻了数据库的压力

缓存的key过期淘汰机制：
  定期删除：默认100毫秒随机抽取一些设置了过期时间的key，去检查是否过期，过期就删除，为什么随机，因为key如果是成千上万的，那么查询的数据就太多了，效率降低。压力增大（可能会存在已过期的key不会被删除，天选之子，就是随机不到它）

​   惰性删除：用户请求key的时候，如果key过期，redis就会把这个key删除，返回用户空值，没有过期，正常返回数据（恰好这个过期的key没有被随机到，也没有被用户访问到，那么要怎么删除它呢，如果类似它这种的key越来越多，内存压力就会越来越大，可以使用内存淘汰机制）

​   内存淘汰机制：没办法保证过期的key百分百被删除，配置好，怎么隔一段时间去清理一下内存，挑选key已经失效，最近最少使用的数据进行删除。

减少硬编码，写死。配置文件数据放在数据库中，直接从数据库中查询。可以放在redis中，设置永不失效。

缓存击穿：（同一时间下）高并发下，一个热门的key过期了，导致大量请求找不到key，就会去请求数据库，引发数据库压力变大。击穿查询的是redis中不存在，数据库中存在的数据。它不会导致服务下线
怎么解决：
  热门key被访问的次数这么多，那就设置别过期，永不过期
  有可能拿到的数据并不是最新的数据。获取到的不是事实数据，是脏数据，
  在对象上添加过期时间，获取到的数据，会进行校验对象时间，主动更新数据库，更新到redis，互斥锁，

缓存穿透：穿透是查询redis中不存在，数据库中也不存在的数据。
  恶意的用户：查询id为-1的key的数据 ，封掉ip
  普通用户去查询发现真的数据不存在，后期可能会添加这个数据，解决：加锁，都会返回一个值，有失效时间，
可以进行缓存预热，
布隆过滤器：非常大的集合，维护了合法有效的key，每次查的数据，都会先经过布隆过滤器，如果合法，就会去redis
也有可能不准确，布隆过滤器说这个key存在，不一定存在，如果说不存在，那么就一定不存在。
都不存在，就会返回用户一个空值，设置一个失效时间，一般是60秒

缓存雪崩：大量的key，同时失效，（抢购，秒杀，手机类商品（大量key）） 双缓存：要首先进行缓存预热。
解决方案：
  给缓存的失效时间，加上一个随机值，避免集体失效。如果Redis是集群部署，将热点数据均匀分布在不同的Redis库中也能避免全部失效的问题。
使用互斥锁，但是该方案吞吐量明显下降了。
设置热点数据永远不过期。
双缓存。我们有两个缓存，缓存A和缓存B。缓存A的失效时间为20分钟，缓存B不设失效时间。自己做缓存预热操作。

​     1. 从缓存A读数据库，有则直接返回

​     2. A没有数据，直接从B读数据，直接返回，并且异步启动一个更新线程。

​     3. 更新线程同时更新缓存A和缓存B。