JWT、Redis常见问题整理

JWT、Redis常见问题整理：

首先简单了解JWT

JWT由三部分组成，它们之间用圆点(.)连接,分别是：Header(头部) 、Payload(负载)、Signature(签名)即：Header.Payload.Signature,下面我们一一了解：
1、header
Header 部分是一个 JSON 对象，描述 JWT 的元数据，通常是下面的样子。
json { “alg”: “HS256”, “typ”: “JWT” }
上面代码中，alg属性表示签名的算法(algorithm)，默认是 HMAC SHA256(写成 HS256)；typ属性表示这个令牌(token)的类型(type)，JWT 令牌统一写为JWT。将上面的 JSON 对象使用 Base64URL 算法转成字符串。
2、payload
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。它包含Claim。Claim中存的就是这些字段，有三种类型：
Registered claims 预定义的声明 - Public claims 公开声明 - Private claims 私有声明
JWT 规定了7个Registered claims: iss (issuer)：签发人 exp (expiration time)：过期时间 sub (subject)：主题 aud (audience)：受众 nbf (Not Before)：生效时间 iat (Issued At)：签发时间 jti (JWT ID)：编号 除了官方字段，你还可以在这个部分定义私有字段。注意：JWT默认是明文展示，任何人都可以读取到，所以此处不要放私密信息.
3、signature
Signature 部分是对前两部分的签名，防止数据篡改。
首先，需要指定一个密钥(secret)。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法(默认是 HMAC SHA256)，按照下面的公式产生签名。HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)
签名是用于验证消息在传递过程中有没有被更改，并且，对于使用私钥签名的token，它还可以验证JWT的发送方是否为它所称的发送方。
算出签名以后，把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"(.)分隔，就可以返回给用户。

1.JWT 的签名部分是用来做什么的？

A. 确保消息的完整性
B.确保消息的机密性
C.确保消息的可用性
D.以上都不是
答案：A。JWT的签名部分用来确保消息的完整性，防止数据被篡改，而不是保证机密性或可用性。

---

2.JWT 的头部部分是用来做什么的？

A.声明类型和加密算法
B.存储用户信息
C.存储访问权限
D.储存数据加密方式
答案：A。JWT的头部部分声明了该JWT的类型（一般为JWT）和使用的加密算法（如HS256），客户端可以根据这些信息对JWT进行解码。

---

3.JWT 可以被用作什么？

A.用户认证
B.数据加密
C.传输数据
D.A、B、C 都是
答案：A。JWT通常用于用户认证和授权，在用户登录后生成一个JWT并存储在客户端，以后每次请求都将JWT放入HTTP头中作为认证凭证，服务器验证JWT的有效性即可实现认证和授权。

---

4.以下哪个不是 JWT 的组成部分？

A.头部
B.载荷
C.签名
D.数据库
答案：D。JWT由头部、载荷和签名三部分组成，其中数据库并不是JWT的组成部分。

---

5.关于SpringCache中的Cacheable注解，说法错误的是？

A.标注在方法上，也可以标注在类上
B.value缓存名、 key缓存键值
C.只能标注在方法上
D.标注在方法上表示缓存该方法的返回值
答案：C。@Cacheable注解标注在方法上，表示当执行方法时，Spring会先查询缓存中是否存在所需数据，若存在则直接返回缓存中的数据；否则执行方法体，并将方法的返回值放入缓存中。而类上标注@Cacheable，表示对该类所有公共方法都生效。需要补充的是，@Cacheable注解只能标注在方法上，如果要对一个类中所有公共方法添加缓存功能，可以使用AOP代理。

---

6.下面哪种 ID 生成机制需要访问数据库？

A.自增长 ID
B.UUID
C.Snowflake
D. 短 ID
答案：A。自增长ID需要访问数据库，常见于MySQL自增主键的方式，每次插入一条记录时，自动将ID加1，需要频繁访问数据库，不适合高并发场景。

---

7.JWT 的签名部分是怎么实现的？

A.使用密钥对整个 JWT 进行签名
B.使用密钥对头部和载荷分别进行签名
C.使用非对称加密算法对整个 JWT 进行签名
D.不需要签名
答案：A。JWT的签名部分使用HS256等对称加密算法，使用同一个密钥对整个JWT进行签名，确保JWT的完整性。

---

8.JWT 可以使用哪些算法来对载荷进行签名和加密？

A. HS256
B.RS256
C.ES256
D.以上都是
答案：D。JWT可以使用HS256、RS256、ES256等算法对载荷进行签名和加密，根据实际需求选择不同的算法。

---

9.关于SpringCache中，CacheAble和CachePut注解说法正确的是？

A.@Cacheable 的逻辑是：查找缓存 - 有就返回 -没有就执行方法体 - 将结果缓存起来
B.@Cacheable 的逻辑是：执行方法体 - 将结果缓存起来
C.@CachePut 的逻辑是：执行方法体 - 将结果缓存起来
D.@CachePut 的逻辑是：查找缓存 - 有就返回 -没有就执行方法体 - 将结果缓存起来
答案：A、C。@Cacheable注解表示从缓存中查询数据，如果缓存中有数据，则返回缓存中的数据；否则执行方法体，并将方法的返回值放入指定的缓存中，key表示指定缓存的名称，value表示缓存的键值；而@CachePut注解表示更新缓存，无论缓存中是否存在，都会执行方法体，并将方法的返回值放入指定的缓存中，key和value与@Cacheable一致。

