没学SpringCloud 不知道什么是分布式、集群的时候不知道为啥要问Redis，现在发现JUC和Redis确实重要，确实该问。。
我的Redis就是学习了这个老师的课 ，讲的很好
https://www.bilibili.com/video/BV1fi4y1N7dA?p=4&spm_id_from=pageDriver

我这里分了一些模块，方便复习。

• Redis概述
• Redis数据类型&使用场景
• 分布式锁问题
• 缓存异常问题
• 内存相关
• 线程模型
• 事务
• 持久化
• 集群
• Redis性能优化

• 其他

  Redis概述

  什么是Redis

  Redis是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库。
  下面的可以稍微说说

• Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、集合、散列表、有序集合。

• 与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。
  

Redis的优缺点

优点

• 读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
• 支持数据持久化，支持AOF和RDB两种持久化方式。
• 支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
• 数据结构高效，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点

• 数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
• Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

Redis为什么这么快（也就是优点）

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；
2、数据结构简单高效，对数据操作也简单，Redis 中的数据结构是专门进行设计的；
3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4、使用多路 I/O 复用模型，非阻塞 IO；
5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

为什么要用Redis/为什么要用缓存

主要从“高性能”和“高并发”这两点来看待这个问题。

高性能：
假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发：
直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

分布式的CAP原则

指在一个分布式系统中，一致性，可用性，分区容错性，三者不可兼得。

Consistency (一致性)：
即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。
对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。

Availability (可用性):
即服务一直可用，而且是正常响应时间。
好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。

Partition Tolerance (分区容错性):
即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

Base理论

base理论是CAP理论的一种妥协。

Redis数据类型&使用场景

Redis的数据结构类型，一般都用在什么场景

1.字符串String /常用操作/使用场景

先拿100个序列号，大大减少频繁交互

2.哈希Hash /常用操作/使用场景

适合多个字段只修改其中一个字段

3.列表List /常用操作/使用场景

4.集合Set /常用操作/使用场景

5.有序集合Zset /常用操作/使用场景

通过索引层，将有序链表改造成支持“折半查找”算法，可以进行快速的插入、删除、查找操作。（空间换时间）
压缩列表—转化为—->跳表的情况**：**

• zset-max-ziplist-entries 128 //元素个数超过128，将用skiplist编码
• zset-max-ziplist-value 64 //单个元素大小超过了64byte，将用skiplist编码

列举Redis的使用场景

• 计数器，可以对 String 进行自增自减运算，从而实现计数器功能。Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。
• 缓存，将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。
• 会话缓存，可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。
• 全页缓存（FPC）除基本的会话token之外，Redis还提供很简便的FPC平台。以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
• 查找表，例如 DNS 记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。
• 消息队列(发布/订阅功能) List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息。不过最好使用 Kafka、RabbitMQ 等消息中间件。
• 分布式锁实现，在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。
• Set 可以实现交集、并集等操作，从而实现共同好友等功能。ZSet 可以实现有序性操作，从而实现排行榜等功能。

• Redis相比其他缓存，有一个非常大的优势，就是支持多种数据类型。
• 数据类型说明string字符串，最简单的k-v存储hashhash格式，value为field和value，适合ID-Detail这样的场景。list简单的list，顺序列表，支持首位或者末尾插入数据set无序list，查找速度快，适合交集、并集、差集处理sorted set有序的set
• string——适合最简单的k-v存储，类似于memcached的存储结构，短信验证码，配置信息等，就用这种类型来存储。
• hash——一般key为ID或者唯一标示，value对应的就是详情了。如商品详情，个人信息详情，新闻详情等。
• list——因为list是有序的，比较适合存储一些有序且数据相对固定的数据。如省市区表、字典表等。因为list是有序的，适合根据写入的时间来排序，如：最新的*，消息队列等。
• set——可以简单的理解为ID-List的模式，如微博中一个人有哪些好友，set最牛的地方在于，可以对两个set提供交集、并集、差集操作。例如：查找两个人共同的好友等。
• Sorted Set——是set的增强版本，增加了一个score参数，自动会根据score的值进行排序。比较适合类似于top 10等不根据插入的时间来排序的数据。

如上所述，虽然Redis不像关系数据库那么复杂的数据结构，但是，也能适合很多场景，比一般的缓存数据结构要多。了解每种数据结构适合的业务场景，不仅有利于提升开发效率，也能有效利用Redis的性能。

排行榜功能的实现：Zset的底层原理？

sortedSet的底层数据结构

通过索引层，将有序链表改造成支持“折半查找”算法，可以进行快速的插入、删除、查找操作。（空间换时间）
压缩列表—转化为—->跳表的情况**：**

• zset-max-ziplist-entries 128 //元素个数超过128，将用skiplist编码
• zset-max-ziplist-value 64 //单个元素大小超过了64byte，将用skiplist编码

分布式锁问题

利用redis实现分布式锁（String实现）

但是这个架构还是存在问题的，因为redis服务器是主从的架构，当在master节点设置锁之后，slave节点会立刻同步。但是如果刚在master节点设置上了锁，slave节点还没来得及设置，master节点就挂掉了。还是会产生上同样的问题，新的线程获得锁。因此使用redis构建高并发的分布式锁，仅适合单机架构，当使用主从架构的redis时还是会出现线程安全性问题。
https://blog.csdn.net/deepking18254382067/article/details/99248342?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522161664004016780265488243%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=161664004016780265488243&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduend~default-2-99248342.first_rank_v2_pc_rank_v29&utm_term=%E9%AB%98%E5%B9%B6%E5%8F%91%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E5%A6%82%E4%BD%95%E5%AE%9E%E7%8E%B0

setnx讲讲 ：
Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系，Redis中可以使用SETNX命令实现分布式锁。

• 当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则 SETNX 不做任何动作
• SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
• 返回值：设置成功，返回 1 。设置失败，返回 0 。

使用SETNX完成同步锁的流程及事项如下：

1. 使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功
2. 为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间
3. 释放锁，使用DEL命令将锁数据删除

实际使用有个解决方案Redisson讲讲，还有zookeeper也能解决分布式锁问题。

秒杀场景下超卖bug（分布式锁）

还就是那个卖票问题，我们用synchronized或者lock加锁只能在单机环境，JVM内存级别，遇到了Tomcat集群就难办。
用JMeter做一下压测 ，发现高并发场景下多卖了。
解决方案：分布式锁 SETNX
Boolean result = strinigRedisTemplate.opsForValue().seetIfAbsent("lockKey","zhuge");
卖票代码
stringRedisTemplate.delete("lockKey") //删除锁
上述代码是什么意思？ 实际上setnx key value 将k的值设为value，当且仅当key不存在，要是给定的k已存在，则setnx不做任何操作。

除此之外，还有很多问题：服务器宕机、死锁、给锁加存活时间，事还没干完锁时间到了（锁永久失效），上锁应该是原子操作，异常处理。
锁的value用线程的UUID，妙啊clientId.equals(stringRedisTemplate.opsForValue().get(lockKey))
锁续命逻辑：妙啊 主线程分出个分线程，分线程每10s检查是否当前线程持有锁，要是持有就重新设置timeout为30s！！

redisson框架，把上面说的东西封装好了。。。。

Redisson讲一讲

类似于Jedis，是Redis的Java实现的客户端。
Redisson实现了分布式和可拓展的Java数据结构。底层用了大量lua卢瓦脚本
干了些什么事情？

1. setnx加分布式锁，设置超时时间
2. 分线程，续命锁30/3 s

如何解决Redis的并发竞争key问题

所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同
推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）

基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

在实践中，当然是从以可靠性为主。所以首推Zookeeper。

Zookeeper与Redisson在解决分布式锁问题上的异同。

CAP原则，Redisson主要保证AP原则，Zookeeper主要保证CP原则。

