Redis看这一篇就够了

Redis入门

redis是什么?

redis(Remote Dictionary Server),远程服务字典。

是一个开源的使用c语言编写的，支持网络， 可基于内存也可以持久化的日志型，Key-Value数据库，并提供多种语言的API。

Redistribution能干嘛

1. 内存存储，持久化（rdb,aof）
2. 效率高，可以用于高速缓存
3. 发布订阅系统
4. 地图信息分析
5. 计时器，计数器（浏览量）
6. 。。。

特性

1. 多样的数据类型
2. 持久化
3. 集群
4. 事务
5. …

基础知识

redis有16个数据库，默认使用的是第0个，可以使用select进行切换

select 3 #切换数据库
DBSIZE #查看数据库大小
set key value #存储key，value
get key #获得value
keys * #查看所有的key
flushds #清空当前库
flushall #清空所有库
EXIST key #查看key是否存在
incr key #value自增1
decr key #value自减1
INCRBY key 10 #value自增10
DECRBY key 10 #value自减10
setex key seconds value #设置过期时间
setnx key value #如果key没有存在则设置成功，如果存在则设置不成功，一般用在分布式锁中
mset #设置多个值
mget #获取多个值，是一个原子性的操作，要么都成功，要么都失败

#对象
set user:1 {name:lc,age:23} #设置一个user:1 对象为josn字符串
#这里的key是一个巧妙地设计 user:{id}:{filed} ,如此设计在redis中是完全ok

#getset #先get再set，

redis是单线程的

redis是很快的，是基于内存操作的，cpu不是性能瓶颈，redis的瓶颈是根据机器的内存和网络的带宽，既然可以使用单线程来实现，就使用单线程了。

redis是C语言写的，官方提供的数据为100000+的QPS，这个不比Memecache差！

redis为什么单线程还这么快？

1. 高性能的服务器一定是多线程的？ 不是

2. 多线程（cpu上下文会切换）一定比单线程效率高？ 不是

   核心“redis是将所有的数据全部放在内存中的，所以说使用单线程去操作效率就是最高的。多线程cpu会上下文切换，比较耗时。对于内存系统来说，如果没有上下文切换，效率就是最高的。多次读写都是在一个cpu上的，在内存情况下，这个就是最佳方案。

Redis的五大数据类型

String（字符串）

字符串

APPEND key value #在key的value后面追加字符串value，如果不存在就相当于set
STRLEN key #获取key的长度
GETRANGE key 0 3 #截取0-3的字符串
GETRANGE key 0 -1 #截取所有的字符串
SETTANGE key 1 xxxx #替换从指定位置开始的字符串

List（列表）

基本的数据类型，列表

在redis中，我们可以把list玩成，栈，队列，阻塞队列

所有的list命令都是l开头的

lpush key value #将一个值，或者多个值，插入到列表的头部（就是例表的左边）
rpush key value #将一个值，或者多个值，插入到列表的尾部（就是列表的右边）
lrange key start end #通过区间来获取具体的值
lpop key #移除最左边的元素
rpop key #移除最右边的元素
lindex key index #通过下标获取list中的某一个值
lrem key count value #移除集合中指定个数的值
ltrim key start end #通过下标截取指定的长度，这个list已经被改变了，只剩下截取的元素了。 
rpoplpush list1 list2 #将list1中的最后一个元素，移到list2中去
lset key index value #将指定元素的值设为新值，如果没有即报错
linsert key before|after value newvalue #将新的元素插入到指定元素的前面或者后面

它实际上是一个链表，before node after，left，right都可以插入值

如果key不存在，创建新的链表

如果keyv存在，新增内容

如果移除了所有制，空链表，也代表不存在

在两边插入或者改动值，效率最高，中间元素，效率会低一点

可以实现，消息排队，消息队列 lpush rpop

Set（集合）

set的值不可以重复

#set的命令都是s开头的

sadd key value #set集合中添加元素
smembers key #获取当前key中的所有元素
sismember key value #判断当前元素是否为key中的元素。
scard key #获取当前集合中的个数
srem key value #移除当前集合中的元素
srandmember key #随机获取当前集合中的一个元素
srandmember key 2 #随机获取当前集合中的两个元素
spop key #随机删除set集合中的元素
smove key1 key2 value #将set1集合中的value移动到key2中
sdiff key1 key2 #计算两个集合的差集
sinter key1 key2 #计算两个集合的交集
sunion key1 key2 #计算两个集合的并集

