SmartLive 智评生活

Appearance

我的核心设计与实现 ​

本页作为网站详细版页面维护，适合直接拿来做项目贡献讲解与简历展开。

1. 建议讲法 ​

  1. 先讲规模与交付密度
  2. 再讲 2-3 条最强技术突破点
  3. 最后补一条最能体现工程判断的设计取舍

2. 代码规模与质量 ​

  • 🔸 核心业务代码：30,000+ 行，当前仓库 Java 总量约 72,000+ 行
  • 🔸 代码文件规模：831 个 Java 文件 / 71 个 Controller
  • 🔸 服务协同密度：18 个 FeignClient / 30 个 RabbitMQ 监听器 / 26 个 @XxlJob 处理器
  • 🔸 数据与文档资产：53 张核心表 / 73 张链路图 / 102 张截图 / 11 篇专题页
  • 🔸 项目周期：6 个月（从零开始独立完成全栈设计与开发）
  • 🔸 Git 提交记录：200+ 条（完整的开发足迹可追溯）

这一页最值得强调的是：我不是只完成了功能实现，而是把“接口层、服务协同、数据模型、异步链路、文档资产”一起交付出来了。

3. 技术突破点（个人深度贡献） ​

3.0 推荐面试讲述顺序 ​

如果面试官让你从“最能体现后端能力”的角度开始讲，我建议按下面这个顺序展开：

  1. 3.4 高并发核心链路优化
    • 最容易体现秒杀、防超卖、异步补偿、Pipeline、CompletableFuture 这些硬核后端能力
  2. 3.7 消息可靠投递与幂等消费基座
    • 最能证明你不是只会发 MQ，而是真的做了重试、幂等、ACK/NACK、死信和延迟补偿
  3. 3.1 Redis 分层缓存架构
    • 最适合讲性能收益、数据结构设计和“为什么这样拆缓存层”
  4. 3.2 微服务分布式架构设计
    • 最适合承接服务拆分、Feign 协同、最终一致性与强一致边界
  5. 3.3 业务数据型 AI / RAG 能力建设
    • 这是你的差异化亮点，适合在前 4 条讲完之后拉开项目辨识度

如果面试官更偏“项目特色”而不是“基础中间件能力”，可以把 3.3 业务数据型 AI / RAG 能力建设 提前到第 3 位。
如果面试官追问“还有没有别的能展开”，再继续讲：

  • 3.9 Gateway 前置安全与双端鉴权设计
  • 3.10 Netty IM 与消息持久化双通道架构
  • 3.6 热榜评分体系与异步洗牌机制

3.1 Redis 分层缓存架构 ​

  • 性能提升 20-40 倍
  • 自主设计三层存储模型：ZSet 存列表 + String 存详情 + String 计数器
  • 应用于项目全量列表/详情/计数场景（评论、博客、商品、店铺、评价等）
  • 相比原 MySQL 方案：列表查询从 500-2000ms → 25ms、详情查询从 50ms → 5ms、计数查询从 50ms → 1ms

3.2 微服务分布式架构设计 ​

  • 16 个业务模块 + 19 个服务应用
  • 独立设计完整的模块拆分策略和跨服务通信方案
  • 实现 Feign 远程调用、RabbitMQ 异步解耦、XXL-JOB 批处理补偿与 Redis 幂等控制
  • 当前核心一致性方案以 MQ + 幂等 + 补偿 为主，Seata 作为强一致基础设施预留，用于后续余额支付、退款、券状态流转等场景

3.3 业务数据型 AI / RAG 能力建设 ​

  • 3 套 Agent 策略 + B/C 双端落地
  • 自研 3 套渐进式 AI Agent 方案：直接路由（基础）→ 自主反思（ReAct）→ 多 Agent 协作，并通过 AgentChatContext 按配置动态切换
  • 商家端落地差评回复、建议优化、文案生成、经营分析；用户端补齐流式对话、店铺/商品问答、推荐卡片渲染等可直接感知的能力
  • 打通完整的业务数据型、结构化、可执行的 RAG 底座（Milvus + 店铺/商品/评价/博客 4 个独立 VectorStore），让经营分析与用户侧问答共用一套业务知识底座
  • 考虑到开源环境和本地联调复杂度，额外实现了 Milvus 不可用自动降级到 SimpleVectorStore 的容错机制，并通过 MQ + 策略工厂 + 死信队列承接 4 类向量数据的同步与失败回收

3.4 高并发核心链路优化 ​

  • 秒杀 QPS > 3,200
  • Redis Lua 原子脚本防超卖 + 一人一单强校验
  • RabbitMQ 死信队列自动补偿机制（超时订单自动回滚）
  • CompletableFuture 并发执行 4 个数据同步任务（点赞、收藏、评论、评价）互不阻塞
  • Redis Pipeline 批量查询 ZSET 分数（100 个分数从 100ms → 5ms）
  • 相比优化前性能提升 15 倍，完全消除超卖/少卖现象

3.5 DDD 驱动的代码设计 ​

  • 遵循 YAGNI 原则
  • 策略与工厂模式覆盖互动与支付两大方向：Like / Follow / Review / Comment / Resource / HotRank / Payment
  • 10+ 子类通过模板方法复用 5 步 ES 同步流程（减少代码重复 90%）
  • 合理的抽象等级：删除价值不高的 AbstractLikeStrategy，保留高复用的 AbstractInteractionStrategy

3.6 热榜评分体系与异步洗牌机制 ​

  • 防冷启动 / 防霸榜
  • 自主抽象 5 类业务热榜策略（博客、店铺、商品、评价、评论），统一沉淀 baseScore + 互动权重 + 时间衰减 的算分模型
  • 采用“发布即时间占位 + XXL-JOB 异步精准重排”双阶段机制：新内容先获得曝光，再由热度模型重新洗牌，兼顾实时性与排序质量
  • 增量重算时主动合并当前 Top N 老榜数据参与再计算，并提供凌晨全量重建兜底机制，避免只重算增量导致的长期霸榜或榜单漂移

3.7 消息可靠投递与幂等消费基座 ​

  • 重试 / 延迟 / 死信
  • 封装统一 MqMessageSendUtils：自动注入 messageId、绑定 ConfirmCallback、失败后定时重试，并预留最终失败补偿入口
  • 在订单、Feed、IM 推送等消费者侧统一接入 Redis SETNX + TTL 幂等键、手动 ACK/NACK 与异常回滚幂等锁机制，保证重复投递不会造成脏数据
  • 为支付超时、订单回滚、互动推送等核心链路配置延迟消息与死信队列，既能自动取消未支付订单，也方便异常消息排查与补偿

3.8 用户端 AI 对话与 AIGC 内容闭环 ​

  • 会话记忆 / 流式响应 / RAG grounding
  • 提供 /message/chat SSE 流式对话、/session 会话管理与消息历史查询，用户消息和 AI 回复都会持久化，并通过 MessageTableChatMemoryManager 回填上下文记忆
  • 基于店铺、商品、评价、博客 4 类 RAG 数据实现“帮我找店 / 查商品 / 看评价 / 参考探店笔记”等用户侧查询，其中店铺检索还会结合经纬度计算距离文本
  • 落地 /generate/blog 用户端探店博客生成功能：可按店铺 ID、用户补充描述、文案风格生成标题候选和正文内容，博客内容会结合店铺详情、评价摘要和历史博客做 grounding
  • 落地 /generate/review 用户端消费评价生成功能：可按店铺/商品来源、总分/口味/环境/服务评分生成不同语气的评价文案，并通过 isAIGenerated 标记内容来源

3.9 Gateway 前置安全与双端鉴权设计 ​

  • 登录态透传 / XSS 清洗 / 黑名单拦截
  • 在 Gateway 层统一接入 AuthFilter / XssFilter / BlackListUrlFilter / ValidateCodeFilter，把鉴权、请求清洗和非法路径拦截前置到系统入口
  • AuthFilter 按 /admin 与 /app 两条路径分别处理后台 JWT 与用户端 Redis Token，会自动透传用户 ID、昵称、来源端等上下文头信息给下游服务
  • XssFilter 会在 JSON 请求体进入业务服务前直接做内容清洗，并重写 Content-Length / Transfer-Encoding，避免脏请求继续往下游扩散

3.10 Netty IM 与消息持久化双通道架构 ​

  • 实时推送 + 持久化会话聚合
  • 独立拆出 smartLive-im 模块承接 Netty WebSocket 长连接，在 8888 端口用 IdleStateHandler + WebSocketServerProtocolHandler 维护连接、心跳和在线状态
  • NettyChatHandler 内部用 ChannelGroup + userChannels + Redis 在线状态/活跃会话标记 维护实时链路，同时通过 Feign 调用 chat 模块完成消息落库和会话聚合
  • 发送链路再通过 MqMessageSendUtils + RabbitMQ 把消息广播到业务后端，实现“实时可推送、消息可持久化、会话列表可回放”的双通道设计

4. 从代码看，这些“个人设计”落到了哪里 ​

如果面试官继续追问“这些是不是只停留在文档层”，这页最值得补的就是下面这组代码级证据：

  • 微服务协同是真实存在的：当前一共 18 个 @FeignClient
  • 异步链路不是装饰：当前一共 30 个 @RabbitListener
  • 补偿与批处理成体系：当前一共 26 个 @XxlJob 处理器
  • 接口交付密度足够高：当前一共 71 个 Controller
  • 互动层确实采用了策略工厂解耦：评论、点赞、关注、热榜、资源聚合都能在 strategy / factory 目录看到成套实现
  • 支付路由确实做成了策略模式：PaymentStrategy + PaymentStrategyFactory 下已经接入微信、支付宝等不同支付通道
  • AI 检索不是只接了一个模型：Milvus 同步工厂下已经拆成 Shop / Product / Review / Blog 4 类独立策略
  • 审核中心不是只有后台页面：审核域当前覆盖 用户 / 店铺 / 博客 / 商品 / 评论 / 评价 六类业务，并通过策略工厂和责任链做差异化处理

这一组信息最适合你在面试里接一句：

我不是只做了几个亮眼功能，而是把这些设计都沉到了接口、服务协同、异步消息、调度补偿和策略抽象代码里。