Redis缓存知识总结

一、Redis数据类型  

https://www.cnblogs.com/dijia478/p/8058775.html

Redis常用的五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

Redis3种特殊（不常用）数据类型（BitMap、Geo和HyperLogLog ）

1.1 BitMap：是string类型扩展

bitmap是string类型，单个值最大可以使用的内存容量为512MB

setbit时是设置每个value的偏移量，可以有较大耗时

bitmap不是绝对好，用在合适的场景最好

1.2 HyperLoglog注意事项

使用hyperloglog进行数据统计时，需要考虑三个因素：

是否需要很少的内存去解决问题，

是否能容忍错误

是否需要单条数据

1.3 GEO即地址信息定位
可以用来存储经纬度，计算两地距离，范围计算等

 

1.4 各个数据类型应用场景：

类型	简介	特性	场景
String(字符串)	二进制安全	可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M	---
Hash(字典)	键值对集合,即编程语言中的Map类型	适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去)	存储、读取、修改用户属性
List(列表)	链表(双向链表)	增删快,提供了操作某一段元素的API	1,最新消息排行等功能(比如朋友圈的时间线) 2,消息队列
Set(集合)	哈希表实现,元素不重复	1、添加、删除,查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作	1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐
Sorted Set(有序集合)	将Set中的元素增加一个权重参数score,元素按score有序排列	数据插入集合时,已经进行天然排序	1、排行榜 2、带权重的消息队列

String（字符串）

string 是 redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个 key 对应一个 value。

string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。

string 类型是 Redis 最基本的数据类型，string 类型的值最大能存储 512MB。

实例

redis 127.0.0.1:6379> SET name "runoob"
OK
redis 127.0.0.1:6379> GET name
"runoob"

在以上实例中我们使用了 Redis 的 SET 和 GET 命令。键为 name，对应的值为 runoob。

注意：一个键最大能存储512MB。

Hash（哈希）

Redis hash 是一个键值(key=>value)对集合。

Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。

实例

DEL runoob 用于删除前面测试用过的 key，不然会报错：(error) WRONGTYPE Operation against a key holding the wrong kind of value

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> HMSET myhash field1 "Hello" field2 "World"
"OK"
redis 127.0.0.1:6379> HGET myhash field1
"Hello"
redis 127.0.0.1:6379> HGET myhash field2
"World"

实例中我们使用了 Redis HMSET, HGET 命令，HMSET 设置了两个 field=>value 对, HGET 获取对应 field 对应的 value。

每个 hash 可以存储 232 -1 键值对（40多亿）。

List（列表）

Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。

实例

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> lpush runoob redis
(integer) 1
redis 127.0.0.1:6379> lpush runoob mongodb
(integer) 2
redis 127.0.0.1:6379> lpush runoob rabitmq
(integer) 3
redis 127.0.0.1:6379> lrange runoob 0 10
1) "rabitmq"
2) "mongodb"
3) "redis"
redis 127.0.0.1:6379>

列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。

---

Set（集合）

Redis的Set是string类型的无序集合。

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

sadd 命令

添加一个 string 元素到 key 对应的 set 集合中，成功返回1，如果元素已经在集合中返回 0，如果 key 对应的 set 不存在则返回错误。

sadd key member

实例

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> sadd runoob redis
(integer) 1
redis 127.0.0.1:6379> sadd runoob mongodb
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 1
redis 127.0.0.1:6379> sadd runoob rabitmq
(integer) 0
redis 127.0.0.1:6379> smembers runoob

1) "redis"
2) "rabitmq"
3) "mongodb"

注意：以上实例中 rabitmq 添加了两次，但根据集合内元素的唯一性，第二次插入的元素将被忽略。

集合中最大的成员数为 232 - 1(4294967295, 每个集合可存储40多亿个成员)。

---

zset(sorted set：有序集合)

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。

 

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

zset的成员是唯一的,但分数(score)却可以重复。

zadd 命令

添加元素到集合，元素在集合中存在则更新对应score

zadd key score member 

实例

