项目介绍：

此项目旨在推动成都市探索**超大城市社区发展治理新路**，由三个实验室负责三大内容

1、**研发社区阵地空间管理模块**：AI算法实现态势感知（如通过社区图片和视频、文本，对环境 空间质量、绿视率、安全感分数、压抑感分数等.....）

2、**社区服务机器人**：门禁控制、视频监控检测

3、**社区“微网实格”智慧管理综合服务平台**：党群服务、大数据管理、AI能力管理、与上面两 大块的集成

项目负责：

1. 数据库设计：设计 MySQL 关系型数据库，配置 多数据源（MySQL + HDFS + Redis+OSS），确保数据存储高效、稳定。
2. 后端接口开发：基于 Spring Boot + MyBatis Plus 开发 RESTful API，处理用户请求，保证前后端数据交互流畅。
3. 分布式存储 & 文件管理：基于 HDFS + Redis + 对象存储 设计 缓存策略，优化数据查询性能。

项目亮点难点：

1.AOP（面向切面编程）+ Redis

2.多线程控制

问题一：

1. 为什么采用 AOP？

如果不使用AOP，则需要直接在代码中手写缓存逻辑

• 需要在 每个查询方法 中手动写 Redis 查询 + MySQL 查询 + Redis 存储，代码重复且维护成本高
• 如果有 多个业务场景，每个查询都要写 相同的逻辑，代码冗余
• 逻辑分散在多个地方，不便于统一管理和修改

2. 为什么使用 AOP + Redis？

AOP 允许我们在不改动业务逻辑的情况下，把缓存逻辑封装成一个可复用的模块，然后在需要的地方自动生效，避免手写大量重复代码。

AOP用到的场景：

• 社区居民 获取 政策法规、社区公告等

AOP 带来的优势：

✅ 解耦业务代码

• 把 缓存逻辑 和 业务逻辑 分离，业务代码更干净
• 业务代码 只关心业务，不需要关心 Redis 的处理逻辑

✅ 统一维护

• 以后要调整 Redis 缓存策略（比如过期时间、缓存结构），只需要修改 AOP 代码，不需要改动多个业务方法

✅ 提高代码复用性

• AOP 只写一次，所有查询都可以使用，不需要重复写 Redis 逻辑

✅ 便于扩展

• 未来如果要增加 缓存穿透、缓存击穿、缓存雪崩 处理逻辑，只需要改 AOP 一处代码，所有缓存逻辑都生效

总结：AOP + Redis 的核心注解

问题二：

监控视频流需要实时调用算法接口（如人脸识别、行为分析），单线程处理无法满足实时性要求。

基于 @Async（适用于 Spring 项目）

3.1 线程池配置

（拒绝策略--CallerRunsPolicy）当线程池无法接受新的任务时，它会将任务交给调用线程来执行，而不是抛出异常或丢弃任务。

3.2 视频帧提取与任务提交

• 使用 OpenCV  提取视频帧，封装为任务对象
• 将提取的视频帧提交到线程池处理。

3.3 异步回调与结果处理

使用 CompletableFuture：实现异步回调，处理算法接口返回的结果。

3.4 线程同步与资源管理

线程同步：使用 CountDownLatch 确保所有任务完成后执行后续操作。

项目提问：

你们为什么选择使用 Spring Security + JWT 进行用户认证，而不是 OAuth 或者其他方案？

我们选择 Spring Security + JWT 作为用户认证方案，主要基于以下几点考虑：

1. 项目需求：轻量级认证，适用于前后端分离
   • 由于我们的智慧社区平台是基于 Spring Boot + Vue 前后端分离 的架构，不适合传统的 Session 认证（因为 Session 需要服务器存储状态，无法跨域，且扩展性差）。
   • JWT 采用 无状态认证，前端存储 Token 并在每次请求时携带，后端无需存储 Session，适合高并发场景。
2. OAuth 过于复杂，不适合当前业务
   • OAuth 适用于第三方授权登录，例如使用微信、GitHub 登录，但我们的系统主要是 内部用户（社区管理人员、居民），不涉及第三方授权，不需要 OAuth 这样的授权协议。
   • 配置 OAuth2 服务器需要额外的授权流程，增加了系统复杂性，而 JWT 更加 轻量级，实现和维护都更简单。