• 设置锁的区别：
  • Reids主节点（Master）只要有k了，马上告诉客户端加锁成功，执行业务逻辑（不考虑Redlock）
  • Zookeeper主节点（leader）有了k不会马上告诉客户端，而是把锁同步到集群其他节点（至少半数以上节点都写入了k），才会返回给客户端。所以Zookeeper没有主从切换锁失效的问题。

主从架构锁失效问题的解决

• 我直接用Zookeeper
• RedLock 不好用 Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫 Redlock，此种方式比原先的单节点的方法更安全。它可以保证以下特性：
  • 安全特性：互斥访问，即永远只有一个 client 能拿到锁
  • 避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
  • 容错性：只要大部分 Redis 节点存活就可以正常提供服务

高并发分布式锁如何实现

回忆一下ConcurrentHashMap的底层实现原理，好的顺便复习一下
JDK7： ReentrantLock + Segment + Entry
JDK8：Synchronized + CAS + Node +红黑树
底层是用分段锁来实现的。

缓存异常问题

缓存与数据库双写不一致

解决方案1：更新完数据 就Del缓存，还是有可能出现下述问题：

解决方案2: 延时双删。删两次缓存，中间来点时间间隔 （不靠谱）
解决方案3: 内存队列，串行化执行，不太好。麻烦
解决方案4: 分布式锁，但是有性能问题。（需要优化）
解决方案5: 读写锁 读锁不互斥 ，写锁互斥。互联网80%读，20%写，Redisson有ReadWirteLock读写锁，

解决方案6:缓存设置超时时间。（读多写多，不要求一定一致，譬如逛淘宝，发现库存是5，这个5不一定是数据库里具体的库存数5，没那么精准，因为你提交订单这里还要花一定时间，这段时间就有可能有商品变动）

如何保证数据一致性的问题

上面几个了解一下，不强制要求一致性的就去读缓存，一定要求的就读数据库。

解释一下缓存击穿、缓存穿透、缓存雪崩，如何解决这些问题

缓存雪崩是指缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案

• 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
• 一般并发量不是特别多的时候，使用最多的解决方案是加锁排队。（查数据库的时候加锁）
• 给每一个缓存数据增加相应的缓存标记，记录缓存的是否失效，如果缓存标记失效，则更新数据缓存。
• 缓存预热

缓存穿透（一般来自于攻击）
缓存穿透是指缓存和数据库中都没有的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决方案

• 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
• 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
• 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力

布隆过滤器，好东西啊！ 说你存在，你可能不存在，说你不存在，一定不存在

缓存击穿（数据库有，缓存没有，但是并发很高）
缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。和缓存雪崩不同的是，缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

解决方案

• 设置热点数据永远不过期。
• 加互斥锁，互斥锁

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

解决方案

• 直接写个缓存刷新页面，上线时手工操作一下；
• 数据量不大，可以在项目启动的时候自动进行加载；

定时刷新缓存；

缓存降级（了解）
当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。
缓存降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

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

• 一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
• 警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
• 错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
• 严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

Redis的过期键的删除策略

过期策略通常有以下三种：

• 定时过期：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
• 惰性过期：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
• 定期过期：每隔一定的时间，会扫描一定数量的数据库的expires字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。

(expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

Redis中同时使用了惰性过期和定期过期两种过期策略。

热点key问题分析

(1) 这个key是一个热点key（例如一个重要的新闻，一个热门的八卦新闻等等），所以这种key访问量可能非常大。
(2) 缓存的构建是需要一定时间的。（可能是一个复杂计算，例如复杂的sql、多次IO、多个依赖(各种接口)等等）
于是就会出现一个致命问题：在缓存失效的瞬间，有大量线程来构建缓存，造成后端负载加大，甚至可能会让系统崩溃 。

解决方法：<br />1. 使用**互斥锁(mutex key)**:这种解决方案思路比较简单，就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了<br />2. **"提前"使用互斥锁(mutex key)**：在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。<br />3. "**永远不过期"：**<br /> 这里的“永远不过期”包含两层意思：<br />    (1) 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。<br />    (2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期<br />4. **资源保护：**<br />       hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可。

内存相关

MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

Redis的内存淘汰策略有哪些（这八点还挺重要，

Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

• 全局的键空间选择性移除
  • noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
  • allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个是最常用的）
  • allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。
• 设置过期时间的键空间选择性移除
  • volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
  • volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
  • volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

总结
Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略用于处理内存不足时的需要申请额外空间的数据；过期策略用于处理过期的缓存数据。

Redis主要消耗什么物理资源？

内存。

Redis的内存用完了会发生什么？

如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回。）或者你可以配置内存淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

Redis如何做内存优化？

可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面

线程模型

redis使用单线程的好处，为什么效率这么高

Redis基于响应式模式开发了网络事件处理器，这个处理器叫做文件事件处理器file event handler。这个文件事件处理器，它是单线程的，所以Redis才叫做单线程的模型，它采用IO多路复用机制来同时监听多个Socket,根据Socket上的事件类型来选择对应的事件处理器来处理这个事件。可以实现高性能的网络通信模型，又可以跟内部其他单线程的模块进行对接,保证了Redis内部的线程模型的简单性。

文件事件处理器的结构包含4个部分:多个Socket. IO多路复用程序、文件事件分派器以及事件处理器(命令请求处理器、命令回复处理器、连接应答处理器等)。

多个Socket可能并发的产生不同的操作,每个操作对应不同的文件事件,但是IO多路复用程序会监听多个

Socket,会将Socket放入一个队列中排队，每次从队列中取出一个Socket给事件分派器，事件分派器把Socket给对应的事件处理器。

然后一个Socket的事件处理完之后，I0多路复用程序才会将队列中的下一个Socket给事件分派器。文件事件分派器会根据每个Socket当前产生的事件,来选择对应的事件处理器来处理。

单线程快的原因:
首先它适合使用单线程，业务逻辑不复杂，处理很快。多线程适合复杂逻辑
1)纯内存操作
2)核心是基于非阻塞的IO多路复用机制
3)单线程反而避免了多线程的频繁上下文切换带来的性能问题

redis中如何控制多线程并发

分布式锁。

事务

什么是事务？

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

Redis事务的概念

Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务的三个阶段

1. 事务开始 MULTI
2. 命令入队
3. 事务执行 EXEC

事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队

Redis事务相关命令

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的

Redis会将一个事务中的所有命令序列化，然后按顺序执行。

1 redis 不支持回滚，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
2 如果在一个事务中的命令出现错误，那么所有的命令都不会执行；
3 如果在一个事务中出现运行错误，那么正确的命令会被执行。

• WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
• MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
• EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。
• 通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
• UNWATCH命令可以取消watch对所有key的监控。

事务管理（ACID）概述

原子性（Atomicity）
原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。

一致性（Consistency）
事务前后数据的完整性必须保持一致。

隔离性（Isolation）
多个事务并发执行时，一个事务的执行不应影响其他事务的执行

持久性（Durability）
持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服务器运行在AOF持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。

Redis事务支持隔离性吗

Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

Redis事务保证原子性吗，支持回滚吗

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务其他实现

• 基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行，其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完
• 基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐

持久化

什么是Redis持久化？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis 的持久化机制是什么？各自的优缺点？

Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制:

RDB：是Redis DataBase缩写快照
RDB是Redis默认的持久化方式。在指定的时间间隔内将内存的数据以快照的形式保存到硬盘中
实际操作是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。
优点：
1、只有一个文件 dump.rdb，方便持久化。
2、容灾性好，方便备份。
3、性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能
4.相对于数据集大时，比 AOF 的启动效率更高。
缺点：
1、数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
2、由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF：持久化
AOF持久化(即Append Only File持久化)。
以日志的形式记录服务器所处理的每一个写、删除操作、查询操作不会记录、以文本的方式记录，可以打开文件看到详细的操作记录。