redis 127.0.0.1:6379> DEL runoob
redis 127.0.0.1:6379> zadd runoob 0 redis
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 mongodb
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 1
redis 127.0.0.1:6379> zadd runoob 0 rabitmq
(integer) 0
redis 127.0.0.1:6379> > ZRANGEBYSCORE runoob 0 1000
1) "mongodb"
2) "rabitmq"
3) "redis"

最后，还有个对key的通用操作，所有的数据类型都可以使用的

 

二、设计一个缓存系统

不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。

1、缓存穿透

缓存穿透是指查询一个一不存在的key对应的数据。例如：从缓存redis没有命中，需要从mysql数据库查询，查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到数据库去查询，造成缓存穿透。请求会穿透到DB，流量大时DB会挂掉。

正常的使用缓存流程大致是，数据查询先进行缓存查询，如果key不存在或者key已经过期，再对数据库进行查询，并把查询到的对象，放进缓存。如果数据库查询对象为空，则不放进缓存。

解决方案

1. 采用布隆过滤器，使用一个足够大的bitmap，用于存储可能访问的key，不存在的key直接被过滤。redis布隆过滤器
2. 访问key未在DB查询到值，也将空值写进缓存，但可以设置较短过期时间。
3. 可以给key设置一些格式规则，然后查询之前先过滤掉不符合规则的Key。

2、缓存雪崩

数据未加载到缓存中，或者缓存同一时间大面积（大部分key）的失效，从而导致所有请求都去查数据库，导致数据库CPU和内存负载过高，甚至宕机。

比如：大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。

比如一个雪崩的简单过程：

1、redis集群大面积故障

2、缓存失效，但依然大量请求访问缓存服务redis

3、redis大量失效后，大量请求转向到mysql数据库

4、mysql的调用量暴增，很快就扛不住了，甚至直接宕机

5、由于大量的应用服务依赖mysql和redis的服务，这个时候很快会演变成各服务器集群的雪崩，最后网站彻底崩溃。

解决方案

可以给缓存设置过期时间时加上一个随机值时间，使得每个key的过期时间分布开来，不会集中在同一时刻失效。

2.1 缓存的高可用性

缓存层设计成高可用，防止缓存大面积故障。即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如 Redis Sentinel 和 Redis Cluster 都实现了高可用。

2.2 缓存降级

可以利用ehcache等本地缓存(暂时使用)，但主要还需要对源服务访问进行限流、资源隔离(熔断)、降级等。

当访问量剧增、服务出现问题仍然需要保证服务还是可用的。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级，这里会涉及到运维的配合。

降级的最终目的是保证核心服务可用，即使是有损的。

比如我的淘宝页面，由于是非核心页面，后端服务如果暂时不能提供使用的情况，可以考虑直接使用一个静态页面替换掉，这样对于用户也是永远提供服务的状态(再发报警信息提示急需解决)，也不至于出现空白或者异常错误的裸奔状态。

在进行降级之前要对系统进行梳理，比如：哪些业务是核心(必须保证)，哪些业务可以容许暂时不提供服务(利用静态页面替换)等，以及配合服务器核心指标，来后设置整体预案，比如：

(1)一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级;

(2)警告：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警;

(3)错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级;

(4)严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

2.3 Redis备份和快速预热

1)Redis数据备份和恢复

2)快速缓存预热

3).提前演练

最后，建议还是在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，对高可用提前预演，提前发现问题。

 

3、缓存击穿

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

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

解决方案

在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。

 

4、缓存并发

这里的并发指的是多个redis的client同时set key引起的并发问题。其实redis自身就是单线程操作，多个client并发操作，按照先到先执行的原则，先到的先执行，其余的阻塞。当然，另外的解决方案是把redis.set操作放在队列中使其串行化，必须的一个一个执行。

5、缓存预热

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。

这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题，用户直接查询事先被预热的缓存数据。

解决思路：

1、直接写个缓存刷新页面，上线时手工操作下。

2、数据量不大，可以在项目启动的时候自动进行加载。

目的就是在系统上线前，将数据加载到缓存中。

 

6、作为一个并发量较大的互联网应用，我们的目标有3个:

      1. 加快用户访问速度，提高用户体验。

      2. 降低后端负载，保证系统平稳。

      3. 保证数据“尽可能”及时更新(要不要完全一致，取决于业务，而不是技术。)