---

10.什么是雪花id，简述雪花id的优缺点？

答案：雪花ID（Snowflake）是Twitter开源的一种分布式ID生成算法，它可以生成一个全局唯一的64位整数，其中包含了时间戳、工作机器ID、序列号等信息。雪花ID的优点是：1）高效：通过位运算实现高效的ID生成；2）唯一性：生成的ID全局唯一，且按照时间递增排序；3）可反解：由于ID中包含时间戳等信息，因此可以根据ID反解出生成时间、工作机器ID等信息。缺点是：1）依赖机器时钟：如果机器时钟不准确，会导致生成的ID不唯一；2）有一定的并发问题：如果同一毫秒内多个请求生成ID，可能会导致序列号重复。需要补充的是，雪花ID的生成算法可以按照实际需求进行修改，如扩展位数、修改时间戳格式等。

---

11.JWT 和 session 的区别是什么？

答案：JWT和session都可以用于用户认证和授权，但两者主要的区别在于：1）JWT是无状态的，即服务器不需要保存用户信息，只需要验证JWT的有效性；而session需要在服务器端保存用户信息，并通过Session ID来维持客户端和服务端的会话状态；2）JWT可以跨域传输，适用于微服务、API网关等场景；而session在跨域传输时需要考虑一些额外的问题

---

12.简要描述SpringCache的常用注解

答案：SpringCache的常用注解包括：
● @Cacheable：标注在方法上，表示将方法返回结果缓存起来，以后调用相同的参数时直接返回缓存数据；
● @CachePut：标注在方法上，表示将方法返回结果缓存起来，每次调用都会执行方法体；
● @CacheEvict：标注在方法上，表示从缓存中删除数据；
● @Caching：可以同时使用多个缓存操作注解，如@CacheEvict、@CachePut等；
● @CacheConfig：可以在类上统一配置缓存名称和缓存管理器等信息。

---

13.JWT 的优点是什么？

答案：JWT的优点包括：
● 无状态：JWT是无状态的，服务器不需要保存用户信息，只需要验证JWT的有效性，因此可以很好地支持分布式系统和微服务架构。
● 安全性高：JWT使用签名保证安全性，防止数据被篡改；并且不容易受到CSRF攻击和XSS攻击，可以很好地保护Web应用程序。
● 前后端分离：JWT可以让前后端分离开发，后端只需要提供API接口，前端负责处理用户界面，并将JWT存储在客户端，提升了系统的灵活性和可维护性。
● 可扩展性：JWT的载荷部分可以自定义，可以添加任意信息，方便扩展。

---

14.简述Redis的持久化策略？

答案：Redis的持久化策略分为RDB和AOF两种：
● RDB：保存Redis在某个时间点的数据快照，可以手动执行或者定时执行，将内存中的快照保存到磁盘上。RDB持久化方式的优点是备份数据快速且完整，缺点是可能存在数据丢失。
● AOF：按照一定的规则将Redis执行的写命令记录下来，以日志的形式保存到磁盘上。AOF持久化方式的优点是数据更加安全，缺点是备份速度较慢。

---

15.列举Redis的常用数据类型？

答案：Redis的常用数据类型包括：
● String：最基本的数据类型，可以存储字符串、整数、浮点数等；
● Hash：类似于Java中的Map，由多个键值对组成；
● List：类似于Java中的List，由多个元素组成，支持头尾插入、删除等操作；
● Set：不允许重复元素的集合，支持交、并、差等操作；
● Sorted Set：有序的不允许重复元素的集合，支持按照分值排序。

---

16.跨域的常用解决方案？

答案：跨域的常用解决方案包括：
● JSONP：利用

---

17.什么是redis的缓存雪崩？如何解决

答案：Redis的缓存雪崩是指大量缓存数据同时失效，导致所有请求都落到数据库上，引起数据库压力过大而崩溃。解决方法包括：
● 设置不同的过期时间或者过期时间随机化，避免所有缓存同时失效，保证缓存层服务高可用性；
● 引入熔断机制，当数据库压力过大时，自动降级或者返回预先设定的默认值；
● 对缓存系统做实时监控，报警。
● 依赖隔离组件为后端限流并降级。
● 做好持久化，以便数据的快速恢复。
● 不设置过期时间，由后台定时更新缓存

---

18.什么是redis的缓存穿透？如何解决

答案：缓存穿透是指数据既不在缓存中，也不在数据库，比如不存在的数据，绕过了缓存去请求数据库。
1、白名单或者黑名单，限制非法请求
2、针对缓存击穿现象的字段，设置空值或者默认值
3、布隆过滤器

---

19.什么是redis的缓存击穿？如何解决

答案：而缓存击穿是一个热点的Key，有大并发集中对其进行访问，突然间这个Key失效了，导致大并发全部打在数据库上，导致数据库压力剧增。这种现象就叫做缓存击穿。可以看作缓存雪崩的子集，思路跟缓存雪崩类似，对于热点的key可以设置永不过期的key，后台来更新缓存

---

20.Redis的数据过期策略？

答案：1、定时删除：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
2、惰性删除：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
3、定期删除：每隔一段时间执行一次删除(在redis.conf配置文件设置hz，1s刷新的频率)过期key操作