Redis的键值设计原则

key键格式

我们之前都是使用简单的key存储，如存储string类型的name为zhangsan，此时普通的需求可以满足，然而在实际业务中，往往key键的存储会非常的复杂，比如我们现在有一个需求：

需求：根据基础数据系统中的数据字典类型查询对应的字典集合

这时，我们需要关注的业务就变得复杂了，就不能使用常规的key键存储方式，上面的需求大致可以拆分为：

系统：基础数据系统
模块：数据字典
方法：根据数据字典类型查询
参数：字典类型

为什么要这样拆分呢？为了可读性；也为了抽象出key存储规则；因为业务复杂情况下，我们定义的key键太多时就不便于管理，也不便于查找，以 系统-模块-方法-参数 这样的规则定义，我们可以很清晰的了解redis key存储的值是做了什么事情

common:sys:sex:1 男
common:sys:sex:0 女
common:page:title 欢迎使用XX管理系统
user:1  {id:1.name:小明}
user:2  {id:2.name:习大大}

这个在使用Redis Desktop Manager工具去查看的时候就可以看出层级关系。

value值格式

在Java常规开发中，我们需要有面向对象的思想，相对于对象来说，比较常用且能快速转换的格式就是 JSON 了；比较常用的Java处理JSON数据有三个比较流行的类库FastJSON、Gson和Jackson。

上面提到了JSON，这是因为在Redis的存储中，我们使用它来存储value值，为什么要这样做呢？主要是因为json格式有如下几种好处：

标准，主流数据交换格式
简单，结构清晰，相对于XML来说更加的轻量级，易于解析
语言无关，任何语言都能轻松搞它
类型安全，值是有类型的，比如整数、字符串、布尔等

代码中redis value在存储前我们对其做了一次转换，将对象Value转换为json对象后存储，也就是一个key对应一个json串。

Redis常见面试

Redis支持的数据类型

1、String（字符串）

String数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。常规key-value缓存应用；常规计数：微博数，粉丝数等。

常用命令: set,get,incr,decr,mget 等
set key value #设置值
get key #获取值
incr key #加一
decr key #减一

2、hash（哈希）

Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。

常用命令: set,get,decr,incr,mget 等
hset key field value #设置值
hget key field #获取值
hincrby key field num #设置增数量

3、list（列表）

Redis list 的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销。

Redis list 的应用场景非常多，也是Redis最重要的数据结构之一，比如微博的关注列表，粉丝列表，消息列表等功能都可以用Redis的 list 结构来实现。

可以通过 lrange 命令，就是从某个元素开始读取多少个元素，可以基于 list 实现分页查询，这个很棒的一个功能，基于 redis 实现简单的高性能分页，可以做类似微博那种下拉不断分页的东西（一页一页的往下走），性能高。

常用命令: lpush,rpush,lpop,rpop,lrange等
lpush list a b c d #从list左边添加元素
rpush list 1 2 3 4 #从list右边添加元素
lrange list 0 -1 #从0 到 -1 元素查看：也就表示查看所有
lpop list #从list左边取，删除
rpop list #从list右边取，删除

4、set（集合）

Redis的Set是string类型的无序集合。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。

常用命令： sadd,spop,smembers,sunion 等
sadd set1 a b c d d #向set1中添加元素，元素不重复
smembers set1 #查询元素
srem set1 a #删除元素
sorted set（zset，有序集合）

5、zset（排序集合）

和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列。

例：在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜，弹幕消息（可以理解为按消息维度的消息排行榜）等信息，适合使用 Redis 中的 Sorted Set 结构进行存储。

常用命令： zadd,zrange,zrem,zcard等
#添加元素 zadd key score member，这里添加元素a:1分、元素b:2分、元素c:3分
zadd zset1 1 a 2 b 3 c  
zrange zset1 0 -1 #查看zset1的所有元素，默认从小到大
zrange zset1 0 -1 withscores #查看zset1的所有元素,包括分数score
zrevrange zset1 0 -1 #查看zset1的所有元素，从大到小
zincrby zset1 5 a #对zset1的a元素增加5分

Redis持久化

概念

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。（Redis 数据都放在内存中。如果机器挂掉，内存的数据就不存在。所以需要做持久化，将内存中的数据保存在磁盘，下一次启动的时候就可以恢复数据到内存中。）

方式

Redis 提供了两种持久化方式：RDB（默认）和AOF 。

1、RDB （快照）：Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

快照持久化是Redis默认采用的持久化方式，在redis.conf配置文件中默认有此下配置：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。

2、AOF（只追加文件）：与快照持久化相比，AOF持久化的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：appendonly yes。

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。

在Redis的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

#每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync always

appendfsync everysec #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no #让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项，让Redis每秒同步一次AOF文件，Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

优缺点

RDB （快照）：快照形式，定期将当前时刻的数据保存磁盘中。会产生一个dump.rdb文件，特点：性能较好，数据备份。但可能会存在数据丢失。

AOF（只追加文件）：append only file (所有对redis的操作命令记录在aof文件中)，恢复数据，重新执行一遍即可。特点：每秒保存，数据比较完整。但耗费性能。

【注】如果两个都配了优先加载AOF。（同时开启两个持久化方案，则按照 AOF的持久化放案恢复数据。）

Redis的架构模式

主从模式（Redis2.8版本之前的模式）、哨兵sentinel模式（Redis2.8及之后的模式）、Redis Cluster集群模式（Redis3.0版本之后）。

缓存穿透/缓存雪崩

缓存穿透

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

如何避免？

1、对查询结果为空的情况也进行缓存，缓存时间设置短一点，或者该key对应的数据insert了之后清理缓存。

2、对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中，查询时通过该bitmap过滤。

3、也可以使用流行的bloom filter布隆过滤器。

缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃。