该文章已加密，点击 阅读全文 并输入密码后方可查看。

教育背景

华中农业大学（211） | 数据科学与大数据技术 | 2023.09 – 至今

获奖经历

• ICPC国际大学生程序设计竞赛区域赛（武汉站）铜奖（2025）
• CCPC全国邀请赛（郑州）银奖（2025）
• 蓝桥杯全国软件和信息技术专业人才大赛全国总决赛 C/C++ 程序设计大学A组 二等奖（2025）
• 中国高校计算机大赛 – 团队程序设计天梯赛全国总决赛 个人二等奖（2025）

专业技能

• 编程语言与基础：熟练掌握 Java，了解多线程、集合框架等；具备扎实的算法与数据结构基础。
• 数据库：熟悉 MySQL，了解索引、事务、锁机制，能通过执行计划进行 SQL 性能优化。
• 后端框架：掌握 Spring Boot + MyBatis，理解 IOC、AOP 等核心设计思想。
• 中间件：
  • Redis：熟悉常用数据结构、持久化、高可用方案，了解缓存穿透/雪崩/击穿应对策略。
  • 消息队列：了解 RabbitMQ，具备消息可靠投递、幂等消费等实践经验。
• 系统与架构：
  • 了解 JUC 并发编程，了解线程池、锁机制。
  • 了解 Spring Cloud（Nacos、OpenFeign、Gateway）微服务组件。
  • 了解高并发系统设计理念，如缓存、异步、读写分离等。
• 开发与工具：熟练使用 Git、Maven、Docker，熟悉 Nginx、Vue，能独立完成项目开发与部署。

项目经历

高仿 QQ 的 Web 即时通讯系统（独立开发） | 2025.07 – 至今
技术栈：Spring Boot, WebSocket, JWT, Redis, RabbitMQ, MySQL, Redisson

项目描述：
独立设计并实现一个支持高并发、可扩展的即时通讯系统。该项目核心攻克了集群环境下的消息实时推送、海量消息的可靠存储与高效查询以及高并发业务场景下的数据一致性三大技术挑战，综合运用了WebSocket、消息队列、分布式锁等关键技术。

核心职责与成果：

1. 分布式实时通信与安全认证

   • 基于 WebSocket 实现双向实时通信，并设计心跳机制以维持长连接。
   • 为解决集群部署下的会话同步问题，设计了会话路由方案：将用户与服务器的映射关系存储于 Redis，跨服务器消息通过 RabbitMQ 精准路由并推送，实现了系统的横向扩展能力。
   • 采用 JWT 双Token（Access/Refresh） 机制实现无状态认证与安全刷新，并利用 AOP 与 Redis 分布式锁 对关键接口（如登录验证码发送）实施分布式限流，有效防御恶意请求。

2. 消息可靠投递与存储性能优化

   • 设计了 “推送即持久化” 的异步流程：消息实时推送后，立即发送至 RabbitMQ，由独立的消费者服务进行异步处理，实现业务与数据层的解耦。
   • 消费者采用 “内存缓冲 + 批量写入” 策略，显著降低了数据库的写入频率与压力。通过消息唯一ID与手动确认（ACK）机制，确保了消息的可靠投递与消费的幂等性。
   • 针对消息查询，设计了分级存储策略：活跃会话的最新消息直接从 Redis 缓存读取；查询历史或非活跃会话时，通过分布式锁保证缓存与数据库的数据一致性后执行查询，兼顾了性能与准确性。

3. 高并发业务实践：群聊红包系统

   • 实现了完整的群聊红包功能，核心解决高并发下的超抢与金额分配原子性问题。
   • 使用 Redisson 分布式锁 确保对同一红包资源的访问串行化。
   • 在锁内，采用 二倍均值随机算法 公平分配金额，并通过执行 Redis Lua 脚本，原子化地完成库存扣减与领取记录写入，完美保障了高并发场景下的数据准确性与一致性。

项目总结：
本项目以解决实际技术问题为导向，深入应用了消息队列、缓存、分布式锁等中间件。通过实践，不仅掌握了这些技术的核心用法，更深刻理解了它们在系统解耦、流量削峰、保证数据强一致性等场景下的价值，形成了从架构设计到编码落地的完整闭环能力。

自我评价

• 技术扎实，善于实践：具备良好的算法与 Java 开发基础，能独立完成项目从设计到部署的全流程。
• 逻辑清晰，解决问题能力强：通过算法竞赛与项目实践，能快速理解复杂业务场景，设计并实施可行的技术方案。
• 主动学习，追求深入：关注后端技术发展，乐于钻研实现原理，持续优化项目与个人技术栈。
• 团队协作意识强：具备竞赛团队合作经验，注重沟通与协作，期待在实习中为团队贡献价值。

单节点的redis并发能力有限，因此我们需要搭建主从集群，实现读写分离。一般是主节点进行写，从节点进行读。

主从同步：

• 全量同步：从结点第一次与主节点同步数据时使用的方案。从节点向主结点发送同步请求，携带参数replicationId，offset，主节点会根据replicationId来判断是否是第一次同步，如果是第一次同步（Id不一致），则主节点会把自己的replicationId和offset发给从节点，同时主节点执行bgsave生成rdb文件。在生成的同时，会开启一个缓冲区记录该期间收到的所有写命令，最后把rdb和这个缓冲区的信息（类似日志）一起发送给从节点。
• 增量同步：还是从节点发送请求，主节点判断是不是第一次请求，不是则获取从节点的offset，并把从结点的offset和自身offset之间的数据同步给从节点。

高可用：

哨兵模式（sentinel）：

