1、Redis的基本数据结构类型
string、list、set、hash、zet。还有三种特殊类型：Geospatial、Hyperloglog、bitMap。
2、各数据类型对应的场景
3、redis快的原因
*基于内存
内存读写效率远高于磁盘读写，省去磁盘IO操作
*存储形式
Redis作为K-V键值对型的内存数据库，所有键值都是用字典来存储，即哈希表结构。哈希表的特性就是能在O（1）时间复杂度就可以获取对应的值。
*支持多种编码
支持多种数据结构及编码，针对不通业务场景，都有相对应的数据结构和编码。根据元素的数量，有一个阈值，小于阈值和大于阈值的编码不同。
*IO多路复用
核心思想：让单个线程去监视多个连接，某个连接就绪，就触发读写事件。即可以单个线程处理多个客户端连接，无需创建和维护过多的进程和线程。
*单线程，避免上下文切换
内部执行命令为单线程，避免上下文切换带来的CPU开销
*渐进式ReHash
Redis使用全局哈希表来保存所有键值对，哈希表相当于一个数组，数组的每个元素称为一个哈系桶，每个哈系桶中保存了键值对的数据。
数据增加到一定阈值，数组扩容会导致数据发生移动，此时访问会发生阻塞。渐进式ReHash就是把一次性大量拷贝（数组移动）的开销，分摊到多次处理请求的过程中。
*缓存时间戳：
业务中需要用到时间戳时，一般会使用System.currentTimeMillis()或者New Date()等方式获取系统的毫秒时间戳，每一次获取都是一次系统调用（需要调用操作系统中对应的函数，涉及上下文切换），相对比较耗时。作为单线程的Redis承受不起，因此它由一个定时任务，每毫秒更新一次缓存，获取时间都是从缓存中直接拿。
4、为什么Redis6.0之前不支持多线程
1.Redis的瓶颈不是CPU，redis主要受制于内存、网络。
2.提高Redis性能，比如Pipeline（批量命令），每秒可以将100万个请求包装进Pipeline。
3.单线程的内部维护成本相对较低，不需要处理多线程的安全问题。多线程会有命令执行顺序不确定性，读写并发问题
4.多线程会有线程切换、加锁/解锁、死锁等问题
5.使用惰性Rehash（渐进式）可以减少阻塞。
所以一般的公司，单线程Redis就够了。
5、为什么Redis6.0之后引入了多线程
主要是并发量的问题，针对大的公司，需要更大的QPS，使用IO的多线程（内部执行命令还是单线程）。
6、为什么不采用分布式架构
服务器数量多，会导致维护成本高。对Redis命令来说不适用。而且需要数据分区的话，无法解决热点数据读写的问题。同时数据倾斜、重新分配、扩容、缩容等都会更加复杂。
7、Redis有哪些高级功能
1.慢查询
redis可以快速定位系统中的慢操作，监测发生时间、耗时、命令的详细信息。
2.pipeline
3.watch命令。
确保事务中的key有没有被其他客户端修改过，才执行事务，否则不执行（类似于乐观锁）。
4.Redis+Lua语言实现限流
5.分布式锁
首先需要Redis有互斥的能力，可以使用SETNX命令，（即如果key不存在，才会设置它的值，否则什么也不做。两个客户端进程可以执行这个命令，达到互斥，就可以实现一个分布式锁。
任务没执行完锁过期了怎么办？如图：
加入看门狗
加锁时，先设置一个过期时间，然后开启**“守护线程”**，定时检测这个锁的失效时间，如果快要过期了，操作共享资源还未完成，则自动对锁进行续期，重新设置过期时间。
6. 高并发和高可用
主从复制功能。提供了复制功能，实现了相同数据的多个Redis副本。每个主节点可以对应多个从节点，复制的数据流只能由主节点复制到从节点。
8、redis的事务命令
如果错误需要回滚，在回滚机制上，Redis只能对基本语法错误进行判断。运行时错误无法回滚。
9、Redis的过期策略以及内存淘汰机制
1、内存淘汰机制
定期删除（定时扫描策略）：
设置了过期时间的key放入独立字典，Redis默认会每秒进行十次过期扫描，不会遍历Key，而是采用简单的贪心策略。
从过期字典中随机20个key，删除其中已经过期的，如果过期比例超过1/4，则重复整个步骤；
一定要注意过期时间，如果大批量key过期（雪崩），需要给过期时间设置一个时间范围，不能全部同一时间过期。
惰性删除：
客户端访问key的时候，redis对key的过期时间进行检查，如果过期就立即删除，不会返回任何东西。
总结：定期删除是集中处理，惰性删除是零散处理。
2、过期策略
定时过期：每个设置过期时间的key都需要创建一个定时器，到期清除key。该策略会立即清除过期的数据，对内存友好，但是会占用大量CPU去处理过期数据，影响吞吐量。
惰性过期：只有访问一个key时，才会判断是否已过期，过期则清除。最大化节省CPU资源，对内存不友好。可能会导致大量过期的key因未被访问而无法清除。
定期过期：每隔一定时间，扫描一定数量的key，并删除其中过期的，通过调整定时扫描的时间间隔和扫描限定耗时，使CPU和内存达到一个最佳平衡状态。
Redis中同时使用了惰性过期和定期过期两种策略。
每隔100ms就随机抽取一定量key，检查和删除。同时获取key时，会检查一下是否过期，过期则删除。
隐患：同样可能定期删除，漏删了大量过期key，也没有走惰性删除，就会导致大量过期key堆积在内存。
3.缓存淘汰算法
Redis 缓存淘汰算法用于在内存资源不足时，决定哪些数据需要从缓存中移除。Redis 提供了多种策略以应对不同的应用场景：
volatile-lru（LRU for volatile keys）：
当内存不足以容纳新写入的数据时，会优先剔除已设置过期时间的键值对，并根据LRU原则删除最近最少使用的数据。
allkeys-lru：
不区分是否设置了过期时间，所有键都会根据LRU规则淘汰，即删除最近最少使用的数据。
volatile-ttl：
同样针对设置了过期时间的键，但淘汰时不是基于访问频率而是基于键的剩余存活时间（TTL），选择TTL最短的键进行淘汰。
noeviction：
不进行任何数据淘汰，当内存满时，执行可能导致占用更多内存的命令将返回错误。
allkeys-random：
随机淘汰任意键，不论其是否被频繁使用或何时到期。
volatile-random：
淘汰一个随机的已设置过期时间的键。
值得注意的是，Redis 实现的 LRU 算法并不是精确的 LRU，因为为了性能考虑，它并没有真正维护一个完整的 LRU 链表结构。Redis 采用了一种近似 LRU 的实现方法：通过为每个键维护一个 lru 字段来记录最后一次访问的时间戳，在内存不足时，Redis 会选择一定数量（比如 5 个）的候选键，然后比较这些候选键的 lru 值，选择其中最小的一个进行淘汰。这样可以降低维护 LRU 数据结构的成本，同时在大部分情况下能够达到类似 LRU 的效果。
10、什么是缓存穿透？如何避免？
其本质是数据库和Redis都未查到数据，比如查询id为-1的数据。
坏处：每次都需要查询数据库和redis，增加磁盘IO的压力
解决方案：
1.参数校验、屏蔽非法参数
2.数据库查询为空，可以给缓存一个空值或默认值，防止第二次再去数据库
3.使用布隆过滤器快速判断数据是否存在，将所有可能存在的数据哈希存到一个足够大的容器中，不存在的数据被这个bitmap拦截掉。
11、什么是缓存雪崩？如何避免？
本质：数据库和Redis都存在，但redis都过期了
同一时间，缓存大面积失效，大量请求都直接去访问数据库
原因：
1、Redis失效、宕机（故障）
搭建Redis集群，主从架构；
RDB持久化、IOF持久化；
加入缓存组件：EHCache，搭建多级缓存（容易高并发的数据存入）；
加入限流组件：hystrix，超过一定流量后，增加请求限制（保护数据处理层）；
2、Redis大量key的ttl过期
ttl（过期时间）岔开，增加随机值，避免同一时间全部失效。
解决方案：
热点数据永不过期，或者通过异步线程在每次热点数据快要过期时，进行续期；
数据的过期时间不要全一致，设为一定范围内的随机时间；
并发量不高，可加入队列或者锁，限制同一时间访问数据库的阈值；
分布式部署，将热点数据打散分布到多个节点；
如果是缓存中间件宕机了，需要尽可能保证其高可用性，可以搭建redis集群，提前做好报警机制；
12、缓存击穿
本质：单个key没有或过期，同一时间查询这同一条数据并发量过多
解决方案：
热点数据用不过期，或者通过异步线程在每次热点数据快要过期时，进行续期；
使用互斥锁，避免大量请求同时查询数据库；
熔断、降级、防止系统崩溃；
还可以考虑对重要的热点数据进行多级缓存；
13、Redis如何设计分布式锁
概念：
锁：同一时间只允许一个线程或者一个应用程序进入执行
分布式锁：必须要求Redis有【互斥】能力，可以使用SETNX命令：即key不存在了才会设置它的值，否则什么也不做。
注意事项：
如果过期时间是每个服务自己生成，需要保证每个客户端时间同步。
必须保存持有者唯一标识，否则可能被别的客户端释放/解锁。
给锁设置过期时间，以免进程挂了或异常了无法释放锁。
加入看门狗：开启守护线程，定期检测锁的失效时间，如果快过期了，业务还没有执行完，则续期。
看门狗：开源框架Redisson，只要线程一个线程加锁成功，就会启动一个watch dog，每隔10秒检查一下锁是否释放，只要第一个线程还持有锁，就延长锁的失效时间，解决了锁过期但业务还没执行完的问题。
14、什么是bigkey？会有什么影响？
1.概念：
key对应的value所占内存空间较大
例如一个字符串类型的value最大存到512M，一个列表类型的value最大可以存储2的32次方-1个元素。
2.字符串类型：
体现在单个value值特别大，一般认为超过10kb就是bigkey，和具体OPS相关（不同系统不同并发）。
3.非字符串类型：
哈希、列表、集合、有序集合，体现在元素个数过多。
4.危害：
内存空间不均匀
超时堵塞：单线程操作bigkey比较耗时
网络拥塞：每次获取bigkey产生的网络流量较大
例如：一个bigkey为1MB，每秒访问为1000，则每秒产生1000MB的流量，普通千兆网（按照字节算是128MB/s）的服务器是灭顶之灾，而且服务器通常会采用单机多实例的方式来部署，可能会对其他实例造成影响。
5.解决方案：value拆分
15、Redis如何解决key冲突
1、业务隔离
2、key的设计
业务模块+系统名称+关键（id），针对用户可以加入（userid）
3、分布式锁
场景：多个客户端并发写key
客户端拿到锁，才能进行操作，避免多个客户端竞争该key
4、时间戳
key拼接时间戳，根据时间戳保证多个客户端的业务执行顺序
16、怎么提高缓存命中率
1、提前加载
2、增加缓存的存储空间，增加缓存的数据
3、调整缓存的存储类型
例：对象通过Hash存储，而不用String。根据业务做适当调整。
4、定时更新
MySQL通过检测binlog，将消息推送到Redis，更新缓存
通过Mq，业务更新修改数据时，通过MQ发送消息，消费更新缓存
16.Redis持久化方式有哪些方式？有什么区别？
redis持久化指的是将数据写入磁盘，避免因进程退出而造成的数据丢失，下次重启时通过持久化文件恢复数据。
RDB
通过快照（内存中数据在某一时刻的状态记录）的方式实现持久化，根据快照的触发条件，将内存的数据快照写入磁盘，以二进制的压缩文件进行存储。
缺点：每隔一段时间触发持久化，数据安全性低。
AOF
以独立日志的方式记录每次写的命令，重启时重新执行AOF文件中的命令恢复数据。
AOF重写机制：AOF文件的大小达到某个阈值时，会将其中指令进行压缩。(如果有对于某个key多次的变更指令，则仅保留最新的数据指令)。
优点：
因为AOF重写过程中需要读取当前内存中所有键值数据，性能较低，redis将其放在一个后台子线程中完成。
为了避免重写过程中出现数据变动，主进程的数据变更需要追加到AOF重写缓冲区中，等到AOF重写完成后，再把AOF重写换乘区里面的内容追加到新的AOF文件中。
缺点：AOF文件可能过大，性能较差。
混合式存储
如果执行bgrewriteaof命令，将内存中已有的数据以二进制格式存放在AOF文件中（模拟RDB），后续命令亦然采用AOF追加方式。
生产环境中一般采用两种持久化机制混合使用。
将内存中数据快照存储在AOF文件中（模拟RDB），后续再以AOF追加方式。
如果仅作为缓存使用，可以承受几分钟数据丢失，可以使用RDB，对主程序性能影响最小。
17、为什么Redis需要把所有数据放到内存中？
1、内存访问与磁盘访问的差距几乎是10倍以上，如果不是顺序读取而是随机读取效率会相差更大，同时还有CPU上下文切换的开销。
2、Redis通过异步，持久化将数据写入磁盘
3、随着技术的发展，硬件上来说内存也越来越便宜了
4、默认情况下，哪怕Redis内存不够了，也不会发生宕机，而是只可读不能写（Noeviction策略）
5、通过内存淘汰策略，确保整体服务正常运行。
18、如何保证缓存与数据库双写一致性？
1、新增数据类
新增数据时，数据会直接写入数据库，不用对缓存做任何操作；此时缓存没有新增数据，而数据库中是最新值。
2、更新缓存类
（1）先更新缓存，在更新DB（一般不考虑）
原因：缓存更新成功，更新数据库时出现异常，会导致数据源与缓存数据完全不一致，而且很难察觉，因为缓存中的数据一直都存在。
（2）先更新DB，在更新缓存（一般不考虑）
原因：数据库更新成功了，缓存更新失败了，同样会导致数据源与缓存数据完全不一致，也很难察觉。
3、删除缓存
（3）先删除缓存，后更新DB
问题：
两个请求：A（更新）和B（查询）
A -> 删除缓存中的数据 -> 更新数据库
B -> 查询缓存为空 -> 查询数据库 -> 补录到缓存
A -> 还未更新成功/事务还未提交，B -> 查询到的其实是数据库旧值
解决方案：
先淘汰缓存，再写数据库，休眠1秒，再次淘汰缓存。
这个休眠的时间需要评估项目的读数据业务逻辑的耗时，确保请求结束时，写请求可以删除读请求造成的缓存脏数据。
（4）先更新DB，后删除缓存
查询：先读缓存 -> 缓存没有就读数据库 -> 取出数据放入缓存 -> 同时返回响应。
更新：先更新数据库 -> 删除缓存
4、如何选择
一般线上更多偏向于第三种（容易避免问题）
原因：
删除缓存比在DB中要快，所以一般先更新DB，而问题只会出现在查询比删除慢的情况，出现率相对最少。同时延迟双删可以有效避免缓存不一致情况。
5、读取binlog日志
异步删除、更新缓存，
可以使用canal将binlog日志采集发送到MQ队列中。
通过ACK机制确认处理这条更新消息，删除缓存，保证数据一致性。
19、Redis常见性能问题和解决方案
1、持久化 性能问题
早期仅支持全量复制->部分复制（一台机器性能开销过大）
因此开始配置主从 ：主节点不再做持久化而是交给从节点来做
2、数据比较重要时，开启AOF。策略最好配置每秒同步。
3、主从复制保证流畅，建议同一个局域网内操作，否则网络开销过大
4、尽量避免主库压力过大，增加从库
5、主从复制 尽量不要使用网状结构、线性结构
20、什么情况下可能会导致Redis阻塞
1、客户端阻塞
命令执行时间过长： keys* Hgetall smembers 时间复杂度O(N)
2、BIGkey删除
需要释放大量占用内存 zset（100万的元素 删除大概需要2s）
3、清空库
flushdb flushall 涉及删除所有键值对
4、AOF日志同步写时大量写的操作，一个同步写磁盘操作大概耗时1~2ms
5、从库加载RDB文件时RDB文件过大
6、Redis尽量部署在独立的服务器中
21、线上Redis响应慢处理思路
1、紧急处理方案，扩容
2、生产环境查看Redis内存使用率，分析一定时间段内key数量变化
分析是否是大量数据未设置过期时间，或者是因为新版本迭代引起
3、清除bigkey，优化生成bigkey的代码块，调整未设置过期时间的代码块
4、根据业务场景调整淘汰策略
22、Redis 的高可用
高可用：数据不能丢失（尽量减少丢失），保证Redis
1.主从模式
部署多台Redis服务器，主从复制以保证数据副本一致。主库通过将RDB文件发送给从库实现复制。
主从之间采用读写分离，主库写操作，从库仅负责读操作。
主库如果宕机了，人工切换一台从库称为主库，通知应用方更新主节点地址。
问题：数据不一致。
原因：主从库网络延迟，从库接收到命令，但它正在执行阻塞性命令。
解决方法：保证网络通畅，监控主从库复制进度。
2 哨兵模式
Redis从2.8开始提供哨兵机制。
2.1 作用
监控：周期性ping主从库，检测是否挂了，标记下线状态。
自动选主切换：多个从库中按照一定规则选一个作为主库。
通知：选出主库后，将新主库的连接信息发送给其他从库以及应用方，重新建立联系。
2.2 哨兵
由一个或多个哨兵实例组成哨兵系统，监控其他Redis节点的同时，哨兵实例之间也互相监控。
哨兵之间通过发布订阅机制组成集群。一主多从
缺点：无法实现在线扩容，并发压力受限于单个服务器的资源配置。
3 Redis Cluster
哨兵模式解决了自动切换主从的问题，但是没有解决在线扩容的问题。
本质：Redis Cluster实现了Redis的分布式存储，每个节点存储不同的数据，实现数据分片。
引入Slot槽实现数据分片，每个节点分配一个Slot区间，当我们存取Key的时候，Redis根据key计算得到Slot值，找到对应的节点进行读写。多主多从。
