[root@localhost myredis]# vim redis6379.conf

将下面代码编辑到该配置文件
include usr/local/redis/myredis/redis.conf
pidfile /var/run/redis_6379.conf
port 6379
dbfilename dump6379.rdb

复制端口6380

[root@localhost myredis]# vim redis6380.conf

将下面代码编辑到该配置文件
include usr/local/redis/myredis/redis.conf
pidfile /var/run/redis_6380.conf
port 6380
dbfilename dump6380.rdb

复制端口6381

[root@localhost myredis]# vim redis6381.conf

将下面代码编辑到该配置文件
include usr/local/redis/myredis/redis.conf
pidfile /var/run/redis_6381.conf
port 6381
dbfilename dump6381.rdb

启动各个端口的redis

[root@localhost myredis]# redis-server redis6379.conf
[root@localhost myredis]# redis-server redis6380.conf
[root@localhost myredis]# redis-server redis6381.conf

查看redis进程

[root@localhost myredis]# ps -ef | grep redis
root 5209 1 0 06:10 ? 00:00:01 redis-server 127.0.0.1:6380
root 5243 1 0 06:10 ? 00:00:01 redis-server 127.0.0.1:6381
root 5611 1 0 06:24 ? 00:00:00 redis-server 127.0.0.1:6379
root 5620 3992 0 06:24 pts/0 00:00:00 grep --color=auto redis

分别打开三个窗口连接三个服务器

redis-cli -p 6379
redis-cli -p 6380
redis-cli -p 6381

1.4、一主二仆

这里把6379当作主服务器，把6380、6381当作为从服务器，那么6380、6381就要通过命令去绑定主服务器，在6380、6381服务器分别输入以下命令，将6379服务器当作主服务器。

127.0.0.1:6380> slaveof 127.0.0.1 6379
OK

127.0.0.1:6381> slaveof 127.0.0.1 6379
OK

-- 测试主服务器写操作
127.0.0.1:6379> set a 1
OK
-- 从服务器读操作
127.0.0.1:6380> get a
"1"
127.0.0.1:6381> get a
"1"

1.5、注意事项

1、当其中的一个从服务器 shutdown 挂掉了，从服务器再次启动还会不会重新连接到主服务器中？

不会，会自动变成主服务器。

2、如果把挂掉的从服务器重新连到主服务器后，主服务器的数据还会不会复制过来？

会。

3、当主服务器挂掉后，从服务器不会做任何事情，查看从服务器 info replication服务器情况，还认主服务器只是状态挂掉了，再次重启主服务器，又回到主服务位置。

1.6、反客为主

将主服务器挂掉

-- 主服务器挂掉 --
127.0.0.1:6379> shutdown

把从服务器上位为主服务器

-- 把从服务器上位为主服务器 --
127.0.0.1:6380> slaveof no one
OK

-- 6381从服务器挂上6380服务器 --
127.0.0.1:6381> slaveof 127.0.0.1 6380
OK

1.7、哨兵模式（sentinel）

是一种容灾方案。以上主服务器挂了，虽然从服务器变成了主服务器，但是有一个问题，是手动变成服务器

哨兵：实则是一个在特殊模式下的Redis服务器，里面存储的是自己本身的信息，主服务器的信息，从服务器的信息。

用一个或者多个哨兵来监视主服务器（也就是进行写操作的服务器）是否在正常执行任务，一旦哨兵发现主服务器不可用时，就找到一个合适的从服务器成为主服务器。

恢复到6379位主服务器，6380、6381位从服务器的状态

在当前myredis目录下创建 sentinel.conf 文件，名字不要写错,配置如下

sentinel monitor mymaster 127.0.0.1 6379 1

mymaster为监控对象起的服务器名字，1 只要有一个哨兵认为master宕机就可以切换，同时会选举1个哨兵进行迁移的数据

启动哨兵模式

[root@localhost myredis]# redis-sentinel sentinel.conf

把主服务器6379服务器 shutdown , 查看哨并是否会自动把从服务器变成主服务器

-- 主服务器 shutdown 宕机 --
127.0.0.1:6379> SHUTDOWN

-- 只剩下6380和6381--
[root@localhost myredis]# ps -ef|grep redis
root 5209 1 0 06:10 ? 00:00:10 redis-server 127.0.0.1:6380
root 5243 1 0 06:10 ? 00:00:10 redis-server 127.0.0.1:6381
yanqi 6597 5400 0 07:36 pts/2 00:00:00 redis-cli -p 6380
yanqi 6598 5327 0 07:36 pts/1 00:00:00 redis-cli -p 6381
root 7279 7080 0 08:07 pts/3 00:00:00 redis-sentinel *:26379 [sentinel]
root 7333 3992 0 08:10 pts/0 00:00:00 grep --color=auto redis

此时哨兵会检测到主服务器宕机，会再选择一个从服务器上位主服务器

2、Redis集群

2.1、什么是集群

如果说主从复制是各司其职的话，那么集群就是一群同样的个体做着同样的事情。在Redis中，数据的写入操作次数很大的情况下，只使用单独一个服务器来进行写入操作的话，效率不高，那么如果使用集群方案,利用多个Redis服务器来进行写操作，大量的数据，你写一点，我写一点，大家都分担一点，那么效率会高很多。就像工地上搬砖，一个人搬肯定效率非常慢，但是叫来十几个人一起搬，用不了多少时间就会被搬空，人越多效率越高，也就是说我们数据容量大大提升了！

集群模式的思想可以在多处使用。总之就是，一个个体完成不了或者说效率很低的场景下，都可以使用这种思想。

2.2、什么是redis集群