3. JWT 认证的优势
   • 无状态：服务器不用存储用户状态，扩展性更强，适用于微服务架构。
   • 安全性：JWT 可以存储用户权限信息，并通过签名（HMAC 或 RSA）防止篡改。
   • 性能优化：相比传统 Session，每次请求都不需要查询数据库（Session 需要 Redis 存储），减轻数据库压力。

总结：考虑到我们的 前后端分离架构、内部用户管理 以及 轻量级认证需求，Spring Security + JWT 是最合适的方案。OAuth 适用于第三方授权，Session 适用于传统服务端渲染系统，而 JWT 更符合我们的高并发需求和无状态认证需求。

如何处理 JWT 失效和续期？

JWT 失效的主要挑战 ：

• Token 过期后，用户体验受影响（需要重新登录）
• 如果设置较长的过期时间，会增加安全风险（Token 被盗用后有效期长）

1. Token 有效期设计
   1. JWT（Access Token）：有效期短，一般设为 15-30 分钟，用于每次请求身份验证。
   2. Refresh Token：有效期长，一般设为 7 天甚至更长，用于申请新的 Access Token。
2. 自动续期策略（Sliding Expiration）
   1. 当 Access Token 过期时，前端可以使用 Refresh Token 访问后端，后端验证 Refresh Token 是否有效，如果有效，就 重新签发新的 Access Token 并返回给前端。
   2. 如果 Refresh Token 也过期，则要求用户重新登录。
3. 安全性考虑
   1. Refresh Token 存储：前端使用 HttpOnly Cookie 存储 Refresh Token，避免被 JavaScript 读取，防止 XSS 攻击。
   2. 黑名单机制：如果用户主动登出或密码修改，后端会 将 Refresh Token 加入 Redis 黑名单，防止被继续使用。

总结：我们通过 短 Token + 刷新 Token 结合 HttpOnly Cookie 存储和 Redis 黑名单 机制，保证了用户体验（无感续期）和系统安全性（防止 Token 被滥用）。

1. 你们的 JWT 续期是在前端还是后端实现的？（建议说 前端在 Token 过期前会主动请求刷新）
2. 如果 JWT 被盗，如何避免滥用？（可以回答 绑定 IP、设备信息，并使用 Redis 记录 Refresh Token 状态）
3. 为什么不直接让 Access Token 过期时间更长？（可以回答 安全性考虑，避免 Token 被盗后长期有效）

MyBatis Plus相比传统 MyBatis 更具优势：

1. CRUD 代码简化，提高开发效率

传统 MyBatis 需要 手写 XML 或 Mapper 方法 来实现增删改查。

而 MyBatis Plus 直接提供了 BaseMapper，无需写 SQL 语句即可完成 CRUD

2. 内置分页插件，优化查询

MyBatis 需要手写分页 SQL，而 MyBatis Plus 提供了 PageHelper 插件，支持 IPage 分页查询：

面试官可能的追问

1. MyBatis Plus 的分页插件底层如何实现？（可以回答 通过 LIMIT 语句实现，适配不同数据库）
2. 如果使用 MyBatis Plus，是否还能手写复杂 SQL？（可以回答 支持自定义 SQL，使用 @Select 或 XML 文件）
3. 你们的项目中是如何避免 MyBatis Plus SQL 注入的？（可以回答 使用 Wrapper 进行参数绑定，避免拼接 SQL）

你们如何使用 Redis 进行缓存控制？有哪些缓存策略？

Redis 缓存策略（Cache Strategy）：

在项目中，我们主要采用了以下 缓存策略：

1. LRU（Least Recently Used）：Redis 默认淘汰策略，最近最少使用的数据会被删除，避免缓存占用过多内存。
2. TTL（Time To Live）：给缓存数据设置过期时间，保证数据不会永久驻留，减少缓存不一致问题。
3. 预热（Cache Warming）：服务启动时，主动将高频访问数据写入 Redis，减少数据库压力。
4. 定期刷新（Cache Refreshing）：对某些关键数据（如统计数据）设定定期刷新机制，确保数据实时性。
5. 分级缓存（Multi-Level Caching）：使用 本地缓存 + Redis 缓存 结合，比如用户权限数据先查询本地缓存，未命中时再访问 Redis，提高访问效率。