柚子快报邀请码778899分享：数据库 nosql Redis
Redis
目录
Redis前言一、NoSQL的由来二、什么是NoSQL三、NoSQL的特点四、NoSQL的四大分类1. KV键值对2.文档型数据库3.列存储数据库4. 图关系数据库5. 四种关系型数据库对比
五、Redis入门六、Redis持久化什么是RDB（Redis Database）什么是AOF（Append Only File）
七、Redis主从复制哨兵模式
八、Redis缓存穿透，击穿和雪崩缓存穿透缓存击穿缓存雪崩
总结
前言
刚刚学完Redis，所以想要浅显的总结一下，如果那里有不对的地方，麻烦各位大佬在评论区指出，谢谢~
好可爱的关于Redis的文章和下面的视频是配套的！
哈哈哈，超级可爱的Redis，快去看看！随便帮我催催更(# . #)
这篇文章是狂神的Redis视频的学习笔记！
一、NoSQL的由来
Nosql是在MySQL后面出现的，因为互联网的发展，MySQL要容纳的数据越来越多，对MySQL的请求也是越来越多，众所周知，对数据库的请求60%都是在读数据，而且经常都是重复查询一个东西，浪费很多时间去进行磁盘I/O。所以我们想要减轻数据库的压力，就使用缓存来保证效率，以后每次要获取可以直接从缓存中拿，如果要写的话就可以到MySQL中写，就这样实现了读写分离，极大的提高了效率。
二、什么是NoSQL
NOSQL=Not Only SQL（不仅仅是SQL） 泛指非关系型数据库，随着web2.0互联网的诞生！传统的关系型数据库很难对付web2.0时代！尤其是超大规模的高并发的社区！暴露出来很多难以克服的问题，NoSQL在当今大数据环境下发展的十分迅速，Redis是发展最快的。
三、NoSQL的特点
解耦！
方便扩展（数据之间没有关系，很好扩展！）大数据量高性能（Redis一秒8万次，读取11万，NoSQL是缓存记录级，是一种细粒度的缓存，性能会比较高！）数据类型是多样型的！
四、NoSQL的四大分类
1. KV键值对
RedisTairMemecahe
2.文档型数据库
MongoDB
MongoDB是一个基于分布式文件存储的数据库，C++编写，主要用来处理大量的文档。MongoDB是一个介于关系型数据库和非关系型数据库中的中间产品。MongoDB是非关系型数据库中功能最丰富，最像关系型数据库的。 ConthDB
3.列存储数据库
HBase分布式文件系统
4. 图关系数据库
Neo4jInfoGrid
5. 四种关系型数据库对比
五、Redis入门
Redis是什么？
Redis是一款内存高速缓存数据库。Redis全称为：Remote Dictionary Server（远程数据服务），使用C语言编写，Redis是一个key-value存储系统（键值存储系统），支持丰富的数据类型，如：String、list、set、zset、hash。 Redis是一种支持key-value等多种数据结构的存储系统。可用于缓存，事件发布或订阅，高速队列等场景。支持网络，提供字符串，哈希，列表，队列，集合结构直接存取，基于内存，可持久化。
Redis能干什么？
1、内存存储（内存中是断电即失）、持久化 2、效率高，可以用于高数缓存 3、发布订阅系统 4、地图信息分析 5、计时器、计数器 ……
特性
多样的数据类型、持久化、集群、事务……
基础的知识
redis默认有16个数据库，默认使用的是第0个（可以用select命名进行切换数据库。） Redis是单线程的！ Redis是基于内存操作的，CPU不是Redis性能瓶颈，Redis的瓶颈是根据机器的内存和网络带宽，既然可以使用单线程来实现，那就实现了单线程。 Redis虽然是C语言写的，由官方提供的数据为100000+的QPS，可知Redis完全不必同样是使用key-value的Memacache差。
缓存过期和缓存淘汰
服务器上的内存是有限的，但是数据是无限的，如果这样一直存下去，服务器上的内存是不够用的。所以就出现了缓存过期和缓存淘汰。 缓存过期 给缓存内容设置一个超时时间，具体设置多长交给应用程序们去设置，如果有一个数据超过了缓存时间，就把这个数据删除。 内存淘汰
noeviction：返回错误，不会删除任何键值allkeys-lru：使用LRU算法删除最近最少使用的键值volatile-lru：使用LRU算法从设置了过期时间的键集合中删除最近最少使用的键值allkeys-random：从所有key随机删除volatile-random：从设置了过期时间的键的集合中随机删除volatile-ttl：从设置了过期时间的键中删除剩余时间最短的键volatile-lfu：从配置了过期时间的键中删除使用频率最少的键allkeys-lfu：从所有键中删除使用频率最少的键
六、Redis持久化
Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能！
什么是RDB（Redis Database）
RDB方式的持久化是Redis数据库默认的持久化机制,是保证redis中数据可靠性的方式之一，这种方式可以按照一定的时间周期策略把内存中的数据以快照(二进制数据)的形式保存到磁盘文件中，即快照存储。对应产生的数据文件为dump.rdb。
持久化快照保存过程
在指定的时间间隔内将内存中的数据集快照写入磁盘，过后会直接将快照文件读到内存里。（过程图如下） 1、 Redis会单独创建（fork）一个子进程来进行持久化； 2、Redis会先将数据写入到一个临时文件中； 3、带持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。RDB的缺点是最后一次持久化后的数据可能丢失。 优点 1、适合大规模的数据恢复。 2、对数据的完整性要求不高。 缺点 1、需要一定的时间间隔来实现进程操作，如果Redis意外宕机了，这最后一次的修改数据就没有了。 2、fork进程的时候，会占用一定的内存空间。
什么是AOF（Append Only File）
Redis中AOF方式的持久化是将Redis收到的每一个写命令都追加到磁盘文件的最后，类似于MySQL的binlog。当Redis重启时，会重新执行文件中保存的写命令，然后在内存中重建整个数据库的内容。 AOF 持久化默认是关闭的，可以通过配置appendonly yes 开启。当 AOF 持久化功能打开后，服务器在执行完一个写命令之后，会将被执行的写命令追加到服务器端 aof 缓冲区（aof_buf）的末尾，然后再将 aof_buf 中的内容写到磁盘。
AOF持久化过程
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，Redis启动之初会读取该文件重新构建数据，换言之，Redis重启的话就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。（过程如下图） 优点 1、每一次修改都同步，文件的完整性会更好。 2、每秒同步一次，可能会丢失一秒的数据。 3、从不同步，效率最高。 缺点 1、相对数据文件来说，AOF远远大于RDB，修复的速度也比RDB慢。 2、AOF运行效率也要比RDB慢，所以我们Redis默认的配置就是RDB持久化。
七、Redis主从复制
主从复制，是指将一台Redis服务器的数据复制到其他的Redis服务器。前者称为主节点（master/leader），后者称为从节点（slave/follower）；数据的复制是单向的，只能由主节点到从节点。master以写为主，slave以读为主。 默认情况下，每台Redis服务器都是主节点； 且一个主节点可以有多个从节点（或者没有从节点），但一个从节点只能有一个主节点。 主从复制的作用主要包括：
数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不行的（因为可能会出现宕机的情况），原因如下： 1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。 2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内容容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
复制原理
slave启动成功连接到master后会发送一个sync同步命名。 Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。 全量复制： 而slave服务在接收到数据文件到slave，并完成一次完全同步。 增量复制： master继续将新的所有手机到的修改命名一次传给slave，完成同步。 但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！我们的数据一定可以在从机中看到！
哨兵模式
概述
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis从2.8开始正式提供了Sentinel（哨兵）架构来解决这个问题。 谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。 哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。 这里的哨兵有两个作用
通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。 假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover[故障转移]操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。
优缺点
优点： 1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有 2、主从可以切换，故障可以转移，系统的可用性就会更好 3、哨兵模式就是主从模式的升级，手动到自动，更加健壮！
缺点： 1、Redis 不好啊在线扩容的，集群容量一旦到达上限，在线扩容就十分麻烦！ 2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择！
八、Redis缓存穿透，击穿和雪崩
缓存穿透
概念
缓存穿透的概念很简单，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有，于是本次查询失败。当用户很多的时候，缓存都没有命中（秒 杀！），于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这时候就相当于出现了缓存穿透。
解决方案
布隆过滤器 布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃，从而避免了对底层存储系统的查询压力； 缓存空对象 当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源； 但是这种方法会存在两个问题： 1、如果空值能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键； 2、即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间窗口的不一致，这对于需要保持一致性的业务会有影响。
缓存击穿
概述
这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。 当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。
解决方案
设置热点数据永不过期 从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。 加互斥锁 分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。
缓存雪崩
概念
缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis 宕机！
解决方案
redis高可用 这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续工作，其实就是搭建的集群。（异地多活！） 限流降级 这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。 数据预热 数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。
总结
这以上大部分是狂神视频里面的内容，还有一小部分是我对Redis粗浅的认识，如有错误，麻烦各位大佬在评论区指出，谢谢。
提示：想要转载，请私信本作者，经本人同意后，方可转载。谢谢！！
柚子快报邀请码778899分享：数据库 nosql Redis
推荐链接
您阅读本篇文章共花了：
发表评论