下面方案可以做如下比较，还是那句话：没有最好，只有最合适。 

解决方案	优点	缺点
简单分布式锁(Tim yang)	1. 思路简单 2. 保证一致性	1. 代码复杂度增大 2. 存在死锁的风险 3. 存在线程池阻塞的风险
加另外一个过期时间(Tim yang)	1. 保证一致性	同上
不过期(本文)	1. 异步构建缓存，不会阻塞线程池	1. 不保证一致性。 2. 代码复杂度增大(每个value都要维护一个timekey)。 3. 占用一定的内存空间(每个value都要维护一个timekey)。
资源隔离组件hystrix(本文)	1. hystrix技术成熟，有效保证后端。 2. hystrix监控强大。	1. 部分访问存在降级策略。

 

7、Redis 中的布隆过滤器（布隆算法）

举个列子：

爬虫系统去爬所有网站的数据，在爬的时候怎么知道当前URL已经爬取过了，把已经爬过的记录到数据库或者Set里面？

1：如果历史记录存储在关系数据库里，去重就需要频繁地对数据库进行 exists 查询，当系统并发量很高时，数据库是很难扛住压力的。

2：你可能又想到了缓存，但是如此多的历史记录全部缓存起来，（存到Set这个是需要很大内存资源开销的）那得浪费多大存储空间啊？而且这个存储空间是随着时间线性增长，你撑得住一个月，你能撑得住几年么？但是不缓存的话，性能又跟不上，这该怎么办？

这时，布隆过滤器 (Bloom Filter) 闪亮登场了，它就是专门用来解决这种去重问题的。它在起到去重的同时，在空间上还能节省 90% 以上，只是稍微有那么点不精确，也就是有一定的误判概率。

布隆过滤器有二个基本指令，bf.add 添加元素，bf.exists 查询元素是否存在，它的用法和 set 集合的 sadd 和 sismember 差不多。

布隆过滤器原理

 

布隆过滤器（Bloom Filter）的核心实现是一个超大的位数组和几个哈希函数。假设位数组的长度为m，哈希函数的个数为k，以上图为例，具体的操作流程：假设集合里面有3个元素{x, y, z}，哈希函数的个数为3。首先将位数组进行初始化，将里面每个位都设置为0。对于集合里面的每一个元素，将元素依次通过3个哈希函数进行映射，每次映射都会产生一个哈希值，这个值对应位数组上面的一个点，然后将位数组对应的位置标记为1。查询W元素是否存在集合中的时候，同样的方法将W通过哈希映射到位数组上的3个点。如果3个点的其中有一个点不为1，则可以判断该元素一定不存在集合中。反之，如果3个点都为1，则该元素可能存在集合中。注意：此处不能判断该元素是否一定存在集合中，可能存在一定的误判率。可以从图中可以看到：假设某个元素通过映射对应下标为4，5，6这3个点。虽然这3个点都为1，但是很明显这3个点是不同元素经过哈希得到的位置，因此这种情况说明元素虽然不在集合中，也可能对应的都是1，这是误判率存在的原因。（这段话与图片引用于 布隆过滤器(Bloom Filter)的原理和实现  中的描述，还有一些细节实现 感兴趣可阅读 https://www.cnblogs.com/cpselvis/p/6265825.html）

特点：巧妙的使用hash算法和bitmap位存储的方式，极大的节约了空间。

       由于主要用的是hash算法的特点，所有满足和hash算法相同的规则：当过滤器返回 true时（表示很有可能该值是存在的），有一定概率是误判的，即可能不存在；当过滤器返回false时（表示确定不存在），是可以完全相信的。

       我们换个数据的角度来看规则：当数据添加到布隆过滤器中时，对该数据的查询一定会返回true；当数据没有插入过滤器时，对该数据的查询大部分情况返回false，但有小概率返回true，也就是误判。

　　 我们知道它最终满足的规则和hash的规则是一致的，只是组合了多个hash，使用了bitmap来存储，大大优化了存储的空间和判断的效率。