redis和jwt

1.
JWT 的签名部分是用来做什么的:确保消息的完整性

2.
JWT 的头部部分是用来做什么的:声明类型和加密算法
 

3.
JWT 可以被用作什么:        1.用户认证        2.数据加密        3.传输数据

4.
JWT 的组成部分:        1.头部        2.载荷        3.签名

5.
关于SpringCache中的Cacheable注解，说法错误的是？
A.标注在方法上，也可以标注在类上
B.value缓存名、 key缓存键值
C.只能标注在方法上
D.标注在方法上表示缓存该方法的返回值
答案:C

6.
[单选题]
下面哪种 ID 生成机制需要访问数据库？
A.自增长 ID
B.UUID
C.Snowflake
D. 短 ID
答案:A

7.
[单选题]
JWT 的签名部分是怎么实现的？
A.使用密钥对整个 JWT 进行签名
B.使用密钥对头部和载荷分别进行签名
C.使用非对称加密算法对整个 JWT 进行签名
D.不需要签名
答案:A

8.
[单选题]
JWT 可以使用哪些算法来对载荷进行签名和加密？
A. HS256
B.RS256
C.ES256
D.以上都是
答案:D

9.
[多选题]
关于SpringCache中，CacheAble和CachePut注解说法正确的是？
A.@Cacheable 的逻辑是：查找缓存 - 有就返回 -没有就执行方法体 - 将结果缓存起来
B.@Cacheable 的逻辑是：执行方法体 - 将结果缓存起来
C.@CachePut 的逻辑是：执行方法体 - 将结果缓存起来
D.@CachePut 的逻辑是：查找缓存 - 有就返回 -没有就执行方法体 - 将结果缓存起来
答案:A  C

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

    雪花ID（Snowflake ID）是一种分布式 ID 生成算法，由Twitter公司开发。
它可以生成全局唯一的、有序的、可排序的64位长整型数字，
通常用于分布式系统中生成唯一ID。

雪花ID的结构如下：

每个雪花ID由以下部分组成：

时间戳（占用 41 位）：记录生成 ID 的时间，精确到毫秒级别，
                    可以支持 69 年的时间跨度。

机器标识（占用 10 位）：记录生成 ID 的机器标识，
                      可以支持 1024 台机器同时生成 ID。

序列号（占用 12 位）：记录同一毫秒内生成的不同 ID，
                    可以支持每台机器每毫秒生成 4096 个不同的 ID。

雪花ID的优点是：

高性能：生成速度快，不需要访问数据库或其他服务端资源。

唯一性：生成的ID具有全局唯一性，可以在分布式系统中被安全地使用。

有序性：生成的ID具有时间上的有序性，可以按照生成时间进行排序。

雪花ID的缺点是：

依赖于机器时钟：如果系统时钟不同步或者发生回拨，
会导致生成的ID有重复或者不连续的情况。

ID 可逆推：由于生成的 ID 中包含了时间戳信息，
可能会暴露系统的使用模式和规律，从而被恶意利用。

存储空间较大：每个 ID 需要占用 64 位的存储空间，
相比其他 ID 生成算法，存储空间较大。

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

    JWT（JSON Web Token）和 session 都是用于用户身份认证和授权的机制，
但它们之间有一些重要的区别。

机制不同
    Session 是由服务器生成的一种基于服务器端存储的认证机制。
当用户登录后，服务器会为该用户创建一个 session，
同时在客户端返回一个包含 session ID 的 cookie。
后续的请求会携带这个 cookie，服务器通过解析 cookie 中的 session ID，
来确定该请求对应的 session。

    JWT 是基于 token 的认证机制，不需要在服务器端保存任何状态。
当用户登录成功后，服务器会生成一个 JWT，将 JWT 发送给客户端，
客户端在后续的请求中携带 JWT，服务器通过对 JWT 的验证，
来确定该请求的合法性。

存储位置不同
    Session 的存储位置通常在服务器端，
服务器需要为每个 session 分配一定的内存来保存 session 数据。
这样会导致服务器端的内存开销较大，
同时也需要考虑 session 数据的备份和恢复等问题，
以保障 session 数据的可靠性。

    JWT 的存储位置通常在客户端，服务器不需要为 JWT 维护任何状态，
只需要在生成 JWT 时对其进行签名，以确保 JWT 的真实性和完整性。
客户端可以将 JWT 存储在 cookie、localStorage 等位置，
以便在后续的请求中携带 JWT。

跨域支持不同
    由于 session 是基于 cookie 的，
所以在跨域的场景下需要考虑 cookie 的安全性和传递问题。
通常需要通过特殊的配置或者使用一些第三方工具来解决跨域的问题。

    JWT 由于存储在客户端，所以天然支持跨域，
