1、为什么需要缓存，缓存的意义和底层原理是什么？
由于计算机体系结构的设计问题，所有的程序都会在CPU之中进行运算，然而考虑到计算数据的完整性，所有的数据不会通过磁盘加载，而是会通过内存进行数据的缓存，最终才会被加载到CPU之中，这样一来在整个项目的运行过程之中，如果磁盘IO的操作性能较差，那么最终就会导致程序变慢。
2、讲一讲你常用的缓存工具（单机与分布式）？
单机缓存工具
Caffeine
Caffeine Cache 以其高性能和可扩展性赢得「 本地缓存之王 」的称号，它是一个 Java 缓存库。 Spring Boot 1.x 版本中的默认本地缓存是 Guava Cache。但在 Spring5 （SpringBoot 2.x）后，Spring 官方放弃了 Guava Cache 作为缓存机制，而是使用性能更优秀的 Caffeine 作为默认缓存组件。 我举例一些特功能：
Caffeine 支持异步加载缓存数据
Caffeine 提供了丰富的统计信息和监控功能，可以监控缓存的命中率、加载时间等指标。 Caffeine 提供了多种内存管理策略（过期机制管理）
Guava Cache
Guava Cache 是 Google 提供的 Java 缓存库
简单易用的 API、功能相对比价丰富。
EhCache
特色：EhCache提供了非常丰富的功能，不但可以将数据存储在JVM内部，还可以放到堆外（供了堆外缓存off-heap）
分布式缓存工具
Redis
基于内存的日志型Key-Value数据库。还支持事务、持久化、Lua脚本、LRU驱动事件和多种集群方案。
Redis的特点包括：
-
纯内存操作：数据存储在内存中，类似于HashMap，提供快速的查找和操作。
-
单线程操作：网络请求模块使用一个线程，避免多线程的CPU上下文切换和锁的问题，减少性能消耗。
-
多路I/O复用：使用I/O多路复用程序同时监听多个套接字，能够处理多个客户端连接，减少资源占用。
Redis的读写速度非常快，每秒可以处理超过10万次读写操作，因此它被广泛应用于缓存和分布式锁等场景。此外，Redis还提供了特殊的数据结构类型，如GEO、Hyperloglog和Bitmap。
Memcached
简单的一个分布式缓存，不支持持久化、数据类型只支持文本和二进制。
MongoDB
基于c++开发。是nosql数据库中功能最丰富，最像关系数据库的。
l 面向集合文档的存储：适合存储Bson（json的扩展）形式的数据；
l 格式自由，数据格式不固定，生产环境下修改结构都可以不影响程序运行；
l 强大的查询语句，面向对象的查询语言，基本覆盖sql语言所有能力；
l 完整的索引支持，支持查询计划；
l 支持复制和自动故障转移；
l 支持二进制数据及大型对象（文件）的高效存储；
l 使用分片集群提升系统扩展性；
l 使用内存映射存储引擎，把磁盘的IO操作转换成为内存的操作；
3、为什么要用Redis缓存（Redis缓存的优势）
Redis的好处
读取速度快，因为数据存在内存中，所以数据获取快，单机轻松10W+并发
支持多种数据结构，包括字符串、列表、集合、有序集合、哈希等
还拥有其他丰富的功能，主从复制、集群、数据持久化等
可以实现其他丰富的功能，消息队列、分布式锁等
4、如何理解Redis的单线程与Redis的多线程
单线程
C语言实现，效率高
C语言程序运行时要比其他语言编写的程序快得多，因为它"离底层机器很近"
单线程的优势
使用了单线程后，可维护性高。多线程模型虽然在某些方面表现优异，但是它却引入了程序执行顺序的不确定性，带来了并发读写的一系列问题，增加了系统复杂度、同时可能存在线程切换、甚至加锁解锁、死锁造成的性能损耗
Pipeline
Redis主要受限于内存和网络，几乎不会占用太多CPU。可以将命令和pipeline结合起来使用，减少命令在网络上的传输时间，将多次网络IO缩减为一次网络IO，通过使用pipeline每秒可以处理100万个请求。
存储实现优化
Redis的基础数据结构每一种至少有2种及2种以上的实现，在不同的大小或长度下选用适合的数据类型，达到极致的存储效率，从而提高写入和读取速度。
多线程
Redis多线程比单线程性能提升一倍：
Redis 作者 antirez 在 RedisConf 2019分享时曾提到：Redis 6 引入的多线程 IO 特性对性能提升至少是一倍以上。国内也有大牛曾使用unstable版本在阿里云esc进行过测试，GET/SET 命令在4线程 IO时性能相比单线程是几乎是翻倍了
巨头公司的需求
Redis将所有数据放在内存中，内存的响应时长大约为100纳秒，对于小数据包，Redis服务器可以处理80,000到100,000 QPS，这也是Redis处理的极限了，对于80%的公司来说，单线程的Redis已经足够使用了。
但随着越来越复杂的业务场景，有些公司动不动就上亿的交易量，因此需要更大的QPS。
集群方案的问题
常见的解决方案是在分布式架构中对数据进行分区并采用多个服务器，但该方案有非常大的缺点，例如要管理的Redis服务器太多，维护代价大；
某些适用于单个Redis服务器的命令不适用于数据分区；
数据分区无法解决热点读/写问题；数据偏斜，重新分配和放大/缩小变得更加复杂等等。
1.纯内存KV操作
Redis的操作都是基于内存的，CPU不是 Redis性能瓶颈,，Redis的瓶颈是机器内存和网络带宽。
在计算机的世界中，CPU的速度是远大于内存的速度的，同时内存的速度也是远大于硬盘的速度。redis的操作都是基于内存的，绝大部分请求是纯粹的内存操作，非常迅速。
2.单线程操作
使用单线程可以省去多线程时CPU上下文会切换的时间，也不用去考虑各种锁的问题，不存在加锁释放锁操作，没有死锁问题导致的性能消耗。对于内存系统来说，多次读写都是在一个CPU上，没有上下文切换效率就是最高的！既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章的采用单线程的方案了
Redis 单线程指的是网络请求模块使用了一个线程，即一个线程处理所有网络请求，其他模块该使用多线程，仍会使用了多个线程。
3.I/O 多路复用
为什么 Redis 中要使用 I/O 多路复用这种技术呢？
首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用就是为了解决这个问题而出现的
4.Reactor 设计模式
Redis 文件事件处理器由四个部分组成：套接字、I/O多路复用程序、文件时间分派器（dispatcher）、事件处理器。
文件事件是对套接字操作的抽象，每当一个套接字准备好执行连接应答（accept）、写入（write）、读取（read）、关闭（close）等操作时，就会相应产生一个文件事件。
I/O多路复用器负责通过loop循环监听多个套接字，同时将一系列套接字按循序存储到一个队列中，由队列向文件事件分派器传送队列中套接字。这个队列中套接字是有序的，它会当一个套接字事件被处理完毕后，会立马向文件事件分配器传送下一个套接字。
文件事件分配器接受队列中的套接字并根据套接字产生的事件类型，相应调用不同的事件处理器
5、Redis常见数据类型与运用场景
字符串（String）
适合场景
缓存功能
Redis 作为缓存层，MySQL作为存储层，绝大部分请求的数据都是从Redis中获取。由于Redis具有支撑高并发的特性,所以缓存通常能起到加速读写和降低后端压力的作用。
计数
使用Redis 作为计数的基础工具，它可以实现快速计数、查询缓存的功能,同时数据可以异步落地到其他数据源。
共享Session
一个分布式Web服务将用户的Session信息（例如用户登录信息)保存在各自服务器中，这样会造成一个问题，出于负载均衡的考虑，分布式服务会将用户的访问均衡到不同服务器上，用户刷新一次访问可能会发现需要重新登录，这个问题是用户无法容忍的。
为了解决这个问题,可以使用Redis将用户的Session进行集中管理,，在这种模式下只要保证Redis是高可用和扩展性的,每次用户更新或者查询登录信息都直接从Redis中集中获取。
限速
比如，很多应用出于安全的考虑,会在每次进行登录时,让用户输入手机验证码,从而确定是否是用户本人。但是为了短信接口不被频繁访问,会限制用户每分钟获取验证码的频率，例如一分钟不能超过5次。一些网站限制一个IP地址不能在一秒钟之内方问超过n次也可以采用类似的思路。
哈希(Hash)
Java里提供了HashMap，Redis中也有类似的数据结构，就是哈希类型。但是要注意，哈希类型中的映射关系叫作field-value，注意这里的value是指field对应的值，不是键对应的值。
适合场景
哈希类型比较适宜存放对象类型的数据，我们可以比较下，如果数据库中表记录user为：
| id | name | age |
|---|---|---|
| 1 | lijin | 18 |
| 2 | msb | 20 |
1、使用String类型
需要一条条去插入获取。
set user:1:name lijin;
set user:1:age 18;
set user:2:name msb;
set user:2:age 20;
优点：简单直观，每个键对应一个值
缺点：键数过多，占用内存多，用户信息过于分散，不用于生产环境
2、使用hash类型
hmset user:1 name lijin age 18
hmset user:2 name msb age 20
优点：简单直观，使用合理可减少内存空间消耗
列表（list）
列表( list)类型是用来存储多个有序的字符串，a、b、c、c、b四个元素从左到右组成了一个有序的列表,列表中的每个字符串称为元素(element)，一个列表最多可以存储(2^32-1)个元素(4294967295)。
适合场景
每个用户有属于自己的文章列表，现需要分页展示文章列表。此时可以考虑使用列表,因为列表不但是有序的,同时支持按照索引范围获取元素。
消息队列，Redis 的 lpush+brpop命令组合即可实现阻塞队列，生产者客户端使用lrpush从列表左侧插入元素，多个消费者客户端使用brpop命令阻塞式的"抢"列表尾部的元素,多个客户端保证了消费的负载均衡和高可用性。
集合（set）
集合( set）类型也是用来保存多个的字符串元素,但和列表类型不一样的是，集合中不允许有重复元素,并且集合中的元素是无序的,不能通过索引下标获取元素。
适合场景
集合类型比较典型的使用场景是标签(tag)。例如一个用户可能对娱乐、体育比较感兴趣，另一个用户可能对历史、新闻比较感兴趣，这些兴趣点就是标签。有了这些数据就可以得到喜欢同一个标签的人，以及用户的共同喜好的标签，这些数据对于用户体验以及增强用户黏度比较重要。
例如一个电子商务的网站会对不同标签的用户做不同类型的推荐，比如对数码产品比较感兴趣的人，在各个页面或者通过邮件的形式给他们推荐最新的数码产品，通常会为网站带来更多的利益。
除此之外，集合还可以通过生成随机数进行比如抽奖活动，以及社交图谱等等。
有序集合（ZSET）
有序集合相对于哈希、列表、集合来说会有一点点陌生,但既然叫有序集合,那么它和集合必然有着联系,它保留了集合不能有重复成员的特性,但不同的是,有序集合中的元素可以排序。但是它和列表使用索引下标作为排序依据不同的是,它给每个元素设置一个分数( score)作为排序的依据。
有序集合中的元素不能重复，但是score可以重复，就和一个班里的同学学号不能重复,但是考试成绩可以相同。
有序集合提供了获取指定分数和元素范围查询、计算成员排名等功能，合理的利用有序集合，能帮助我们在实际开发中解决很多问题。
有序集合比较典型的使用场景就是排行榜系统。例如视频网站需要对用户上传的视频做排行榜，榜单的维度可能是多个方面的:按照时间、按照播放数量、按照获得的赞数。
6、讲一讲Redis的高级数据类型与运用场景
Bitmaps
现代计算机用二进制(位)作为信息的基础单位，1个字节等于8位，例如"big"字符串是由3个字节组成，但实际在计算机存储时将其用二进制表示,"big"分别对应的ASCII码分别是98、105、103，对应的二进制分别是01100010、01101001和 01100111。
许多开发语言都提供了操作位的功能，合理地使用位能够有效地提高内存使用率和开发效率。Redis提供了Bitmaps这个"数据结构"可以实现对位的操作。把数据结构加上引号主要因为:
Bitmaps本身不是一种数据结构，实际上它就是字符串，但是它可以对字符串的位进行操作。
Bitmaps单独提供了一套命令，所以在Redis中使用Bitmaps和使用字符串的方法不太相同。可以把 Bitmaps想象成一个以位为单位的数组，数组的每个单元只能存储0和1，数组的下标在 Bitmaps 中叫做偏移量。
布隆过滤器
1970 年布隆提出了一种布隆过滤器的算法，用来判断一个元素是否在一个集合中。 这种算法由一个二进制数组和一个 Hash 算法组成。
本质上布隆过滤器是一种数据结构，比较巧妙的概率型数据结构（probabilistic data structure），特点是高效地插入和查询，可以用来告诉你 "某样东西一定不存在或者可能存在"。
相比于传统的 List、Set、Map 等数据结构，它更高效、占用空间更少，但是缺点是其返回的结果是概率性的，而不是确切的。
实际上，布隆过滤器广泛应用于网页黑名单系统、垃圾邮件过滤系统、爬虫网址判重系统等，Google 著名的分布式数据库 Bigtable 使用了布隆过滤器来查找不存在的行或列，以减少磁盘查找的IO次数，Google Chrome浏览器使用了布隆过滤器加速安全浏览服务。
HyperLogLog
介绍
HyperLogLog(Hyper[ˈhaɪpə(r)])并不是一种新的数据结构(实际类型为字符串类型)，而是一种基数算法,通过HyperLogLog可以利用极小的内存空间完成独立总数的统计，数据集可以是IP、Email、ID等。
如果你负责开发维护一个大型的网站，有一天产品经理要网站每个网页每天的 UV 数据，然后让你来开发这个统计模块，你会如何实现？
如果统计 PV 那非常好办，给每个网页一个独立的 Redis 计数器就可以了，这个计数器的 key 后缀加上当天的日期。这样来一个请求，incrby 一次，最终就可以统计出所有的 PV 数据。
但是 UV 不一样，它要去重，同一个用户一天之内的多次访问请求只能计数一次。这就要求每一个网页请求都需要带上用户的 ID，无论是登陆用户还是未登陆用户都需要一个唯一 ID 来标识。
一个简单的方案，那就是为每一个页面一个独立的 set 集合来存储所有当天访问过此页面的用户 ID。当一个请求过来时，我们使用 sadd 将用户 ID 塞进去就可以了。通过 scard 可以取出这个集合的大小，这个数字就是这个页面的 UV 数据。
但是，如果你的页面访问量非常大，比如一个爆款页面几千万的 UV，你需要一个很大的 set集合来统计，这就非常浪费空间。如果这样的页面很多，那所需要的存储空间是惊人的。为这样一个去重功能就耗费这样多的存储空间，值得么？其实需要的数据又不需要太精确，105w 和 106w 这两个数字对于老板们来说并没有多大区别，So，有没有更好的解决方案呢？
这就是HyperLogLog的用武之地，Redis 提供了 HyperLogLog 数据结构就是用来解决这种统计问题的。HyperLogLog 提供不精确的去重计数方案，虽然不精确但是也不是非常不精确，Redis官方给出标准误差是0.81%，这样的精确度已经可以满足上面的UV 统计需求了。
GEO
Redis 3.2版本提供了GEO(地理信息定位)功能，支持存储地理位置信息用来实现诸如附近位置、摇一摇这类依赖于地理位置信息的功能。
地图元素的位置数据使用二维的经纬度表示，经度范围(-180, 180]，纬度范围(-90,90]，纬度正负以赤道为界，北正南负，经度正负以本初子午线(英国格林尼治天文台) 为界，东正西负。
业界比较通用的地理位置距离排序算法是GeoHash 算法，Redis 也使用GeoHash算法。GeoHash 算法将二维的经纬度数据映射到一维的整数，这样所有的元素都将在挂载到一条线上，距离靠近的二维坐标映射到一维后的点之间距离也会很接近。当我们想要计算「附近的人时」，首先将目标位置映射到这条线上，然后在这个一维的线上获取附近的点就行了。
操作命令
增加地理位置信息
geoadd key longitude latitude member [longitude latitude member ...J
longitude、latitude、member分别是该地理位置的经度、纬度、成员，例如下面有5个城市的经纬度。
城市 经度 纬度 成员
北京 116.28 39.55 beijing
天津 117.12 39.08 tianjin
石家庄 114.29 38.02 shijiazhuang
唐山 118.01 39.38 tangshan
保定 115.29 38.51 baoding
cities:locations是上面5个城市地理位置信息的集合，现向其添加北京的地理位置信息:
geoadd cities :locations 116.28 39.55 beijing
返回结果代表添加成功的个数，如果cities:locations没有包含beijing,那么返回结果为1，如果已经存在则返回0。
如果需要更新地理位置信息，仍然可以使用geoadd命令，虽然返回结果为0。geoadd命令可以同时添加多个地理位置信息:
geoadd cities:locations 117.12 39.08 tianjin 114.29 38.02 shijiazhuang 118.01 39.38 tangshan 115.29 38.51 baoding
获取地理位置信息
geopos key member [member ...]下面操作会获取天津的经维度:
geopos cities:locations tianjin1)1)"117.12000042200088501"
获取两个地理位置的距离。
geodist key member1 member2 [unit]
其中unit代表返回结果的单位，包含以下四种:
m (meters)代表米。
km (kilometers)代表公里。
mi (miles)代表英里。
ft(feet)代表尺。
下面操作用于计算天津到北京的距离，并以公里为单位:
geodist cities : locations tianjin beijing km
获取指定位置范围内的地理信息位置集合
georadius key longitude latitude radius m|km|ft|mi [withcoord][withdist]
[withhash][COUNT count] [ascldesc] [store key] [storedist key]
georadiusbymember key member radius m|km|ft|mi [withcoord][withdist]
[withhash] [COUNT count][ascldesc] [store key] [storedist key]
georadius和georadiusbymember两个命令的作用是一样的，都是以一个地理位置为中心算出指定半径内的其他地理信息位置，不同的是georadius命令的中心位置给出了具体的经纬度，georadiusbymember只需给出成员即可。其中radius m | km |ft |mi是必需参数，指定了半径(带单位)。
这两个命令有很多可选参数，如下所示:
withcoord:返回结果中包含经纬度。
withdist:返回结果中包含离中心节点位置的距离。
withhash:返回结果中包含geohash，有关geohash后面介绍。
COUNT count:指定返回结果的数量。
asc l desc:返回结果按照离中心节点的距离做升序或者降序。
store key:将返回结果的地理位置信息保存到指定键。
storedist key:将返回结果离中心节点的距离保存到指定键。
下面操作计算五座城市中,距离北京150公里以内的城市:
georadiusbymember cities:locations beijing 150 km
获取geohash
geohash key member [member ...]Redis使用geohash将二维经纬度转换为一维字符串，下面操作会返回beijing的geohash值。
geohash cities: locations beijing
字符串越长,表示的位置更精确，geohash长度为9时,精度在2米左右，geohash长度为8时,精度在20米左右。
两个字符串越相似,它们之间的距离越近,Redis 利用字符串前缀匹配算法实现相关的命令。
geohash编码和经纬度是可以相互转换的。
删除地理位置信息
zrem key member
GEO没有提供删除成员的命令，但是因为GEO的底层实现是zset，所以可以借用zrem命令实现对地理位置信息的删除。