redis总结

 1.nosql数据库的发展历程

1.1 web系统发展：

web系统: 1.0 -- > 2.0

改变点: 用户量不断提升 , 业务(页面)也在不断提升

导致: 原有的数据库系统无法承载这么大的并发访问, 此时需要一些基于内存型数据库(nosql型)

常见的nosql型数据库: memcache , redis, MongoDB HBase....

nosql型数据库: 非关系型数据库

不支持多行事务, 不支持表关系

1.2 nosql数据库应用场景

适用场景:

1) 高并发的数据读写场景 2. 存储大量的数据 3. 具有扩展性 4 速度够快

不适用场景:

1) 对事务要求比较高的场景 2) 不适合结构化的SQL查询方案, 或者 即席查询

2.redis的基本介绍

redis是一款非关系型的nosql数据库，开源免费，基于c语言编写的易可进行持久化的基于内存的key-value型数据库

redis的应用场景：

1) 高效快速的数据读写操作 2) 排行榜 3. 计数统计 4) 去重业务

redis具有特点:

1）redis具有高效的读写：读 11w/s  写  8w/s

2) redis支持多种数据类型：

 主要有五种：string  hash  list  set  zset

注意点：redis的数据类型主要描述的key-value中 value的数据类型 而key只有string

3) redis的操作都是原子性 保证数据的完整性

4) redis数据库非常稳定数据库, 一般不容易出现宕机问题, 数据移植非常快

3.redis的持久化机制

什么是持久化?

指的 将内存中数据移植到磁盘中进行存储操作,这个过程称为持久化, 也称为序列化 或者 钝化

思考: 从磁盘 到 内存的过程称为什么呢? 反序列化 | 活化

redis为什么要提供持久化的机制呢?

redis的数据都是存储在内存中, 在内存中数据, 一旦发生宕机或者服务器出现断电的情况, 都有可能导致内存数据出现丢失的问题, redis为了保证数据不丢失, 提供持久化的方案

redis提供的持久化方案主要有二种: RDB | AOF

RDB持久化方案：

基于快照机制的持久化方案

• 优点: 快照文件一般比较小, 适合于灾难恢复工作

• 弊端: 由于RDB 持久化的机制问题, 有可能导致数据丢失问题

 

AOF的持久化方案

基于日志机制持久化, 会将操作redis的命令全部完整的记录到日志文件中

• 优点: 数据保持的更加的完整, 数据丢失风险比较低

• 弊端: 日志文件比较庞大, 不适合做灾难恢复

 

如何设置RDB持久化方案

设置RDB持久化的方案, 需要到redis的配置文件中进行操作: 是redis默认使用持久化方案

save 900 1     : 在 900s(15分钟) 时间内, 如果有一个数据被修改了, 执行一次RDB快照操作 
save 300 10    : 在 300s(5分钟) 时间内, 如果有十个数据被修改了, 执行一次RDB快照操作
save 60 10000  : 在 60s(1分钟) 时间内, 如果有一万个数据被修改了, 执行一次RDB快照操作

如何设置AOF持久化方案

设置AOF持久化的方案, 需要到redis的配置文件中进行操作: 默认关闭

appendonly no : 是否开启AOF持久化机制, 默认为 no 
appendfilename "appendonly.aof" :  持久化日志文件的名称
appendfsync  always | everysec  |no : 设置AOF方案
    always: 总是  (坚决不使用)
        优点: 用户每操作一次redis, 就会将这个命令保存日志文件中,保存数据最完整
        弊端: 极大的影响redis的效率, 对效率的影响在50%以上
    everysec : 每秒执行一次 (默认)
        优点: 对redis的效率影响较低,保存的数据相对比较完整
        弊端: 存在数据丢失的问题 , 丢失1s的数据, 对效率也有一定影响 
    no: redis不主动执行AOF, 将持久化的动作交给了Linux系统(45分钟|30分钟)  (一般也不使用)
        优点: 几乎对redis的效率没有任何的影响
        弊端:  数据丢失风险更大了

思考：在生产中, 一般使用redis的那种持久化方案? A: RDB B: AOF C: RBD+AOF

    原因如下: redis是一个非常稳定nosql数据库,几乎不会出现宕机的问题, 而且redis中存储的数据都是缓存数据, 这些数据在关系型数据库中一般还会存储一份,即使真的发生丢失, 完全可以再从关系型数据库中缓存出来一份即可  

4.redis的过期策略

指的是: 当redis中设置过期策略的key 过期后, redis应该如何处理的问题

过期策略主要有三种: redis使用 惰性过期 + 定期过期

• 1) 定时过期: 一旦发现数据过期, 立即删除

• 2) 惰性过期: 当查询某一个key, 判断这个key是否过期, 如果过期, 直接删除

• 3) 定期过期: 每隔一定的时间, 查询整个redis中, 是否有过期的数据, 如果有直接删除

 

5redis的内存淘汰策略

指的是: 当redis对应服务器内存不足的情况下, 如果此时已然有写入数据操作,并且需要申请额外的空间, 此时redis应该如何做的问题

默认情况下: 当redis内存不足情况下, 如果依然要进行数据的插入, redis会直接报错

redis除了默认的方式以外, 支持其他五种方案:

• 1) 从设置了过期时间的key中, 找一个使用比较少的key进行删除操作, 从而达到让新的key可以插入

• 2) 从redis中所有的key中, 找一个使用比较少的key尽心删除操作 (推荐使用)

• 3) 从设置了过期时间的key中, 随机删除一个key

• 4) 从redis中所有的key中, 随机删除一个key

• 5) 从设置了过期时间的key中, 删除设置最早过期key