微博将一个用户所有关注的人放在一个set中，将他的粉丝也放在一个set中

共同关注，共同爱好，二度好友，推荐好友

Hash（哈希）

Map集合，key-map集合，本身和string类型没有多大区别，还是一个简单的key-value

hset key field value #hash中添加元素
hget key field #获取key中的field元素
hmset key field2 value1 field2 value2 #同时存入多个值
hmget key field1 field2 #同时获取读个元素
hgetall key #获取当前hash中的所有元素
hdel key field #删除指定的hash，对应的value值也消失
hlen key #获取hash表的字段数量
hexist key field #判断hash中的指定字段是否存在
hkeys key #获得当前hash中的所有key
hvalues key #获取当前hash中的所有value
hincr key field # 当前hash中的key对应的value自增1
hdecr key field # 自减
hincrby hdecrby # 指定增量
hsetnx key field value #如果存在就可以设置，如果不存在就不能设置

hash可以存一些变更的数据，尤其是用户的信息，经常变动的信息。hash更适合于对象的存储，String更适合字符串的存储

Zset

在set得基础上，增加了一个值

zadd key k1 v1 # 添加一个值
zadd key k1 v1 k2 v2 #添加多个值
zrange key #获取值
zrangebyscore key -inf +inf #从k的最小值到最大值对v排序 -inf +inf为显示的区间
zrangebyscore key -inf +inf withscores #输出格式带着k
zrem key value # 移除有序集合中的指定元素
zcard key # 查看当前集合总的总元素 
zrevrange key start end # 从大到小排序
zcount key start end #获取指定区间的元素个数

案例：

set排序，存储班级成绩，工资表排序，带权重排序。

排行榜应用实现

三种特殊的数据类型

geospatial（地理位置）

朋友的定位，附近的人，打车距离计算？

redis的Geo，在3.2版本已经推出这个功能可以推算地理位置信息，两地之间的距离，方圆几里的人。

只有6个命令

# 两级无法添加，一般用Java程序导入 有效的经度从-180到180，有效的纬度从-85.05112878到85.05112878
getadd key 经度 纬度 城市名 #添加地理位置
getpos key value #获取指定城市的地理位置
geodist key value1 value2 #获取两个城市之间的距离，默认为米
georadius key 经度 维度 半径 [withdist(输出到中心位置距离信息)] [withcoord(输出周围的人的经纬度信息)] [count(获得指定数量的人)] #以给定的经纬度为中心，找出某一半径内的元素
georadiusbymember key city 距离 #找出以当前city为中心的指定距离以内的元素
geohash key city #将二维的经纬度转换为一维的字符串。两个字符串越接近，那么则距离越近

geo底层实现的原理其实就是zset，我们可以使用zset来操作geo

hyperloglog

什么是基数？

A {1,2,5,7,8,7}

B {1,3,5,7,8,}

基数 -> 5 可以接受误差

Redis 2.8.9更新了Hyperloglog数据结构

Hyperloglog 基数统计的算法

优点：占用的内存是固定的，2^64不同的元素的基数，只需要12KB内存。

网页的uv（一个人访问网站多次，但是还是算作一个人）

传统方式，set保存用户的id，然后就可以统计set中的元素数量，做为标准判断。这个方式如果保存大量的用户id，就比较麻烦！我们的目的是为了计数，而不是保存用户id，

pfadd key value value ... #创建
pfcount key #统计基数
pfmerge key3 key1 key2 #将两个基数合并为key3

如果允许容错一定可以使用hyperloglog，不允许容错，就是用set或其他数据类型。

bitmaps

位存储

统计用户信息，活跃，不活跃！登录，未登录！

所有的东西都是操作二进制位进行记录，就只有0和1两个状态。

setbit key 位置 0|1 # 设置每个位置的状态
getbit key 位置 # 查看位置的状态
bitcount key # 统计为1的次数

事务

redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，在事务执行的过程中，会按照顺序执行。

一次性，顺序性，排他性

-------队列 set set set 执行-----

Redis事务没有隔离级别的概念。所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行。

Redis单条命令保证原子性，但是事务不保证原子性。

redis的事务

正常执行事务

​ 开启事务（multi）

​ 命令入队（…）

​ 执行事务（exec）

放弃事务

​ discard

编译型异常（代码有问题！命令有错！）事务中的所有命令都不会被执行

运行时异常，如果队列中存在语法性错误，那么执行命令的时候，其他命令是可以正常执行的。