当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

优点：
1、数据安全，Redis提供了三种同步策略，即每秒同步，每修改同步，不同步。每修改同步我们可以将其视为同步持久化，每进行一次命令操作就记录到 aof 文件中一次。
2、通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
3、AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)
缺点：
1、AOF 文件比 RDB 文件大，且恢复速度慢。
2、数据集大的时候，比 rdb 启动效率低。
3、运行效率没有RDB高

总结：
AOF文件比RDB更新频率高，优先使用AOF还原数据。
AOF比RDB更安全也更大
RDB性能比AOF好
如果两个都配了优先加载AOF

如何选择合适的持久化方式

一般来说， 如果想达到足以媲美PostgreSQL的数据安全性，你应该同时使用两种持久化功能。在这种情况下，当 Redis 重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失，那么你可以只使用RDB持久化。

有很多用户都只使用AOF持久化，但并不推荐这种方式，因为定时生成RDB快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比AOF恢复的速度要快，除此之外，使用RDB还可以避免AOF程序的bug。

如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。

Redis持久化数据和缓存怎么做扩容？

如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。

如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

解释一下一致性哈希

我麻了
https://blog.csdn.net/qq_25448409/article/details/86013885?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&dist_request_id=1328741.2091.16167718095175715&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control

集群

Redis主从+哨兵

一主多从，主负责写，并且将数据复制到其它的slave节点，从节点负责读。

sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

集群监控：负责监控 redis master 和 slave 进程是否正常工作。
消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

• 故障转移时，判断一个 master node 是否宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题。主从切换的瞬间存在访问瞬断的情况。
• 即使部分哨兵节点挂掉了，哨兵集群还是能正常工作的，因为如果一个作为高可用机制重要组成部分的故障转移系统本身是单点的，那就很坑爹了。

哨兵的核心知识

• 哨兵至少需要 3 个实例，来保证自己的健壮性。
• 哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。
• 对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

高可用集群模式

Redis Cluster方案

Redis Cluster是一种服务端分片Sharding技术，3.0版本开始正式提供。Redis Cluster并没有使用一致性hash，而是采用slot(槽)的概念，一共分成16384个槽。将请求发送到任意节点，接收到请求的节点会将查询请求发送到正确的节点上执行。

方案说明

• 通过哈希的方式，将数据分片，每个节点均分存储一定哈希槽(哈希值)区间的数据，默认分配了16384 个槽位
• 每份数据分片会存储在多个互为主从的多节点上
• 数据写入先写主节点，再同步到从节点(支持配置为阻塞同步)
• 同一分片多个节点间的数据不保持一致性
• 读取数据时，当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点
• 扩容时时需要需要把旧节点的数据迁移一部分到新节点

在 redis cluster 架构下，每个 redis 要放开两个端口号，比如一个是 6379，另外一个就是 加1w 的端口号，比如 16379。

16379 端口号是用来进行节点间通信的，也就是 cluster bus 的东西，cluster bus 的通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议，gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

优点

• 无中心架构，支持动态扩容，对业务透明
• 具备Sentinel哨兵的监控和自动Failover(故障转移)能力
• 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
• 高性能，客户端直连redis服务，免去了proxy代理的损耗

缺点

• 运维也很复杂，数据迁移需要人工干预
• 只能使用0号数据库 （默认11个数据库）
• 不支持批量操作(pipeline管道操作)
• 分布式逻辑和存储模块耦合等

Redis Sharding方案

基于客户端分片

简介
Redis Sharding是Redis Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上。Java redis客户端驱动jedis，支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool

优点

• 优势在于非常简单，服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强

缺点

• 由于sharding处理放到客户端，规模进一步扩大时给运维带来挑战。

• 客户端sharding不支持动态增删节点。服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。连接不能共享，当应用规模增大时，资源浪费制约优化
  

  客户端发送请求到一个代理组件，代理解析客户端的数据，并将请求转发至正确的节点，最后将结果回复给客户端
  

