Java 业务场景面试题：系列导航

小红学堂具体业务场景深度剖析

这组文章回答的不是“Redis 有什么用”“MQ 怎么保证可靠”这种抽象技术题，而是一个边界明确的业务问题：谁在什么时机发起操作，系统要守住什么业务规则，数据如何变化，发生并发、超时、宕机和乱序后如何恢复。

外部 PDF 只用于观察面试场景和常见追问。正文的案例约束、状态模型、架构、图表和分析结构均重新设计，不沿用原文答案，也不把资料中的规模数字写成真实项目成绩。

首批四篇

文章	具体业务问题	最值得追问的矛盾
IM 系统里的群聊已读怎么做	群成员打开会话后，如何让发送者看到已读人数和名单	一条消息一条回执会产生群人数乘消息数的数据量，游标方案又会遇到历史成员、撤回消息和大群扩散问题
电商订单未支付过期如何自动关单	支付窗口到期后，怎样可靠关闭订单并释放资源	支付回调和关单任务可能同时到达，外部支付结果还可能未知
如何设计支持 10 万 QPS 的会员系统	大促期间结算、首页和权益中心同时查询会员身份与权益	读流量很大，但积分、等级和权益变更必须有可信真相源，不能只靠缓存
如何从零搭建 10 万 QPS 高并发优惠券系统	限量券开抢时，怎样扛住突发流量并正确发券	既要防超发和重复领，又不能把 10 万次请求全部打进数据库，还要处理“已受理但券未到账”

第二批四篇

文章	具体业务问题	最值得追问的矛盾
电商商品改价后多端价格如何保持一致	一个 SKU 改价后，详情页、搜索、购物车、促销展示和结算分别应该显示什么	展示读模型允许短暂滞后，但不能让旧事件覆盖新版本，更不能让过期展示价变成成交依据
短视频点赞、取消点赞和计数如何设计	用户快速点赞又取消，热视频同时承受集中写入时，怎样保证关系和计数最终正确	用户点赞关系是事实，公开计数是投影；稳定虚拟桶、物理路由迁移和恢复水位必须同时闭环
IM 离线消息与多端同步怎么做	手机离线、电脑在线或连接反复中断时，各端怎样补齐同一账号的消息与控制事件	会话顺序、历史成员周期、用户同步顺序、设备进度和阅读进度属于不同维度，延迟扇出也不能按当前成员状态重判
内容平台实时热搜榜如何设计	搜索、发帖和互动持续涌入时，怎样形成可解释、抗刷、可恢复的实时榜单	ZSET 只负责排序，真正困难的是归一前交接 barrier、不可变窗口输入、候选集合封口、风险纪元和快照发布权

八篇之间的关系

首批训练高频进度状态、大量定时事件、读多写少系统和热点写入系统；第二批进一步训练多读模型一致性、关系与计数分离、多端消息收敛、实时窗口聚合。文章中即使都出现 Redis、MQ、Elasticsearch 或数据库条件更新，它们承担的业务责任也不相同。

统一阅读方法

每篇先回答五个问题：

1. 用户到底能看到什么，产品承诺到哪一步？
2. 哪个数据是最终事实，哪个只是缓存、索引或调度信号？
3. 哪些状态迁移只能成功一次？
4. 重复、并发、乱序、超时和结果未知分别如何处理？
5. 怎样通过数据、日志、指标、对账和压测证明方案有效？

文章中的 QPS、群规模、券库存和缓存命中率均为设计案例的容量标尺。映射到个人项目时，只能说明自己真实做过的范围和实际验证结果。