监控！watch

悲观锁：

​ 很悲观，什么时候都会出问题，无论做什么都会加锁

乐观锁：

​ 认为什么时候都不会出现问题，无论做什么都不会加锁。更新数据时去判断下，在此期间是否有人修改过数据，version。

​ 获取version

​ 更新的时候比较version

Redis的监控

多线程修改值，使用watch可以当作redis的乐观锁操作。

watch key # 监视当前key
# 执行之前，另外一个线程修改了当前值，会导致事务执行失败。
unwatch # 解锁

多线程修改解决办法

1. 如果发现事务执行失败，就先解锁
2. 获取最新的值，再次监控
3. 比对监视的值是否发生变化，如果没有变化，那么可以执行成功，如果变了就执行失败。失败就继续获取最新的值

Jedis

什么是Jedis？

​ Jedis是Redis官方推荐的Java连接开发工具！使用Java操作Redis中间件！如果要使用Java操作Redis那么一定要对Jedis十分的熟悉！

测试

1. 导入对应的依赖
2. 编码测试
   1. 连接数据库
   2. 操作命令
   3. 断开连接

Springboot整合

在springboot2.x之后，原来使用的jedis被替换为了lettuce

jedis：采用的直连，多个线程操作是不安全的，如果想要避免线程不安全，使用jedis pool连接池 更像BIO模式

lettuce：采用的netty，实例可以在多个线程中进行共享，不存在线程不安全的情况。可以减少线程数量，更像NIO模式

源码分析

 @Bean
    @ConditionalOnMissingBean(
        name = {"redisTemplate"}
    )
   //我们可以自己自定义一个redisTemplate来替换这个默认的 @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public RedisTemplate<Object, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 默认的RedisTemplate 没有过多的设置，Redis 对象都是需要序列化的
        // 两个泛型都是object，object的类型，我们使用需要强制转换<String,Object>
        RedisTemplate<Object, Object> template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

    @Bean
    @ConditionalOnMissingBean
   // 由于String了类型是最常使用的类型，所以说单独提出来了一个Bean @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public StringRedisTemplate stringRedisTemplate(RedisConnectionFactory redisConnectionFactory) {
        StringRedisTemplate template = new StringRedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);
        return template;
    }

整合测试

1. 导入依赖
2. 配置连接
3. 测试

编写自己的RedisTemplate

 @Bean
    @SuppressWarnings("all")
    //我们可以自己自定义一个redisTemplate来替换这个默认的 @ConditionalOnSingleCandidate(RedisConnectionFactory.class)
    public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory redisConnectionFactory) {
        // 默认的RedisTemplate 没有过多的设置，Redis 对象都是需要序列化的
        // 两个泛型都是object，object的类型，我们使用需要强制转换<String,Object>

        RedisTemplate<String, Object> template = new RedisTemplate();
        template.setConnectionFactory(redisConnectionFactory);

        //json序列化操作
        Jackson2JsonRedisSerializer<Object> objectJackson2JsonRedisSerializer = new Jackson2JsonRedisSerializer<Object>(Object.class);
        ObjectMapper  om = new ObjectMapper();
        om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY);
        om.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);
        objectJackson2JsonRedisSerializer.setObjectMapper(om);

        //String的序列化
        StringRedisSerializer stringRedisSerializer = new StringRedisSerializer();

        //配置序列化的方式
        template.setKeySerializer(stringRedisSerializer);
        template.setHashKeySerializer(stringRedisSerializer);
        template.setValueSerializer(objectJackson2JsonRedisSerializer);
        template.setHashValueSerializer(objectJackson2JsonRedisSerializer);
        template.afterPropertiesSet();

        return template;
    }

Redis.conf详解

启动的时候，就通过配置文件来启动

1. 配置文件unit单位对大小写不敏感

2. 可以包含多个配置文件

   # include /path/to/local.conf
   # include /path/to/other.conf
   

3. 网络

   bind 127.0.0.1 #绑定的IP
   protected-mode yes #保护模式
   port 6379 #端口设置
   

4. 通用配置

   daemonize yes # 守护进程
   pidfile /var/run/redis_6379.pid # 如果以后台方式运行需要制定pid文件
   
   # 日志
   # Specify the server verbosity level.
   # This can be one of:
   # debug (a lot of information, useful for development/testing)
   # verbose (many rarely useful info, but not a mess like the debug level)
   # notice (moderately verbose, what you want in production probably)
   # warning (only very important / critical messages are logged)
   loglevel notice
   
   logfile "" #日志的文件名
   databases 16 #数据库的数量，默认16个
   always-show-logo yes # 是否显示logo
   

