Redis入门知识

redis介绍

最后欢迎的NoSQL数据库之一， 它是个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

定义
redis是一个key-value储存系统。支持存储的value类型相对更多，包括string、list、set、zset(有序集合)和hash。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。为了保证效率，数据会缓存在内存中。redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步，从服务器可以是关联其他从服务器的主服务器。这使得Redis可执行单层树复制。存盘可以有意无意的对数据进行写操作。由于完全实现了发布/订阅机制，使得从数据库在任何地方同步树时，可订阅一个频道并接收主服务器完整的消息发布记录。同步对读取操作的可扩展性和数据冗余很有帮助。

特点：
基于内存运行，性能高效
支持分布式，理论上可以无限扩展
key-value储存系统，持久化操作，高并发读写
是单进程单线程模型
能操作list 、set、hash、 string、zset等数据结构
操作具有原子性

redis的数据类型及应用场景

String
常规的set/get操作，value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。

hash
这里value存放的是结构化的对象，比较方便的就是操作其中的某个字段。博主在做单点登录的时候，就是用这种数据结构存储用户信息，以cookieId作为key，设置30分钟为缓存过期时间，能很好的模拟出类似session的效果。

list
使用List的数据结构，可以做简单的消息队列的功能。另外还有一个就是，可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。

set
因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

sorted set
sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP N操作。sorted set也可以用来做延时任务、范围查找。

redis应用场景

Redis 的应用场景包括：缓存系统（“热点”数据：高频读、低频写）、计数器、消息队列系统、排行榜、社交网络和实时系统。

redis内存分配策略
在Redis中有配置参数maxmemory可以设置Redis内存的大小， 倘若实际的存储中超出了Redis的配置参数的大小时，Redis中有淘汰策略，把需要淘汰的key给淘汰掉，整理出干净的一块内存给新的key值使用

淘汰策略
当redis内存不足时，需要删除一些数据
删除的是没有过期的数据，删除策略是删除已过期的数据
注：执行每条指令前，redis会调用freeMoneryIfNeeded()检查内存是否充足

Redis提供了6种的淘汰策略，其中默认的是noeviction，这6中淘汰策略如下：
noeviction(默认策略)：若是内存的大小达到阀值的时候，所有申请内存的指令都会报错。
allkeys-lru：所有key都是使用LRU算法进行淘汰。
volatile-lru：所有设置了过期时间的key使用LRU算法进行淘汰。
allkeys-random：所有的key使用随机淘汰的方式进行淘汰。
volatile-random：所有设置了过期时间的key使用随机淘汰的方式进行淘汰。
volatile-ttl：所有设置了过期时间的key根据过期时间进行淘汰，越早过期就越快被淘汰。

假如在Redis中的数据有一部分是热点数据，而剩下的数据是冷门数据，或者我们不太清楚我们应用的缓存访问分布状况，这时可以使用allkeys-lru。

假如所有的数据访问的频率大概一样，就可以使用allkeys-random的淘汰策略。

LRU算法
LRU(Least Recently Used)即表示最近最少使用，也就是在最近的时间内最少被访问的key，算法根据数据的历史访问记录来进行淘汰数据。
核心思想：假如一个key值在最近很少被使用到，那么在将来也很少会被访问。

LFU算法
LFU(Least Frequently Used)即表示最近频繁被使用，也就是最近的时间段内，频繁被访问的key，它以最近的时间段的被访问次数的频率作为一种判断标准。
核心思想：根据key最近被访问的频率进行淘汰，比较少被访问的key优先淘汰，反之则优先保留。

redis删除策略

redis有三种删除策略
1.定时删除-创建一个定时器，定时执行对key的删除
优点：节约内存，过期删除，快速释放不必要的内存占用
缺点：cpu压力大，会影响redis服务器的响应时间

2.惰性删除-每次只有访问key的时候，才会检查是否过期，若过期则删除
优点：节约cup性能，并不会立即删除
缺点：内存压力大，出现长期占用内存的数据

3.定期删除-每隔一段时间检查，然后删除过期key
折中以上两种策略，合理的控制删除时间，减少cpu的占用。合理化删除

Redis缓存

1.缓存穿透
访问不存在的数据，就会跳过redis数据缓存阶段，一直去查询数据库，对数据库的压力就会增大，导致数据库崩溃

解决办法
1.可以在最外层先做一层校验：用户鉴权、数据合法性校验等，例如商品查询中，商品的ID是正整数，则可以直接对非正整数直接过滤等等

2.缓存null：Redis对查询结果为null的数据进行缓存，但是这种方式效果十分有限，会导致Redis中缓存了无用的null值，占用空间

3.布隆过滤器

2.缓存击穿
单个高热数据不停的扛着大并发，当缓存过期的瞬间，持续的大并发击穿缓存直接访问数据库，瞬间对数据库的访问压力增大

因素：
冷门数据：该数据没有人查询过 ，第一次就大并发的访问
热点数据：添加到了缓存，reids有设置数据失效的时间 ，这条数据刚好失效，大并发访问

解决办法
1.预先设定：比如购物网站，对热点商品要加大此类key的过期时长
2.现场调整：监控访问量，对自然流量激增的数据延长过期时间或设置为永久性key
3.后台刷新数据：启动定时任务，高峰期来临之前，刷新数据有效期，确保不丢失
4.二级缓存：设置不同的失效时间，保障不会被同时淘汰

3.缓存雪崩
某一节点缓存的过期数据量太大，导致无数请求绕开缓存直接访问数据库

因素：redis宕机或大部分数据失效