• 本质自己也是一个redis服务
• 每1s向集群的每个实例发送ping请求。如果在规定时间收不到响应，认为该结点主观下线。
• 当指定数量的哨兵认为某个结点都下线了，则认为该节点客观下线。这个数量一般不低于哨兵数量的一半。
• 当主节点下线了，哨兵会推选一个新的主节点。选主规则：
  • 如果该结点与原来的主节点断开连接时间超过指定值，则不纳入考虑。
  • 根据结点的优先级来判断，优先选择优先级高的，可在配置文件中设置优先级。
  • 优先级相同时选择offset大的节点
  • 以上条件都相同时选择运行ID最小的节点

脑裂：

• 由于网络原因，哨兵监测不到主结点，认为主节点挂了，实际上主节点并没挂，此时客户端还在与原来的主节点发送请求，然而哨兵却选择了一个新的主节点，原来的主节点变成了从节点，在同步数据的时候，期间所写的数据就失效了。
• 解决方案：可以通过配置min-slaves-to-write（最少从节点数）和min-slaves-max-lag（最大延迟秒数）。当主节点的从节点数量少于配置值，或者从节点的延迟时间超过配置值时，主节点会拒绝写入请求，从而避免数据不一致。这是一种 “宁可拒绝写入，也要保证数据一致性” 的取舍。在脑裂期间，被孤立的旧主节点会提供高可用性。

redis实现的分布式锁：

• 使用setnx命令时，需要设置 ttl，防止系统故障导致锁无法释放。
• 自己实现的分布式锁的缺陷：我们并不知道准确的业务执行时间，因此这个过期时间不好控制。
• 不可重入

因此我们使用第三方工具redisson：

• 提供看门狗（WatchDog），一个线程获取锁成功之后，WatchDog会给持有锁的线程续期（默认每隔10s续期）
• 可重入，底层采用了一个hash结构，用线程id和该锁锁的次数作为依据，如果发现锁已经被获取了，但是是当前线程获取的，我们就可以再次获得锁，并把次数加1。如果发现这个线程id不是自己的，则无法获取锁。释放锁的时候让次数减1即可。
• 不能做到主从的强一致性，如果需要，可以使用zookeeper实现的分布式锁。
• 底层还是setnx和lua

JWT双Token认证方案

一、核心设计

双Token机制：

• AccessToken：短期（15分钟），前端localStorage存储，每次请求校验
• RefreshToken：长期（7天），后端HttpOnly Cookie + MySQL存储，仅刷新时校验

验证策略：

• AccessToken：Redis黑名单验证（被吊销的才记录）
• RefreshToken：MySQL白名单验证（有效的才记录）

二、核心流程

1. 登录流程

用户登录成功 → 生成双Token → AccessToken返回前端存入localStorage → RefreshToken存入MySQL并设置HttpOnly Cookie。

2. API请求流程

前端携带AccessToken → 后端解析JWT（验证签名和过期）→ 查询Redis黑名单 → 不在黑名单则放行 → 处理业务返回结果。

3. 刷新流程（关键）

前端收到401 → 调用刷新接口（Cookie自动携带RefreshToken）→ 后端从MySQL查询RefreshToken进行匹配验证 → 验证通过则：

1. 生成新双Token
2. 旧AccessToken加入Redis黑名单（15分钟TTL）
3. 更新MySQL中的RefreshToken为新值
4. 新RefreshToken设置到HttpOnly Cookie
5. 返回新AccessToken给前端

重要：RefreshToken验证只查MySQL，不查Redis黑名单。

4. 登出流程

用户登出 → 当前AccessToken加入Redis黑名单 → 删除MySQL中的RefreshToken记录 → 清除HttpOnly Cookie。

5. 安全事件处理

密码修改等安全事件 → 删除MySQL中的RefreshToken记录 → 强制重新登录。

三、存储设计

Redis黑名单

只存储被吊销的AccessToken，键格式：blacklist:access_token:{token_hash}，TTL 15分钟（与AccessToken有效期一致）。

MySQL白名单

user_tokens表存储有效的RefreshToken，每个用户一条记录（user_id唯一约束），验证时只查询此表。

四、验证逻辑

AccessToken验证（黑名单逻辑）

默认所有AccessToken都有效，除非在Redis黑名单中。验证顺序：1.JWT解析 → 2.查Redis黑名单。

RefreshToken验证（白名单逻辑）

默认所有RefreshToken都无效，除非在MySQL白名单中且匹配。验证时只查MySQL，不查Redis。

五、性能与安全

性能优化

• AccessToken高频验证：Redis内存操作
• RefreshToken低频验证：MySQL查询，15分钟一次，可接受

安全设计

• AccessToken：短期有效，泄露风险小，可加入黑名单立即吊销
• RefreshToken：HttpOnly Cookie防XSS，每次刷新后失效（MySQL更新）
• 无RefreshToken黑名单：简化设计，通过MySQL更新保证旧Token失效

六、运维管理

监控重点

• Redis：黑名单大小、内存使用
• MySQL：查询性能、连接数
• 业务：刷新频率、401错误率

数据清理

• Redis：自动过期，无需手动清理
• MySQL：定期清理过期记录（每天凌晨）

故障处理

• Redis故障：降级为仅JWT验证（牺牲吊销能力）
• MySQL故障：刷新功能不可用，需重新登录

七、方案优势

1. 高性能：高频操作用Redis，低频操作用MySQL
2. 高安全：双Token分离，HttpOnly Cookie防护
3. 简化设计：无RefreshToken黑名单，通过MySQL更新保证安全
4. 易管理：AccessToken黑名单自动清理，MySQL便于审计

核心要点：RefreshToken验证只查MySQL白名单，不查Redis黑名单；安全事件通过删除MySQL记录使RefreshToken失效。