可以在不同的域名和服务器之间自由传递。

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

    SpringCache 是 Spring 框架提供的一种缓存解决方案，
提供了多种缓存注解，用于实现对方法执行结果的缓存控制。
常用的 SpringCache 注解包括：

    @Cacheable：将方法的返回值缓存起来，在下次调用该方法时，
如果缓存中存在相应的数据，则直接返回缓存中的数据，
否则执行方法体，并将方法的返回值缓存起来。

    @CachePut：用于更新缓存中的数据，它会执行方法体，
并将方法的返回值缓存起来。与 @Cacheable 不同的是，
@CachePut 注解不会检查缓存中是否已经存在相应的数据。

    @CacheEvict：用于清除缓存中的数据，
可以指定清除缓存的条件和方式。当满足指定条件时，
该注解会清除相应的缓存数据。

    @Caching：用于在一个方法中同时使用多个缓存注解，
可以通过该注解组合多个缓存注解。

13.
JWT 的优点是什么？

JWT（JSON Web Token）是一种基于 token 的认证机制，具有以下优点：

无状态：JWT 是无状态的，不需要在服务器端保存任何状态信息，
每个请求都是独立的。这样可以减少服务器端的存储压力，
提高系统的可扩展性和可靠性。

跨平台：JWT 是基于 JSON 格式的，可以在不同的平台和编程语言之间自由传递。
这样可以提高系统的可移植性和互操作性。

安全性高：JWT 使用密钥对 token 进行签名，
可以保证 token 的真实性和完整性，防止 token 被篡改或伪造。
同时，JWT 可以使用 HTTPS 等协议对数据进行加密传输，
保证数据的机密性。

易于实现：JWT 的实现非常简单，只需要使用一个库或者框架，
就可以轻松地实现 JWT 的生成、解析和验证等功能。同时，
JWT 也可以和其他认证机制（例如 OAuth2）进行集成，
提供更加完善的认证和授权解决方案。

可扩展性强：JWT 支持自定义的扩展字段，可以根据不同的业务需求，
灵活地定义 token 的内容和格式。

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

Redis 是一款高性能的内存数据库，它的数据可以持久化到磁盘中，
以保证数据的可靠性和可恢复性。Redis 支持两种持久化策略：RDB 和 AOF。

RDB 持久化
    RDB 持久化是通过定时将 Redis 的数据集快照写入磁盘来实现持久化。
快照是一个 Redis 数据的二进制序列化文件，
包含了 Redis 在某个时间点上的所有数据。
可以通过在配置文件中设置触发快照的条件（例如时间间隔、写入命令数等），
来控制快照的生成时机和频率。快照生成后，
可以将快照文件复制到其他机器上进行备份或者恢复。

    RDB 持久化的优点是快速、紧凑和可靠，
能够在 Redis 启动时快速地恢复大量数据，
同时也可以在备份和恢复时提高效率。

AOF 持久化
    AOF 持久化是通过将 Redis 的所有写命令追加到一个文件（AOF 文件）中来实现持久化。
AOF 文件是一个文本文件，包含了 Redis 执行的所有写命令，以及相应的参数和返回值。
可以通过在配置文件中设置 AOF 的同步模式（always、everysec 和 no），
来控制 AOF 文件的刷写时机和频率。
同时也可以通过 BGREWRITEAOF 命令来进行 AOF 文件的重写，
以减小 AOF 文件的体积和提高 Redis 的性能。

    AOF 持久化的优点是可以提供更高的数据安全性和可靠性，
能够更加细粒度地控制数据的持久化和恢复，
同时也可以通过 AOF 文件进行数据备份和迁移。

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

字符串（string）：字符串是 Redis 中最基本的数据类型，
可以存储任意类型的字符串、数字和二进制数据，支持多种操作，
例如获取、设置、追加、自增、自减等。

列表（list）：列表是一个有序的、可以重复的字符串列表，
支持在列表的两端进行插入和删除操作，还支持通过下标、
范围等方式对列表进行访问和修改。

集合（set）：集合是一个无序的、不重复的字符串集合，
支持对集合进行添加、删除、随机取值、求交集、并集、差集等操作。

有序集合（sorted set）：有序集合是一个有序的、不重复的字符串集合，
每个成员都关联一个分数，支持对有序集合进行添加、删除、按分数范围查询、
按分数排序等操作。

哈希表（hash）：哈希表是一个存储键值对的数据结构，可以存储任意类型的键和值，
支持对哈希表进行添加、删除、获取、修改等操作。

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

    跨域是指浏览器不能直接访问其他域名下的资源，
这是由于同源策略的限制导致的。常见的跨域解决方案包括：

    JSONP（JSON with padding）：JSONP 利用 <script> 标签可以跨域加载资源的特性，