Redis-Cluster的概念 Redis-Cluster采用无中心结构，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
数据分散存储 Redis 集群并没有使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽（hash slot）的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。
Redis 是在内存中保存数据的，而我们的电脑一般内存都不大，这也就意味着 Redis 不适合存储大数据，适合存储大数据的是 Hadoop 生态系统的 Hbase 或者是 MogoDB。Redis 更适合处理高并发，一台设备的存储能力是很有限的，但是多台设备协同合作，就可以让内存增大很多倍，这就需要用到集群。

Redis 集群搭建的方式有多种，例如使用客户端分片、Twitter开发的Twemproxy、豌豆荚开发的Codis 等，但从 redis 3.0 之后版本支持 redis-cluster 集群，它是 Redis 官方提出的解决方案， Redis-Cluster 采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。

2.3、Redis集群中的哈希槽

Redis集群中引入了哈希槽的概念，Redis集群有16384个哈希槽，进行set操作时，每个key会通过CRC16校验后再对16384取模来决定放置在哪个槽，搭建Redis集群时会先给集群中每个master节点分配一部分哈希槽。比如当前集群有3个master节点，

master1节点包含0~5500号哈希槽， master2节点包含5501~11000号哈希槽， master3节点包含11001~16384号哈希槽，

当我们执行“set key value”时，假如 CRC16(key) % 16384 = 777，那么这个key就会被分配到master1节点上，如下图

2.4、Redis集群中节点的通信

既然Redis集群中的数据是通过哈希槽的方式分开存储的，那么集群中每个节点都需要知道其他所有节点的状态信息，包括当前集群状态、集群中各节点负责的哈希槽、集群中各节点的master-slave状态、集群中各节点的存活状态等。Redis集群中，节点之间通过建立TCP连接，使用gossip协议来传播集群的信息。如下图：

2.5、如何判断某个节点挂掉

首先要说的是，每一个节点都存有这个集群所有主节点以及从节点的信息。它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应，集群就认为这个节点宕机了，然后去连接它的备用节点。

3、缓存穿透

3.1、缓存穿透概述

缓存穿透是指缓存和数据库中都没有的数据，这样每次请求都会去查库，不会查缓存，如果同一时间有大量（高并发）请求进来的话，就会给数据库造成巨大的查询压力，甚至击垮数据库。

3.2、解决方案

1、对空值缓存：如果一个查询返回的数据为空，不管数据是否存在，我们仍然把这个空值作缓存，设置空值的过期时间很短。

2、设置访问的白名单：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps偏移的量，每次访问和bitmaps有id进行对比，如果不存在就拦截，不允许访问

3、布隆过滤器：布隆过滤器底层使用bit数组存储数据，该数组中的元素默认值是0。布隆过滤器第一次初始化的时候，会把数据库中所有已存在的key，经过一些列的hash算法（比如：三次hash算法）计算，每个key都会计算出多个位置，然后把这些位置上的元素值设置成1。之后，有用户key请求过来的时候，再用相同的hash算法计算位置。

如果多个位置中的元素值都是1，则说明该key在数据库中已存在。这时允许继续往后面操作。
如果有1个以上的位置上的元素值是0，则说明该key在数据库中不存在。这时可以拒绝该请求，而直接返回。

其实，布隆过滤器最致命的问题是：如果数据库中的数据更新了，需要同步更新布隆过滤器。但它跟数据库是两个数据源，就可能存在数据不一致的情况。

比如：数据库中新增了一个用户，该用户数据需要实时同步到布隆过滤。但由于网络异常，同步失败了。

这时刚好该用户请求过来了，由于布隆过滤器没有该key的数据，所以直接拒绝了该请求。但这个是正常的用户，也被拦截了。

很显然，如果出现了这种正常用户被拦截了情况，有些业务是无法容忍的。所以，布隆过滤器要看实际业务场景再决定是否使用，它帮我们解决了缓存穿透问题，但同时了带来了新的问题。

4、缓存击穿

4.1、缓存击穿概述

有时候，我们在访问热点数据时。比如：我们在某个商城购买某个热门商品。为了保证访问速度，通常情况下，商城系统会把商品信息放到缓存中。但如果某个时刻，该商品到了过期时间失效了。此时，如果有大量的用户请求同一个商品，但该商品在缓存中失效了，一下子这些用户请求都直接到了数据库，可能会造成瞬间数据库压力过大，而直接挂掉。

4.2、解决方案

1、设置热点数据永不过期。（也是一种解决方式，但是实际过程中不推荐）

2、加锁的方式：锁的对象就是key，这样，当大量查询同一个key的请求并发进来时，只能有一个请求获取到锁，然后获取到锁的线程查询数据库，然后将结果放入到缓存中，然后释放锁，此时，其他处于锁等待的请求即可继续执行，由于此时缓存中已经有了数据，所以直接从缓存中获取到数据返回，并不会查询数据库。也就是加锁让一个人去查询数据并把数据存储到缓存中，其他人再查询的时候就直接从缓存中获取了。

5、缓存雪崩

5.1、缓存雪崩概述

缓存雪崩是指当缓存中有大量的key在同一时刻过期，或者Redis直接宕机了，导致大量的查询请求全部到达数据库，造成数据库查询压力骤增，甚至直接挂掉。

5.2、解决方案

给不同的key的TTL添加随机值，避免大量的key同时到期
利用Redis集群提高服务的可用性，避免Redis服务宕机后的数据丢失和请求直达数据库
给缓存业务添加降级限流策略
给业务添加多级缓存

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。

THE END

redis 数据库

二维码

第十四届蓝桥杯（web应用开发）模拟赛2期 -大学组

< <上一篇

Android APN的配置和加载

下一篇>>

搜索内容

Redis进阶（主从复制、Redis集群、缓存穿透、缓存击穿、缓存雪崩）

1、主从复制（读写分离）

1.1、什么是主从复制

1.2、主从复制的作用

1.3、环境搭建