Redis知识点总结

Redis知识点总结

1.Redis是什么？都有哪些使用场景？

Redis是一个key-value存储系统，为了解决应用服务器减少IO读操作，减轻IO压力。大部分情况下是因为其高性能的特性，被当做缓存使用。但是不支持需要事务操作和基于SQL结构化的复杂查询。

**使用场景：**配合关系型数据库作为缓冲、缓冲高频次访问的数据，降低数据库IO、排行问题（ZRank）、删除过期数据、消息队列

2.Redis有哪些功能？

3.Redis和 memecache 有什么区别？

Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构并支持更丰富的数据操作。

内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。

性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高

4.Redis为什么是单线程的？

因为CPU不是Redis的瓶颈。Redis的瓶颈最有可能是机器内存或者网络带宽。为了避免不必要的上下文切换和竞争条件，也不存在多线程或多进程导致的切换而消耗CPU，不用去考虑各种锁的问题，不存在加锁和示范所的操作。没有因为可能出现死锁而导致的性能消耗

5.什么是缓存穿透？怎么解决？

缓冲穿透是指查询一个数据库一定不存在的数据。正常的使用缓冲流程大概是：数据先进行缓存查询，如果key-value不存在或key已经拿给过期，则进入数据库查询，并把查询到的对象放入带缓冲中去，如果查询对象为null，则不放入缓冲。
最常见的解决方案是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
另外也有一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴！
常见的还有缓存雪崩：指的是某一个时间段，缓存集中过期失效。 这个没有完美解决办法，但可以分析用户行为，尽量让失效时间点均匀分布。

大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

数据预热

可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

做二级缓存，或者双缓存策略。

A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期

缓存击穿：指的是一个key非常热点，在不停的扛着大并发，大并发集中地对着这一个点进行访问，当这个key在失效的瞬间，持续的大并发就击穿缓冲，直接请求服务器。

6.Redis支持的数据类型有哪些？

1、字符串string

2、哈希hash

哈希hash是一个string类型的field和value的映射表，hash适合用于存储对象

3、列表

用来存储多个有序的字符串

4、无序集合set

5、有序集合 sorted set

7.Redis支持的 java 客户端都有哪些？

Jedis和Redisson

8.jedis 和 redisson 有哪些区别？

Jedis：

• 轻量，简洁，便于集成和改造
• 支持连接池
• 支持pipelining、事务、LUA Scripting、RedisSentinel、RedisCluster
• 不支持读写分离，需要自己实现

Redisson：

• 基于Netty实现，采用非阻塞IO，性能高
• 支持异步请求
• 支持连接池
• 支持pipelining、LUA Scripting、RedisSentinel、RedisCluster
• 不支持事务，官方建议以LUA Scripting代替事务
• 支持在RedisCluster架构下使用pipelining
• 支持读写分离，支持读负载均衡，在主从复制和RedisCluster架构下都可以使用
• 内建Tomcat Session Manager，为Tomcat 6/7/8提供了会话共享功能
• 可以与Spring Session集成，实现基于Redis的会话共享
• 文档较丰富，有中文文档

9.怎么保证缓存和数据库数据的一致性？

读的时候，先读缓存，缓存没有的话，那么就读数据库，然后取出数据后放入缓存，同时返回响应

更新的时候，先删除缓存，然后再更新数据库，因为有的时候，缓存不简单是数据库中直接取出来的值

10.Redis持久化有几种方式？

RDB快照

RDB存在哪些优势呢？

1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数 据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？

1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF

AOF的优势有哪些呢？

1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其 效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。

2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操 作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据 一致性的问题。

3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创 建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

diskstore方式

11.Redis怎么实现分布式锁？

https://www.cnblogs.com/liuyang0/p/6744076.html

12.Redis分布式锁有什么缺陷？

13.Redis如何做内存优化？

缩减键值对象、共享对象池、字符串优化

https://www.cnblogs.com/jandison/p/6902396.html

14.Redis淘汰策略有哪些？

我们可以通过设置Redis的maxmemory参数，控制最大可用内存大小，如果超出这一大小，就要采用Redis淘汰策略，Redis默认的淘汰策略为noeviction

redis键具有的六大淘汰规则

规则名称	规则说明
volatile-lru	使用LRU算法删除一个键（只对设置了生存时间的键，在设置了过期时间的键空间中，优先移除最近未使用的key。）
allkeys-lru	使用LRU算法删除一个键（在主键空间中，优先移除最近未使用的key）
volatile-random	随机删除一个键（只对设置了生存时间的键）
allkeys-random	随机删除一个键
volatile-ttl	删除生存时间最近的一个键（在设置了过期时间的键空间中，具有更早过期时间的key优先移除）
noeviction	不删除键，只返回错误

LRU算法，least RecentlyUsed，最近最少使用算法。也就是说默认删除最近最少使用的键

几种策略的适用场景：

allkeys-lru：如果我们的应用对缓存的访问符合幂律分布（也就是存在相对热点数据），或者我们不太清楚我们应用的缓存访问分布状况，我们可以选择allkeys-lru策略。

allkeys-random：如果我们的应用对于缓存key的访问概率相等，则可以使用这个策略。

volatile-ttl：这种策略使得我们可以向Redis提示哪些key更适合被eviction

15.Redis常见的性能问题有哪些？该如何解决？

Master写内存快照

save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。

Master AOF持久化

如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。

Master调用BGREWRITEAOF

Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。

Redis主从复制的性能问题

第一次Slave向Master同步的实现是：Slave向Master发出同步请求，Master先dump出rdb文件，然后将rdb文件全量传输给slave，然后Master把缓存的命令转发给Slave，初次同步完成。第二次以及以后的同步实现是：Master将变量的快照直接实时依次发送给各个Slave。不管什么原因导致Slave和Master断开重连都会重复以上过程。Redis的主从复制是建立在内存快照的持久化基础上，只要有Slave就一定会有内存快照发生。虽然Redis宣称主从复制无阻塞，但由于Redis使用单线程服务，如果Master快照文件比较大，那么第一次全量传输会耗费比较长时间，且文件传输过程中Master可能无法提供服务，也就是说服务会中断，对于关键服务，这个后果也是很可怕的。

以上根本问题的原因都离不开系统io瓶颈问题，也就是硬盘读写速度不够快，主进程 fsync()/write() 操作被阻塞。

总结

1. Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化。
2. 如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3. 为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内。
4. 尽量避免在压力较大的主库上增加从库

16. 缓存预热

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决思路：

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

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

3、定时刷新缓存；

17. 缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

（1）定时去清理过期的缓存；

（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

18. 缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

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

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

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

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