5. 持久化

   redis是内存数据库，如果没有持久化，那么数据断电即失。

   持久化，在规定时间内，执行了多少次操作，则会持久化到文件.rdb .aof

   # 900s内，如果至少有1个key进行了修改，那么我们就进行持久化操作，下同
   save 900 1 
   save 300 10
   save 60 10000
   # 我们之后学习持久化，会自己定义这个测试
   
   stop-writes-on-bgsave-error yes # 持久化出错是否继续工作
   rdbcompression yes # 是否压缩rdb文件，需要消耗cpu资源
   rdbchecksum yes  # 是否校验rdb文件
   dir ./ # rdb目录
   

6. SECURITY

   config set requirepass #获取redis的密码
   auth "password" # 使用密码登录
   

7. 限制

    maxclients 10000 #设置连接上redis的最大客户端数量
    maxmemory <bytes> # redis默认最大的内存容量配置
    maxmemory-policy noeviction # 内存达到上限后的处理策略
    	# 移除一些过期的key
   

8. APPEND ONLY模式 aof配置

   appendonly no # 默认不开启aof模式，默认是rdb方式
   ppendfilename "appendonly.aof" # 持久化默认文件名
   
   # appendfsync always # 每次修改都会sync，消耗性能
   appendfsync everysec # 每秒执行一次sync，可能或丢失1s数据
   # appendfsync no # 不执行sync，这个时候操作系统自己同步数据，速度最快
   

Redis持久化

​ Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘，那么一旦服务器进程退出，服务器中的数据库状态也会消失，所以redis提供了持久化功能。

RDB(Redis DataBase)

什么是RDB？

​ 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存中。

​ Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何io操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，但对于数据回复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。我们默认的就是RDB，一般情况下不需要修改这个配置。

在主从复制中，rdb是来备用的。

rdb保存的文件时dump.rdb 是在我们的配置文件快照中进行配置的

触发机制

1. save规则满足的情况下，会触发rdb规则。

2. 执行flushall命令，也会触发我们的rdb规则。

3. 退出redis，也会产生rdb文件。

   备份就会自动生成dump.rdb文件

有时候我们在生产环境会将这个文件备份。

如何恢复rdb文件？

​ 只需要将rdb文件放在我们的redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据

查看需要存在的位置

config get dir

优点：

1. 适合大规模数据的恢复

2. 对数据的完整性要求不高

缺点:

1. 需要一定的时间间隔进行操作，如果redis意外宕机，最后一次修改的数据就没有了

2. fork进程的时候，会占用一定的内容空间。

AOF（Append Only File）

​ 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据集的恢复工作。

aof默认是文件的无限追加，文件会越来越大。

如果aof文件大于64m，太大了，fork一个新的进程来将我们的文件进行重写。

AOF保存的是appendonly.aof文件

​ 默认是不开启的，我们需要手动修改配置文件进行配置。我们只需要将appendonly改为yes就开启了。

​ 重启redis就可以生效了。

​ 如果aof文件有错误，这时候redis是启动不起来的，我们需要修复这个aof文件，redis给我们提供了一个工具，redis-check-aof --fix

优点：

1. 每次修改都同步，文件的完整性更好

2. 每秒同步一次，可能会丢失一秒数据
3. 从不同步的话，效率最高

缺点：

​ 1.相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢

​ 2. aof以运行效率也比rdb慢。

扩展：

RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储

AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对aof文件进行后台重写，使得aof文件的体积不至于过大。

只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不适用任何持久化

同时开启两种持久化方式。

​ 在这种情况下，redis重启的时候会优先载入aof文件来恢复原始的数据，因为在通常情况下aof文件保存的数据集要比rdb文件保存的数据集完整。

​ rdb的数据不实时，同时使用两者时服务器重启也只会找aof文件，那要不要只是用aof呢？不要，因为rdb更适合用于备份数据库（aof在不断变换不好备份），快速重启，而且不会有aof可能潜在的bug，留着作为一个万一的手段。

性能建议