Redis主从复制的核心原理

为啥要主从复制：
主数据库可以进行读写操作，而从数据库一般是只读的，并接受主数据库同步过来的数据。

Master节点在平时提供服务，另外一个或多个Slave节点在平时不提供服务（或只提供数据读取服务）。当Master节点由于某些原因停止服务后，再人工/自动完成Slave节点到Master节点的切换工作，以便整个Redis集群继续向外提供服务。

全量复制：

部分复制：（增量复制）

说说Redis哈希槽的概念？

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

Redis集群会有写操作丢失吗？为什么？

Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

Redis集群之间是如何复制的？

异步复制

Redis集群最大节点个数是多少？

16384个

Redis集群如何选择数据库？

Redis集群目前无法做数据库选择，默认在0数据库。

Redis高可用集群搭建（了解）

如何做一个秒杀系统

稳
整个系统架构要满足高可用，流量符合预期时肯定要稳定，超出预期时也同样不能掉链子，你要保证秒杀活动顺利完成，即秒杀商品顺利地卖出去，这个是最基本的前提。
准
你的业务需求是秒杀10台iPhone XS，那就只能成交10台，多一台少一台都不行。一旦库存不对，那平台就要承担损失。
快
就是说系统的性能要足够高，否则你怎么支撑这么大的流量呢？不光是服务端要做极致的性能优化，而且在整个请求链路上都要做协同的优化，每个地方快一点，整个系统就完美了。
设计思路：将请求拦截在系统上游，降低下游压力。在一个并发量大，实际需求小的系统中，应当尽量在前端拦截无效流量，降低下游服务器和数据库的压力，不然很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。

限流：前端直接限流，允许少部分流量流向后端。（Nginx、计数器、滑动时间窗口、令牌桶、漏桶算法、Hystrix）
削峰：瞬时大流量峰值容易压垮系统，解决这个问题是重中之重。常用的消峰方法有异步处理、缓存和消息中间件等技术。
异步处理：秒杀系统是一个高并发系统，采用异步处理模式可以极大地提高系统并发量，其实异步处理就是削峰的一种实现方式。
内存缓存：秒杀系统最大的瓶颈一般都是数据库读写，由于数据库读写属于磁盘IO，性能很低，如果能够把部分数据或业务逻辑转移到内存缓存，效率会有极大地提升。Redis+JVM缓存（zookeeper同步）
消息队列：消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。
可拓展：当然如果我们想支持更多用户，更大的并发，最好就将系统设计成弹性可拓展的，如果流量来了，拓展机器就好了，像淘宝、京东等双十一活动时会临时增加大量机器应对交易高峰。
前端优化：页面静态化、静态资源优化、CDN优化
安全：防刷-验证码，流量削峰、秒杀下单接口地址隐藏

Redis性能优化

拒绝bigkey防止网卡流量、慢查询

bigkey：String类型一般认为超过10K就是bigkey
bigkey的危害：导致redis阻塞、网络阻塞、过期删除。
如何优化：拆、选择合适的数据类型、设置key的生命周期（建议打乱时间）

客户端使用

1.避免多个应用使用一个redis实例，把不相干的的业务拆分，公共数据做服务化。
2.使用带有连接池的数据库，可以有效控制连接、同时提高效率。如下

3.调节连接池的参数信息。
4.高并发下建议客户端添加熔断功能，如hystrix
5.对过期键进行清理。（8种策略）

其他：

模拟高并发的软件Apache JMeter 压测软件

Redis官方为什么不提供Windows版本？

因为目前Linux版本已经相当稳定，而且用户量很大，无需开发windows版本，反而会带来兼容性等问题。

一个字符串类型的值能存储最大容量是多少？

512M

Redis如何做大量数据插入？

Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入工作。

假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？

使用keys指令(模糊匹配)可以扫出指定模式的key列表。
对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。