解决办法
1.搭建高可用的集群，防止单机的redis宕机。
2.设置不同的过期时间，防止同一时间内大量的key失效。

redis的主从复制

概念：
为了避免单点redis服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的；即使有其中一台宕机，其他服务器依然可以继续提供服务，实现redis的高可用，同时实现数据备份

将master中的数据及时、有效的复制到slave中，一个master可以拥有多个slave，一个slave只对应一个master

master：写数据、执行写操作时，将出现变化的数据自动同步到slave，slave只读数据

作用

1. 读写分离：master写、slave读，提高服务器的读写负载能力
2. 负载均衡：slave分担master负载，并根据需求的变化，可改变slave的数量，大大提高Redis服务器并发量与数据吞吐量
3. 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
4. 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
5. 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案

工作机制流程：
1.当slave启动后会向master发送SYNC命令，master接到数据库的命令后通过bgsave保存快照(RDB持久化)，并且期间的执行的命令都会被缓存

2.然后master会将保存的快照发送给slave，并且继续缓存期间的写命令

3.slave收到主数据库发送来的快照就会加载到自己的数据库中

4.最后master将缓存的命令同步给slave，slave收到命令后执行一遍，这样master就与slave数据一致了

缺点：
数据的一致性问题，当主数据库完成了写操作，那么它的数据就会被复制到从数据库，倘若没有及时复制到从数据库，读的请求就就来了，此时的数据就不是最新的数据，网络故障也会影响数据一致性

redis持久化

redis主要有两种持久化机制，RDB和AOF

RDB持久化机制
将当前进程的数据以生成快照的形式持久化到磁盘中，是redis默认的持久化机制，会把内存中的数据写入默认文件名为dump.rdb

RDB持久化的时候会单独fork一个与当前进程一模一样的子进程来进行持久化，其特点：
1.开机恢复数据块
2.写入持久化文件快

缺点：
RDB持久化后的文件时紧凑的二进制文件，适合于备份、全量复制、大规模数据恢复的场景，对数据的完整性和一致性要求不高，RDB会丢失最后一次快照的数据

在RDB机制中触发内存中的数据进行持久化，有三种方式：
1.save命令
save命令不会fork子进程，通过阻塞当前redis服务器，直到RDB完成为止

2.bgsave命令
会在后台fork一个与redis主线程一模一样的子线程，由子线程复制内存中的数据持久化，虽然消耗了内存，但是不会阻塞主线程

3.自动化，直接在redis.conf文件中配置save

save和bgsave的区别
1.save是同步持久化数据，而bgsave是异步持久化数据。

2.save不会fork子进程，通过主进程持久化数据，会阻塞处理客户端的请求，而bdsave会fork子进程持久化数据，同时还可以处理客户端请求，高效。

3.save不会消耗内存，而bgsave会消耗内存

AOF持久化机制(默认不开启)
在redis.conf中开启 appendonly配置
以日志的形式记录redis中的每一次增删改，不会记录查询操作，以文本的形式记录，打开记录的日志就可以查看操作记录

触发机制
AOF持久化更加安全可靠，默认提供三种触发机制

no：等操作系统数据缓存再同步到磁盘中（快、持久化没保证）。
always：同步持久化，每次发生数据变更时，就会立即记录到磁盘中（慢，安全）。
everysec：表示每秒同步一次（默认值，很快，但是会丢失一秒内的数据）。

AOF的优缺点
优点：
AOF更好保证数据不会被丢失，通过fork一个子进程处理持久化操作，保证了主进程不会被阻塞，能高效的处理客户端要求
缺点：
对于相同数量的数据集而言，AOF文件通常要大于RDB文件，RDB在恢复大数据集时的速度比AOF快，AOF运行效率慢

混合持久化
RDB+AOF 默认关闭，在redis.conf中通过aof-use-rdb-preamble 开启

优点： 混合持久化结合RDB持久化和AOF持久化的优点，由于绝大部分的格式是RDB格式，加载速度快，增量数据以AOF方式保存，数据更少的丢失

哨兵模式

概念
在一主多从结构中，如果master宕机了，就需要从多个slave中选出一个作为新的master，他是一个分布式系统，用于对主从结构中的每台服务进行监控，当出现故障时通过投票来选出新的master，并将所有的slave连接到新的master

哨兵作用
1.监控：监控master和slave是否正常运行，以及哨兵之间也会相互监控
2.通知：当被检控的服务器出现问题时，向其他哨兵、redis发送通知
3.自动故障恢复：当master出现故障的时候，会自动选取一个slave作为master

1.哨兵1向master发送info指令之后，会建立一个cmd连接，创建的连接是用来发送命令的

2.创建好cmd连接之后，会在哨兵1这一端保存目前他所获得的所有信息，另一端master也会保存自己持有的信息

3.然后哨兵1根据从master获取的关于salve的信息，向slave发送info指令，得到salve的信息，丰富这一端所保存的信息

4.当新增一个新的哨兵2时，哨兵2向master发送info指令，建立cmd连接，根据master中的信息可以得到之前已经存在的哨兵1，在自己这一端保存已经获得的信息。然后判断哨兵1是否在线，与哨兵1建立连接，二者互相交换各自的信息，并且双方会持续的ping，保证他们之间是畅通的

5.哨兵2根据从master获得的slave信息，再从slave获取信息，丰富自己所保存的信息

6.再新增一个哨兵3时，与之前的过程类似，最终三个哨兵建立起了关系网

7.关系网中三者会互相交换、发送信息，关系网中的这种工作模式称为发布订阅模式