1. 因为rdb文件只用作后被用途，建议直在Slave上持久化rdb文件，而且只要15分钟备份一次就够了，只保留save 900 1这个规则。
2. 如果Enable AOF好处是在最恶劣的情况下也只会丢失不超过两秒的数据，启动脚本较简单，只load自己的aof文件就可以了，代价是带来了持续的io，二是aof rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少aof rewrite的频率，aof重写的基础大小默认值为64m太小了，可设置到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
3. 如果Enable AOF仅靠Master-Slave Replication实现高可用性也可以，能省下一大笔io，也减少了rewrite时带来的系统波动。代价是如果master/slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个master/slave中的rdb文件，载入较新的那个，微博就是这个架构。

Redis发布订阅

Redis发布订阅是一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息

Redis客户端可以订阅任意数量的频道

第一个：消息发送者 第二个：频道 第三个：消息订阅者

命令：

psubscribe pattern [pattern] #订阅一个或多个符合规定模式的频道
pubsub subcommand [argument] #查看订阅与发布系统状态
publish channel message # 将消息发送到指定的频道
punsubscribe [pattern] # 退订所有给定模式的频道
subscribe channel [channel] #订阅给定的一个或多个频道的信息
unsubscribe [channel] # 只退定给定的频道

测试:

订阅端：

subscribe lucy # 订阅一个频道

发送端：

publish lucy "hello world" # lucy频道发送一个消息

​ 原理：通过subscribe命令订阅谋频道后，redis-server里维护了一个字典，字典的键就是一个个频道，而字典的值则是一个链表，链表中保存了所有订阅和这个channel的客户端。subscribe命令的关键，就是将客户端添加到给定的channel订阅链表中。

​ 通过publish命令向订阅者发送消息，redis-server会使用给定的频道作为键，在它维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发给所有订阅者。

​ pub/sub从字面上理解就是publish与subscribe，在Redis中，你可以设定对某一个key值进行消息发布及消息订阅，当一个key值上进行了消息发布以后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。

使用场景

1. 实时消息系统

2. 实时聊天

3. 订阅，关注系统都是可以的

   复杂场景会使用中间件。

Redis主从复制

​ 主从复制，是指将一台redis服务器的数据，复制到其他的redis服务器。前者称为主节点，后者称为从节点，数据的复制是单项的，只能由主节点到从节点。Master以写为主，Slave以读为主。

​ 默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点，但一个从节点只能有一个主节点。

主从复制的作用主要包括;

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式

2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器均衡；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高redis服务器的并发量。

4. 高可用基石：除了上述作用以外，主从复制还是哨兵集群能够实施的基础，因此说主从复制是redis高可用的基础。

一般来说，要将redis运用于工程项目中，只使用一台redis是万万不能的，原因如下：

1. 从结构上，单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大
2. 从容量上，单个redis服务器内存容量有限，就算一个redis服务器的内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台redis最大使用内存应该不超过20G。

主从复制是项目中必须使用的。

环境配置

只配置从库不配置主库。

info replication # 查看当前库的信息

配置过程

复制三个配置文件，然后修改对应的信息

1. 修改端口
2. 修改pidfile
3. 修改logfile
4. 修改rdb文件

修改完毕之后，启动三个redis服务

一主二从

默认情况下，每一台无服务器都是主节点，我们一般情况下只配从机就可以了。

slaveof ip+端口号 # 配置当前服务器的主机 

真实的主从配置应该在配置文件中配置，这样的话是永久的，命令是暂时的

修改配置文件中的Replication将主节点的host和端口号填写进去

细节

主机可以写，从机不能写。

主机断开连接，从机依旧连接到主机，但是没有写操作了，这个时候主机如果回来了，从机依旧能获得主机写的数据。

如果是使用命令行来配置的主从，这个时候如果重启，就会变回主机。只要变回从机，立马会从主机中获取值

复制原理

Slave启动成功连接到一个master后会发送一个sunc同步命令

Masster接到命令，启动后台的存盘进程，同时收起所有接收到的用于修改数据集命令，在后台进程执行完毕以后，master将传送整个数据文件到slave，并且完成第一次同步

全量复制：而slave服务器在接收到数据库文件数据后，将其存盘并加载到内存中。

增量复制：Master继续将新的所有收集到的修改命令依次传递给slave，完成同步。

但是只要是重新连接master，一次完全同步，将被自动执行。我们的数据一定可以在从机中看到。

链路模型

上一个master连接下一个slave。

这个时候也可以完成我们的主从复制。

如果主节点宕机，能不能选择出一个主节点？

slaveof no one # 如果主机断开了连接，我们可以使用该命令使自己变成主节点

哨兵模式（自动选取master）

概述：

