Redis概念高级部分

Redis高级

热身

整天都在说删库跑路,那么请说出redis中清除数据库的指令?

答: flushdb 只清除当前数据库
	flushall 会清除所有数据库
	如果当前数据库键值数量比较多，flushdb/flushall存在阻塞Redis的可能性,因为redis毕竟是单线程的嘛

Redis中默认配置有多少个数据库?这几个数据库之间的数据能否共享呢?

Redis中默认配置有16个数据库
不能,数据库之间的数据是隔离的。

redis入门

1.什么是Redis？

	1. 是一款开源的nosql数据库，业内称为高速缓存数据库。支持遵守BSD协议、以键值对形式对多种数据结构进行存储。是使用的c语言进行编写。所有的数据都是基于内存的，可以做持久化操作。它可以用作：数据库、缓存和消息中间件。	

2.有哪些优缺点特点？

	优点：
		1、以内存作为存储依据、所以读取数据的效率极高
		2、支持持久化操作
		3、支持多种类型结构，操作简便
		4、单进程单线程模式，避免了多进程或者多线程的来回切换导致的性能消耗，不用去考虑各种锁的安全问题所以就更不会有死锁问题
		5.支持java、C、C#、C++、php、Node.js、Go等语言
	缺点：（不算缺点。如果要说 硬说）
		1、修改配置文件后要进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程中，redis不能提供服务。
		2、由于是内存数据库，所以单台机器的存储量与机器本身的内存有关，如果内存增长过快，需要定期删除数据
           2.1、定时删除和定期删除为主动删除，Redis会定期主动淘汰一批已过期的key。
           2.2、惰性删除为被动删除，用到的时候才会去检验key是不是已过期，过期就删除过期的key。惰性删除是redis服务器内置策略

3.数据类型有哪些，大致概述使用场景？

string、hash、set、list、zset五种
最常用的是string类型，一个键值最大存储512MB

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

(二)hash
   暂无

(三)list
使用List的数据结构，可以做简单的消息队列的功能。可以利用lrange命令，做基于redis的分页功能，性能极佳，用户体验好。LIST可以很好的完成排队，先进先出的原则。

(四)set
因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重？因为我们的系统一般都是集群部署，使用JVM自带的Set，比较麻烦，难道为了一个做一个全局去重，再起一个公共服务，太麻烦了。
另外，就是利用交集、并集、差集等操作，可以计算共同喜好，全部的喜好，自己独有的喜好等功能。

(五)sorted set
sorted set多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用，取TOP10操作。

进阶

4.常用的缓存服务器有哪些？

Redis、Memerycached

redis相比memcached有哪些优势？

(1) Memerycached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型

(2) redis的速度比memcached快很多

(3) redis可以持久化其数据

redis与memcached区别？

1)、存储方式
Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，这样能保证数据的持久性。

2)、数据支持类型
Memcache对数据类型支持相对简单。
Redis有复杂的数据类型。

3）、value大小
redis最大可以达到1GB，而memcache只有1MB

5.Redis 如何保证持久化

Redis是一个支持持久化的缓存数据库，
通过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。
当Redis重启后通过把硬盘文件重新加载到内存，就能达到恢复数据的目的。

有哪些持久化的方式，区别是什么？

保证持久化的两种方式
	1.RDB是Redis默认的持久化方式。按照预先设置好定时策略将内存中的数据定期以二进制的形式快照进文件持久化存储，对应产生的数据文件为dump.rdb
	2.AOF是一种以操作日志的形式存储数据，进行备份的方式。保存下来的不是数据，而是一条条对数据进行操作的指令。当缓存区达到一定量后，再一次性写入到硬盘当中。重启时会读取这些指令在内存中通过某种机制重构数据。

概述RDB的三种指令的区别

1.SAVE指令  
	因为是单线程，所以排队进行保存故会被阻塞，当遇到某一指令太大的话，会影响后面的线程被阻塞。
2.Bgsave指令
  	是一个save的优化。可以在后台重新开一个线程来执行这个保存操作，后面的线程可以继续执行。但是消耗资源
3.配置频率（本质是一个Bgsave）
    1.save 秒  次数 ，每过多少秒 执行多少次。
	2.底层仍然是使用bgsave指令

持久化操作会同时使用吗？为什么要同时使用？

同时使用：
	当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。使用的时候一般会选择两种同时使用
	操作成本高 rdb 全部存储数据 并且扫描过期key 快照在中间过程中是扫不到的 会容易丢失数据  bgsave过程中 新加数据是保存不了的 所以要靠AOF的指令来弥补这些过程中的数据 来恢复 
	
	因此需要两种协同合作一起使用！

6.单线程的redis为什么这么快

(一)纯内存操作，读取速度爆炸  内存数据库
(二)单线程操作，避免了频繁的上下文切换（线程切换），所以降低了性能消耗。同时保证了原子性，操作要么执行要么不执行。
    做了数据压缩 减少了数据的传输
只记两点


