redis面试

redis为什么这么快

https://zhuanlan.zhihu.com/p/57089960
Redis架构原理及应用实践

数据结构

实现结构

SDS

Redis 是用 C 语言开发完成的，但在 Redis 字符串中，并没有使用 C 语言中的字符串，而是用一种称为 SDS（Simple Dynamic String）的结构体来保存字符串。

struct sdshdr {
      int len;
    int free;
    char buf[];
}

SDS 与 C 字符串的区别

①常数时间内获得字符串长度

C 字符串本身不记录长度信息，每次获取长度信息都需要遍历整个字符串，复杂度为 O(n)；C 字符串遍历时遇到 ‘\0’ 时结束。

SDS 中 len 字段保存着字符串的长度，所以总能在常数时间内获取字符串长度，复杂度是 O(1)。

②避免缓冲区溢出

假设在内存中有两个紧挨着的两个字符串，s1=“xxxxx”和 s2=“yyyyy”。

由于在内存上紧紧相连，当我们对 s1 进行扩充的时候，将 s1=“xxxxxzzzzz”后，由于没有进行相应的内存重新分配，导致 s1 把 s2 覆盖掉，导致 s2 被莫名其妙的修改。

但 SDS 的 API 对 zfc 修改时首先会检查空间是否足够，若不充足则会分配新空间，避免了缓冲区溢出问题。

③减少字符串修改时带来的内存重新分配的次数

在 C 中，当我们频繁的对一个字符串进行修改（append 或 trim）操作的时候，需要频繁的进行内存重新分配的操作，十分影响性能。

如果不小心忘记，有可能会导致内存溢出或内存泄漏，对于 Redis 来说，本身就会很频繁的修改字符串，所以使用 C 字符串并不合适。而 SDS 实现了空间预分配和惰性空间释放两种优化策略：

空间预分配：当 SDS 的 API 对一个 SDS 修改后，并且对 SDS 空间扩充时，程序不仅会为 SDS 分配所需要的必须空间，还会分配额外的未使用空间。

分配规则如下：如果对 SDS 修改后，len 的长度小于 1M，那么程序将分配和 len 相同长度的未使用空间。举个例子，如果 len=10，重新分配后，buf 的实际长度会变为 10(已使用空间)+10(额外空间)+1(空字符)=21。如果对 SDS 修改后 len 长度大于 1M，那么程序将分配 1M 的未使用空间。

惰性空间释放：当对 SDS 进行缩短操作时，程序并不会回收多余的内存空间，而是使用 free 字段将这些字节数量记录下来不释放，后面如果需要 append 操作，则直接使用 free 中未使用的空间，减少了内存的分配。

字典

使用场景

String：缓存、计数器、分布式锁等。
List：链表、队列、微博关注人时间轴列表等。
Hash：用户信息、Hash 表等。
Set：去重、赞、踩、共同好友等。
Zset：访问量排行榜、点击量排行榜等。

特性

纯内存操作
单线程
高效的数据结构
合理的数据编码
计算像存储移动
其他方面的优化

淘汰策略

1.volatile-lru：从已经设置过期时间的数据集中，挑选最近最少使用的数据淘汰

2.volatile-ttl：从已经设置过期时间的数据集中，挑选即将要过期的数据淘汰

3.volatile-random：从已经设置过期时间的数据集中，随机挑选数据淘汰

4.allkeys-lru：从所有的数据集中，挑选最近最少使用的数据淘汰

5.allkeys-random：从所有的数据集中，随机挑选数据淘汰

6.no-enviction：禁止淘汰数据

高并发实践

五.Redis高并发及热key解决之道

并发设置key及分布式锁

Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程所以Redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对Redis进行并发访问时会出现问题。比如多客户端同时并发写一个key，一个key的值是1，本来按顺序修改为2,3,4，最后是4，但是顺序变成了4,3,2，最后变成了2。使用分布式锁防止并发设置Key的原理及代码见：使用Redis实现分布式锁及其优化，另外一种方式是使用消息队列,把并行读写进行串行化。

热key问题

热key问题说来也很简单，就是瞬间有几十万的请求去访问redis上某个固定的key，从而压垮缓存服务的情情况。其实生活中也是有不少这样的例子。比如XX明星结婚。那么关于XX明星的Key就会瞬间增大，就会出现热数据问题。那么如何发现热KEY呢：

1.凭借业务经验，进行预估哪些是热key

2.在客户端进行收集

3.在Proxy层做收集

4.用redis自带命令（monitor命令、hotkeys参数）

5.自己抓包评估

解决方案：

1.利用二级缓存，比如利用ehcache，或者一个HashMap都可以。在你发现热key以后，把热key加载到系统的JVM中。

2.备份热key，不要让key走到同一台redis上。我们把这个key，在多个redis上都存一份。可以用HOTKEY加上一个随机数（N，集群分片数）组成一个新key。

3.热点数据尽量不要设置过期时间，在数据变更时同步写缓存，防止高并发下重建缓存的资源损耗。可以用setnx做分布式锁保证只有一个线程在重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。

防止缓存穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，但是出于容错的考虑，如果从存储层查不到数据则不写入缓存层。缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义。造成缓存穿透的基本有两个。
第一，业务自身代码或者数据出现问题，
第二，一些恶意攻击、爬虫等造成大量空命中，下面我们来看一下如何解决缓存穿透问题。解决缓存穿透的两种方案：

1）缓存空对象

缓存空对象会有两个问题：

第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2）布隆过滤器拦截
如下图所示，在访问缓存层和存储层之前，将存在的 key 用布隆过滤器提前保存起来，做第一层拦截。如果布隆过滤器认为该用户 ID 不存在，那么就不会访问存储层，在一定程度保护了存储层。有关布隆过滤器的相关知识，可以参考： 布隆过滤器，可以利用 Redis 的 Bitmaps 实现布隆过滤器，GitHub 上已经开源了类似的方案，读者可以进行参考：redis bitmaps实现布隆过滤器

防止缓存雪崩

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

可以从以下几个方面防止缓存雪崩：

1）保证缓存层服务高可用性
和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。
2）Redis备份和快速预热
Redis备份保证master出问题切换为slave迅速能够承担线上实际流量，快速预热保证缓存及时被写入缓存，防止穿透到库。
3）依赖隔离组件为后端限流并降级
无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部 hang 在这个资源上，造成整个系统不可用。降级在高并发系统中是非常正常的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。
在实际项目中，我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管理，比如如何关闭资源池，开启资源池，资源池阀值管理，这些做起来还是相当复杂的，这里推荐一个 Java 依赖隔离工具Hystrix(https://github.com/Netflix/Hystrix)，如下图所示。
4）提前演练
在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。
5）防止大规模失效的方法：设置key的过期数值加个随机数。

缓存预热

缓存预热就是系统上线前，将相关的缓存数据直接加载到缓存系统。这样就可以避免上线后在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

本文地址：https://blog.csdn.net/weixin_42886721/article/details/107386541