​ 主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间的服务不可用，这不是一种推荐的方式，更多时候我们优先考虑哨兵模式。Redis从2.8开始正式提供了哨兵架构来解决这一问题。

​ 谋朝篡位的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

​ 哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，他会独立运行。其原理是哨兵通过发送命令，等待redis服务器响应，从而监控运行的多个redis实例。

这里的哨兵有两个作用

• 通过发送命令，让redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他从服务器，修改配置文件内容，让他们切换主机。

然而一个哨兵进程对redis服务器进行监控，可能会出现问题，为此我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观认为主服务器不可以用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover故障转移操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线

1. 哨兵配置文件 sentinel.conf

sentinel monitor 被监控的名称 ip+端口 1
# 后面的数字1，代表主机挂了，slave投票看让谁接替为主机，票数最多的就会称为主机。

2. 启动哨兵

redis-sentinel sentinel配置文件

如果master节点款开了，这个时候就会从从机中随机选择一个服务器作为master。如果主机此时回来了，只能归并到新的主机下，当作从机。

优点：

1. 哨兵模式，基于主从复制模式，所有的主从配置优点它全都有。
2. 主从可以切换，故障可以转移，系统的可用性就会更好。
3. 哨兵模式就是主从模式的升级，手动到自动，更加健壮。

缺点：

1. Redis不好在线扩容，集群容量一旦到达上限，在线库容就十分麻烦了

2. 实现哨兵模式的配置，其实是很麻烦的，里面有很多选择。

Redis缓存穿透和雪崩

​ redis缓存的使用，极大的提升了应用程序的性能和效率，特别是数据查询方面。但同时他也带来了一些问题，其中，最要害的问题，就是数据的一致性问题，从严格意义上讲，这个问题无解，如果对数据的一致性要求很高，那么就不能使用缓存。

另外的一些典型问题就是，缓存穿透，缓存雪崩和缓存击穿。目前，业界也都有流行的解决方案。

缓存穿透（查不到）

​ 缓存穿透的概念很简答，用户想要查询一个数据，发现redis内存数据库没有，也就是缓存没有命中，于是向持久层数据库查询。发现也没有。于是本次查询失效。当用户很多的时候，缓存都没有命中。于是都去请求了持久层数据库。这会给持久层数据库造成很大的压力，这就相当于出现了缓存穿透。

解决方案

布隆过滤器

​ 布隆过滤器是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进性校验，不符合则丢弃，从而避免了对底层存储系统的查询压力。

缓存空对象

当存储层不命中后，及时返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

但是这种方法会存在两个问题

1. 如果控制能够被缓存起来，这就意味着缓存需要更多的空间存储更多的键，因为这当中可能会有很多的空值的键。
2. 即使对空值设置了过期时间，还是会存在缓存层和存储层的数据会有一段时间的不一致，这对于需要保持一致性的业务会有影响。

缓存击穿（并发量大，缓存过期）

这里需要注意和缓存击穿的区别，缓存击穿是指一个key非常热点，在不停的扛着大并发，大并发集中对于这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在屏障上凿开了一个洞。

当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过去，会同时访问数据库来查询最新数据，并且回写缓存，会导致数据库瞬间压力过大。

解决方案

设置热点数据永不过期

从缓存层面来看，没有设置过期时间，所以不会出现热点key过期后产生的问题。

加互斥锁

分布式锁：使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考验很大。

缓存雪崩

缓存雪崩，是指在某一个时间段，缓存集中过期失效。redis宕机。

产生雪崩的原因之一，比如双11，很快迎来一波抢购，这波商品比较集中的放入了缓存，假设缓存一个小时，那么到了凌晨一点的时候，这批商品的缓存就要过期了。而对这批商品的访问查询，都会落到数据库中，对于数据库而言，就会产生周期性的压力波峰。于是所有的请求都会到达存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。

其实集中过期，倒不是非常致命，比较致命的缓存雪崩，是缓存服务器的某个节点宕机或者断网。因为自然形成的缓存雪崩，一定是在某个时间段集中创建缓存，这个时候，数据库也是可以顶住的。无非就是对数据库产生周期性的压力而已，而缓存服务节点的宕机，对数据库服务器造成的压力是不可预知的，很有可能瞬间就把服务器压垮。

解决方案

redis高可用

这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis。搭建集群

限流降级

这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

数据预热

数据加热的含义就是在正式部署之前，我先把可能的数据先预访问一遍，这样部分可能大量访问的数据就会加载到缓存中，在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。