(三)采用了非阻塞I/O多路复用机制（select，epoll, kqueue，依据不同的平台，采取不同的实现）来处理多个客户端请求，解决了单线程的尴尬

数据结构简单 对应数据操作简单
redis自己构建的vm机

加强

7.redis的key过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略。

#为什么不用定时删除策略?
	定时删除,用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key,因此没有采用这一策略.
	
#定期删除+惰性删除是如何工作的呢?
	定期删除，redis默认每隔100ms检查，是否有过期的key,有过期key则删除。需要说明的是，redis不是每隔100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。
	于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

#采用定期删除+惰性删除就没其他问题了么?
	不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。
	
在redis.conf中有一行配置  maxmemory-policy volatile-lru
# 该配置就是配内存淘汰策略的
	volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
	volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
	volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
    allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
	allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
	no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错
ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

8.多机redis 的部署如何保证数据一致的？

主从复制，读写分离
 	一类是主数据库（master）一类是从数据库（slave），主数据库可以进行读写操作，当发生写操作的时候自动将数据同步到从数据库，而从数据库一般是只读的，并接收主数据库同步过来的数据，一个主数据库可以有多个从数据库，而一个从数据库只能有一个主数据库。

​ 附加题

​ 为什么要使用主从复制

	持久化即使保证了redis服务重启不会丢失数据(因为redis服务重启后会将硬盘上持久化的数据恢复到内存中),但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障。

9.redis的哨兵模式 的作用

哨兵是对redis进行实时的监控，主要有两个功能。
1.监测主数据库和从数据库是否正常运行。
2.当主数据库出现故障的时候，可以自动将一个从数据库转换为主数据库，实现自动化的故障恢复
缺陷：写操作无法负载均衡；存储能力受到单机的限制。 

终

以下的各个专业名词概念是什么？可以解决什么问题 ？解决方案是什么？

9.缓存预热

定义：在服务器启动之前，将某些指定的数据提前加载进服务器

现象:
	服务器启动,过不了多久服务器宕机

出现的原因：
	1.热点页面请求量大   
	2.主从数据库之间数据吞吐量过大，数据同步操作过于频繁（启动服务器时，没有数据。同时大量请求来访问。导致访问一次页面，加载一遍。）

解决方案：
	1.日常统计热点数据 
		实现方案众多  示例两个：
        	1.利用redis的LRU数据删除策略【从数据集中挑选最近最少使用的数据淘汰】
		    2.storm和kafka 配合使用 快速统计热点数据
    总结：
     	原因：用户来访问的时候，服务器没数据。
        方案：将访问量高的数据先加载，用脚本自动加载。

10.缓存雪崩

现象： 
	底层数据库服务器宕机

出现的原因：
	1.数据库连接量突然激增，处理不过来，导致宕机
	2.应用服务器调用数据库，又无法及时处理请求，还在不断的接收后续请求。最终导致自己也宕机
	原因总结： 请求太多，数据库崩，不能响应给调用方。 调用方等待数据库响应，同时继续接收用户请求。又不能给前面的用户响应。导致最终自己也崩。 继续恶性循环，整个系统崩。 重启哪个都不好使。
	
	解决方案（错峰）：
	概念上：
		1.限流、降级
		2.构建多级/二级缓存方案  （Nginx -- redis --ehcache）
		3.对mysql数据库进行优化
		4.灾难预警机制。 redis性能指标监控 对CPU使用率、内存容量、线程数、平均响应时长进行监控。宏观可控。
     实际上：
     	1.切换redis的淘汰机制 LRU和LFU  按照访问次数淘汰key，而不是按照时间淘汰
     	2.对需要设置过期时间的数据错峰，比如 游戏类30分过期、购物类35分过期等 在此基础上再按照游戏类过期时间随机 比如30.01过期 30.05过期，不要一次性都在30的时候过期
     	3.热门数据不过期，用人工+自动的方式定期维护或者人工干预
     	4.加锁。慎用，影响性能！

11.缓存击穿

现象： 
	缓存数据库各项性能良好，但是服务器还是崩了。
	
原因：
	在某一时刻，某一key过期，但是同时有大量请求到达。redis没有，去数据库查询获得。
	数据库处理不过来，打出GG！
	如： 马航失踪了，该新闻立马是热度，但是正好key过期。

解决方案：
	1.活动前，提前将商家的热点商品延长超时
	2.监控key，遇到有短频激增key，直接延长超时
	3.二级缓存

12.缓存穿透

现象： 
	短时间大量请求到达redis，某些命中，但是大面积未命中，导致服务器还是崩了。
	
原因：
	短时间出现大量非法url，导致检测不到对应大量的key，越过redis直击数据库查询。 （黑客攻击）
	
解决方案：
	1.查询到该key，缓存该key，值为null（设置30-60s的过期时间。作用非常有限）
	2.白名单策略，拦截到黑客进入黑名单
		方式：
			1.bitmaps数据类型 本质是string
			2.布隆过滤器