Redis简介和相关面试问题

简介

​ 是一个开源、免费、高性能、K-V非关系型内存数据库，支持持久化（部分支持，不支持强一致性）集群和事务。

Redis五种数据类型

• string、hash、list、set、zset

string：

string类型是二进制安全的，redis的string可以包含任何数据，如图像、序列化对象。一个键最多能存储512MB
二进制安全是指，在传输数据的时候，能保证二进制数据的信息安全，也就是不会被篡改、破译；如果被攻击，能够及时检测出来
String应用场景：

通常用来存储一个用户信息的对象数据。
1、相比于存储对象的string类型的json串，json串修改单个属性需要将整个值取出来。而hash不需要。
2、相比于多个key-value存储对象，hash节省了很多内存空间
3、如果hash的属性值被删除完，那么hash的key也会被redis删除

hash:

Redis hash是一个string类型的field和value的映射表，hash特别适用于存储对象。每个hash可以存储232-1键值对。可以看成的k-v的map容器。相比于json，hash占用很少的内存空间

Hash的应用场景

1、String通常用于保存单个字符串或JSON字符串数据
2、因为String是二进制安全的，所以可以把保密要求高的图片文件内容作为字符串来存储
3、计数器：常规Key-Value缓存应用，如微博数、粉丝数。INCR(Incr命令将key中储存的数字值增一)本身就具有原子性特性，所以不会有线程安全问题

list:

Java中的LinkedList

(java中的LinkdeList:内部是以连表的形式保存集合元素，所以在查询方便是慢的，在增删有较好的性能和ArrayList恰巧相反；可以根据索引访问集合，同时也实现了Deque接口，可以当做双端队列使用（意思就是说，可以当做栈使用，也可以当做队列使用）)

应用场景

1、对数据大的集合数据删减
		列表显示、关注列表、粉丝列表、留言评价...分页、热点新闻等
2、任务队列
		list通常用来实现一个消息队列，==而且可以确保先后顺序==，不必像MySQL那样通过order by来排序

set:

唯一无序
应用场景

对两个集合间的数据[计算]进行交集、并集、差集运算
1、以非常方便的实现如共同关注、共同喜好、二度好友等功能。对上面的所有集合操作，你还可以使用不同的命令选择将结果返回给客户端还是存储到一个新的集合中。
2、利用唯一性，可以统计访问网站的所有独立 IP

zset:

有序且不重复。每个元素都会关联一个double类型的分数，Redis通过分数进行从小到大的排序。分数可以重复
应用场景

  常用于排行榜：
1、如推特可以以发表时间作为score来存储
2、存储成绩
3、还可以用zset来做带权重的队列，让重要的任务先执行

EXPIRE key second的使用场景：
1、限时的优惠活动
2、网站数据缓存
3、手机验证码
4、限制网站访客频率

key的命名建议

1、key不要太长，尽量不要超过1024字节。不仅消耗内存，也会降低查找的效率
2、key不要太短，太短可读性会降低
3、在一个项目中，key最好使用统一的命名模式，如user:123:password
4、key区分大小写

redis相关面试题

1.redis是存储在内存的，出现宕机的情况后，怎么保证数据的不丢失？

实现redis的持久化。那么redis持久化实现有俩个方法：
1.快照形式RDB:
简介：会在一个特定的时间间隔里面保存某个时间点的数据快照，这种方式我们可以用来备份数据，把快照文件备份起来，传送到其他服务器就可以直接恢复数据。但是这只是某个时间点的全部数据，如果我们想要最新的数据，就只能定期的去生成快照文件，实现主要是通过创建一个子进程来实现 RDB 文件的快照生成，通过子进程来实现备份功能，不会影响主进程的性能。
	优点:
		保存速度和还原速度极快，适用于灾难备份
    缺点:
     	保存一定时间间隔的数据的，这就会导致如果时间间隔过长，服务器出现异常还没来得及生成快照的时候就会丢失这个间隔时间的所有数据，我们可以把时间间隔设置的短一点，适当的缩短是可以的，但是如果间隔时间段设置短一点频繁的生成快照对系统还是会有影响的，特别是在数据量大的情况下，高性能的环境下是不允许这种情况出现		  的小内存的机器不符合使用（RDB机制符合要求就会快照）---（redis.conf 进行 RDB 的相关配置根据规定时间内key的变化触发快照）
     也可以直接生成rdb文件：BGSAVE 命令是生成一个子进程，通过子进程来创建 RDB 文件，主进程依旧可以处理接受到的命令，从而不会阻塞服务器，在生产上可以使用
2.增量文件AOF:
简介：AOF是一种追加执行命令的形式，它跟 RDB 的区别是，AOF 并不是把数据保存下来，而是保存执行的动作。
我们可以定义多长时间把数据同步一次，Redis 本身提供了三种策略来实现命令的同步，分别是
1.不进行同步，2.每秒同步一次，3.以及当有查询的时候同步一次
如果Redis意外down掉，RDB方式会丢失最后一次快照后的所有修改。如果要求应用不能丢失任何修改，可以采用AOF持久化方式。
默认是没有开启的，我们可以通过在配置文件中配置appendonly yes是功能开启，同时配置同步策略appendfsync everysec 开启每秒钟同步一次，我们拿到 AOF 文件过后，可以根据这个文件恢复数据

2.redis和数据库双写一致性问题
产生的原因：
在缓存操作redis时，由于数据库和redis操作还有实效性的，所以缓存难免会有数据库和redis的数据不一致性
前提：
就是如果对数据有强一致性要求，不能放缓存。我们所做的一切，只能保证最终一致性。
有三种策略：
1.先更新数据库 ，在更新缓存（不考虑-线程安全角度）

举例：同时有请求A和请求B进行更新操作，那么会出现

（1）线程A更新了数据库
（2）线程B更新了数据库
（3）线程B更新了缓存
（4）线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
业务场景：
（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。

2.先删除缓存，在更新数据库

该方案会导致不一致的原因是。同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形:
（1）请求A进行写操作，删除缓存
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值
（4）请求B将旧值写入缓存
（5）请求A将新值写入数据库
上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。
那么，如何解决呢？采用延时双删策略
（1）先淘汰缓存
（2）再写数据库（这两步和原来一样）
（3）休眠1秒，再次淘汰缓存
针对上面的情形，读者应该自行评估自己的项目的读数据业务逻辑的耗时。然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

3.先更新数据库，在删除缓存

（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存

发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。

4.redis为什么这么快

回答:主要是以下三点
(一)纯内存操作
(二)单线程操作，避免了频繁的上下文切换
(三)采用了非阻塞I/O多路复用机制

5.redis雪崩，穿透，击穿

6.如何解决redis的并发竞争问题