通过在 URL 中传递一个回调函数名的方式，将数据封装成 JavaScript 代码，
从而实现跨域数据访问。

    CORS（Cross-Origin Resource Sharing）：CORS 是一种基于 HTTP 头部的跨域解决方案，
通过在服务器端设置响应头，允许指定的源访问资源，实现跨域访问。需要注意的是，
CORS 方案需要浏览器和服务器端共同支持。

    WebSocket：WebSocket 是一种全双工通信协议，
可以在浏览器和服务器之间建立一个持久化的连接，实现实时通信和跨域数据传输。

    代理（Proxy）：代理是一种将请求转发到其他服务器的方式，
可以在服务器端实现跨域访问。例如，可以通过在服务器端配置反向代理，
将资源的请求转发到其他域名下的服务器上。

postMessage：HTML5 中新增了 postMessage 方法，可以在不同的窗口之间传递消息，
从而实现跨域数据传输。

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

    Redis 的缓存雪崩是指，在某个时间段内，大量缓存的 key 同时失效或过期，
导致大量请求直接访问数据库，导致数据库瞬时压力过大甚至宕机的现象。
这种情况往往是由于缓存的 key 在同一时间失效或过期，导致请求直接打到数据库上，
从而引起数据库的压力过大。

为了避免缓存雪崩，可以采取以下措施：

设置过期时间时，加上一个随机值，使不同 key 的过期时间错开，避免同时失效。

对热点数据进行永久缓存，减少缓存失效的可能性。

设置本地缓存，避免 Redis 宕机时大量请求直接访问数据库。

使用集群部署，将缓存分散到多个节点上，避免单点故障。

使用限流、降级等手段，控制请求量，避免瞬时压力过大。

定期对缓存进行预热，避免缓存冷启动时大量请求访问数据库。

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

Redis 的缓存穿透是指查询一个不存在的 key，由于缓存和数据库中都没有对应的数据，
导致大量请求直接打到数据库上，从而引起数据库的压力过大甚至宕机的现象。

缓存穿透可以通过以下措施进行解决：

布隆过滤器（Bloom Filter）：布隆过滤器是一种高效的数据结构，
可以用于判断一个 key 是否存在于缓存中，如果不存在，则可以直接返回结果，
避免了对数据库的查询。

对查询结果为空的 key，设置一个默认值，将其作为缓存返回，
避免对数据库的反复查询。

设置短期内的本地缓存，避免缓存穿透的请求直接访问数据库。

对热点数据进行永久缓存，避免缓存失效的可能性，从而避免缓存穿透的问题。

对恶意攻击进行限流、封禁等措施，防止缓存穿透攻击。

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

Redis 的缓存击穿是指某个热点 key 在缓存失效的瞬间，遭受大量的请求，
从而直接访问数据库，引起数据库的瞬时压力过大甚至宕机的现象。
这种情况往往是由于某些热点数据的访问频率非常高，导致缓存失效的瞬间，
大量请求直接打到数据库上，从而引起数据库的压力过大。

缓存击穿可以通过以下措施进行解决：

设置热点数据永久缓存，避免缓存失效的可能性，从而避免缓存击穿的问题。

对热点数据设置较短的过期时间，并对过期时间进行随机化，
避免所有热点数据在同一时间失效，从而避免缓存击穿的问题。

使用互斥锁（Mutex）或分布式锁（Distributed Lock）等机制，
保证只有一个请求访问数据库，其余请求等待结果即可。

对查询结果为空的 key，设置一个默认值，将其作为缓存返回，
避免对数据库的反复查询。

使用缓存预热技术，提前加载热点数据到缓存中，避
免缓存冷启动时大量请求访问数据库。

20.
Redis的数据过期策略？

Redis 的数据过期策略主要有两种：定时删除和惰性删除。

定时删除：Redis 会为每个设置过期时间的 key 创建一个定时器，
到达过期时间时，定时器会立即将 key 删除。定时删除策略对系统的资源消耗较大，
但能够及时删除过期的 key，避免占用过多的内存空间。

惰性删除：惰性删除是指在获取某个 key 的时候，Redis 会先判断该 key 是否过期，
如果过期则立即删除。惰性删除策略对系统的资源消耗较小，
但可能会产生过期 key 未及时删除的情况，占用过多的内存空间。

Redis 会根据实际情况自动选择定时删除和惰性删除策略。
当 Redis 的内存使用率超过设置的阈值时，会优先采用惰性删除策略，
尽可能释放内存空间；当内存使用率低于阈值时，会采用定时删除策略，
及时删除过期的 key。

需要注意的是，定时删除和惰性删除策略都可能存在数据过期的时间窗口
（即 key 已过期但未被删除的时间段），为了避免这种情况，
可以通过设置较短的过期时间、使用惰性删除策略并配合定期执行删除操作等方式进行优化。