宁波网站制作优化服务公司中国建筑在线网

Redis是CP还是AP？

        首先我们来聊一下，Redis是AP还是CP，我个人偏向于AP，在稍微大型的项目中，Redis不可能单节点部署的，如何Redis挂了，系统的效率就会很慢很慢，特别是有短时间高并发的系统，如果只部署单节点的Redis，数据库很大可能因为短暂的大量请求，导致数据库崩溃，所以Redis我个人偏向于AP。

为什么Redis那么快？

        redis快的原因有三个：

        1.纯内存操作

        2.单线程操作，避免了频繁的上下文切换。

        3.采用了非阻塞I/O多路复用机制。

这里的I/O多路复用，听起来很高大上，我们这边举一个很简单的例子带大家了解一下，我们这边会举出两种情况，来解释一下为啥I/O多路复用会让Redis变快：小明在本地开了一家公司，但是由于资金控制不当，雇佣了一批的员工和一台电脑。

经营方式一：

每来一个客户豆分配给一个员工，然后员工使用电脑来给客户编写方案，慢慢的小明发现这个经营方式出现了以下的问题：

1.几十个员工都将时间花在了抢电脑使用权了，很多的员工都处于闲置状态，谁能使用电脑，谁才能给客户提供方案。

2.随着客户的越来越多，导致员工越来越多，导致公司已经容不下那么多的人了，没办法再雇佣新员工了。

3.客户间的协调时间很长。

经营方式二：

小明只雇佣一个员工，客户需要的方案，可以按照客户的先后顺序来进行排序，没做好一份就可以发送给对应的客户，依次进行。

上述俩个方案，很明显，第二种方案效率是更高的，也是更好的，在上述的比喻中：

1.每个员工    ------------------> 每个线程

2.每个客户方案  --------------> 每个socket(I/O流)

3.客户的需求 ---------------> socket的不同状态

4.客户的方案请求 ------------> 来自客户端的请求

5.小明的经营方式 ------------> 服务端运行的代码

6.一台电脑     ------------------> CPU的核数

于是我们得出了如下的结论：

1. 经营方式一就是传统的并发模式，每个I/O流(客户方案)都有一个新的线程(员工)管理。

2. 经营方式二就是I/O多路复用。只有单个线程(一个员工)，通过跟踪每个I/O流的状态(每个客户的需求)，来管理多个I/O流。

下面类比到真实的redis线程模型，如图所示：

参照上图，简单来说，就是。我们的redis-client在操作的时候，会产生具有不同事件类型的socket。在服务端，有一段I/0多路复用程序，将其置入队列之中。然后，文件事件分派器，依次去队列中取，转发到不同的事件处理器中。
需要说明的是，这个I/O多路复用机制，redis还提供了select、epoll、evport、kqueue等多路复用函数库，大家可以自行去了解。

redis的数据类型，以及每种数据类型的使用场景

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

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

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

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

(五)sorted set

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

redis的淘汰机制和过期策略

分析:这个问题其实相当重要，到底redis有没用到家，这个问题就可以看出来。比如你redis只能存5G数据，可是你写了10G，那会删5G的数据。怎么删的，这个问题思考过么？还有，你的数据已经设置了过期时间，但是时间到了，内存占用率还是比较高，有思考过原因么?

回答:
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

该配置就是配内存淘汰策略的
1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。应该没人用吧。
2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。推荐使用。
3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。应该也没人用吧，你不删最少使用Key,去随机删。
4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。这种情况一般是把redis既当缓存，又做持久化存储的时候才用。不推荐
5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。依然不推荐
6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。不推荐
ps：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。