Redis缓存之剖析

一、Redis缓存相关问题

1、缓存穿透

缓存穿透是指查询一个数据库一定不存在的数据。也即是说，用户发送一个请求，穿透redis缓存这层，直接把压力达到数据库。

我们以前正常的使用Redis缓存的流程大致是：
1、数据查询首先进行缓存查询
2、如果数据存在则直接返回缓存数据
3、如果数据不存在，就对数据库进行查询，并把查询到的数据放进缓存
4、如果数据库查询数据为空，则不放进缓存

例如我们的数据表中主键是自增产生的，所有的主键值都大于0。此时如果用户传入的参数为-1，会是怎么样？这个-1，就是一定不存在的对象。程序就会每次都去查询数据库，而每次查询都是空，每次又都不会进行缓存。假如有人恶意攻击，就可以利用这个漏洞，对数据库造成压力，甚至压垮我们的数据库。

为了防止有人利用这个漏洞恶意攻击我们的数据库，我们可以采取如下措施：

如果从数据库查询的对象为空，也放入缓存，key为用户提交过来的主键值，value为null，只是设定的缓存过期时间较短，比如设置为60秒。这样下次用户再根据这个key查询redis缓存就可以查询到值了（当然值为null），从而保护我们的数据库免遭攻击。

解决方案：有很多种方法可以有效地解决缓存穿透问题。最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

布隆算法：通过一定的错误率来换取空间

它使用bit二进制数组来记录Mysql数据库中的数据是否存在。

 

2、缓存雪崩

缓存雪崩，是指在某一个时间段，缓存集中过期失效。在缓存集中失效的这个时间段对数据的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波峰。

为了避免缓存雪崩的发生，我们可以将缓存的数据设置不同的失效时间，这样就可以避免缓存数据在某个时间段集中失效。例如对于热门的数据（访问频率高的数据）可以缓存的时间长一些，对于冷门的数据可以缓存的时间段一些。甚至对于一些特别热门的数据可以设置永不过期。

3、缓存击穿

缓存击穿，是指一个key非常热点（例如双十一期间进行抢购的商品数据），在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求到数据库上，就像在一个屏障上凿开了一个洞。

同样可以将这些热点数据设置永不过期就可以解决缓存击穿的问题了。

二、Redis集群方案

单机Redis的读写速度非常快，能够支持大量用户的访问。虽然Redis的性能很高，但对于大型网站来说，每秒需要获取的数据远远超过单台redis服务所能承受的压力，迫切需要一种方案能够解决单台Redis服务性能不足的问题。这就需要使用到Redis的集群了。

Redis集群有多种方案，下面分别进行讲解。

1、主从复制Replication（实际使用场景较少）

redis支持主从复制的模式。
在主从复制模式下Redis节点分为两种角色：主节点(也称为master)和从节点(也称为slave)。这种模式集群是由一个主节点和多个从节点构成。
原则：Master会将数据同步到slave，而slave不会将数据同步到master。Slave启动时会连接master来同步数据。

这是一个典型的分布式读写分离模型。我们可以利用master来处理写操作，slave提供读操作。这样可以有效减少单个机器的并发访问数量。

实现：如何在一台虚拟机模拟多个redis节点？

可以启动多个redis实例，每个实例使用不同的端口号，那么每个实例相当于一个redis节点。

要实现主从复制这种模式非常简单，主节点不用做任何修改，直接启动服务即可。从节点需要修改redis.conf配置文件，加入配置：slaveof <主节点ip地址> <主节点端口号>，例如master的ip地址为192.168.200.129，端口号为6379，那么slave只需要在redis.conf文件中配置slaveof 192.168.200.129
6379即可。

（1）启动主节点master

redis的启动方式之一 -- 带上配置文件

[root@hadoop101 bin]# ./redis-server ./redis.conf 
[root@hadoop101 bin]# ll
总用量 8568
-rw-r--r--. 1 root root      18 5月  28 17:52 dump.rdb
-rwxr-xr-x. 1 root root 2077088 5月  16 17:06 redis-benchmark
-rwxr-xr-x. 1 root root   24992 5月  16 17:06 redis-check-aof
-rwxr-xr-x. 1 root root   55840 5月  16 17:06 redis-check-dump
-rwxr-xr-x. 1 root root 2201120 5月  16 17:06 redis-cli
-rw-r--r--. 1 root root   41404 5月  25 15:53 redis.conf
lrwxrwxrwx. 1 root root      12 5月  16 17:06 redis-sentinel -> redis-server
-rwxr-xr-x. 1 root root 4351944 5月  16 17:06 redis-server
[root@hadoop101 bin]# ps -ef|grep redis
root       2220      1  0 09:35 ?        00:00:00 ./redis-server *:6379
root       2236   1708  0 09:35 pts/0    00:00:00 grep --color=auto redis

(2)启动从节点slave1

修改其配置文件redis_slave1.conf：修改端口为6380，

启动从节点slave1，查看redis进程

通过登录主节点master查看：

通过登录从节点查看：

现在我们就可以通过这种方式配置多个从节点进行读操作，主节点进行写操作，实现读写分离。

2、哨兵sentinel（企业中常用）

我们现在已经给Redis实现了主从复制，可将主节点数据同步给从节点，实现了读写分离，提高Redis的性能。但是现在还存在一个问题，就是在主从复制这种模式下只有一个主节点，一旦主节点宕机，就无法再进行写操作了。也就是说主从复制这种模式没有实现高可用。那么什么是高可用呢？如何实现高可用呢？

2.1、高可用介绍

高可用(HA)是分布式系统架构设计中必须考虑的因素之一，它是通过架构设计减少系统不能提供服务的时间。保证高可用通常遵循下面几点：
1) 单点是系统高可用的大敌，应该尽量在系统设计的过程中避免单点
2) 通过架构设计而保证系统高可用的，其核心准则是：冗余
3) 实现自动故障转移

sentinel(哨兵)是用于监控redis集群中Master状态的工具，其本身也是一个独立运行的进程，是Redis的高可用解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。

当主节点挂掉，自动将某一个从节点上升为主节点

redis-sentinel

sentinel可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求，并且其余从节点开始从新的主节点复制数据。

 

2.2、 Redis sentinel使用

在redis安装完成后，会有一个redis-sentinel的文件，这就是启动sentinel的脚本文件，同时还有一个sentinel.conf文件，这个是sentinel的配置文件。

（1）修改配置sentinel.conf 

注意：如果有sentinel monitor mymaster 127.0.0.1 6379 2配置，则注释掉。

(2)启动sentinel

(3)测试sentinel

将主节点下线

6380变成master:

3、Redis内置集群cluster

（1）Redis cluster介绍

Redis Cluster是Redis的内置集群，在Redis3.0推出的实现方案。在Redis3.0之前是没有这个内置集群
的。Redis Cluster是无中心节点的集群架构，依靠Gossip协议协同自动化修复集群的状态。
Redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等
的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连
接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他
节点的数据。