案例分析第1题
某市计划建设一套电动车充电管理系统，为城市中的集中式充电站、路侧分布式充电桩以及用户手机APP提供统的接入与管理服务。系统需满足如下质量需求场景(a~n)
a)当用户通过手机APP或现场终端发起“开始充电”操作后，系统必须在3秒内给出响应结果(成功/失败及原因)，否则视为超时。
b)在充电站方圆200米范围内，即使同时有超过300个设备在充电或等待充电口分配，系统CPU使用率仍需控制在40%以下，保证系统性能稳定。
c)当运营方提出集成新的第三方支付或计费API时，自提出需求之日起，须在10个工作日内完成设计、开发、联调和上线，不影响原有业务功能。
d)当系统发生软件故障或节点宕机时，从故障发生到恢复正常对外服务的时间不得超过5分钟。
e)系统需支持模拟雷电、暴雨、冰雹等恶劣天气场景下的充电过程，包括电压波动、网络抖动等，用于环境仿真测试。
f)系统需支持远程调用测试接口(如开放RESTful或gRPC的测试端点)，便于第三方测试平台进行自动化回归测试。
g)对于用户敏感信息(如用户账号、密码、位置信息等)，系统需采用AES-256加密算法进行存储与传输加密，防止数据泄露。
h)系统支持多语言界面、多种交互模式(触屏、键鼠等)，并满足针对视力、听力或肢体障碍用户的无障碍使用标准(如放大字体、语音播报等)，以提高易用性与可访问性。
i)系统整体采用模块化设计，要求运维人员在不依赖开发人员参与的前提下，能在2小时内通过手动配置快速替换故障模块(如更换计费模块、风控模块)，保证业务连续性。
j)针对普通新用户，从首次接触系统到能独立完成一次充电操作的时间，不应超过60秒，体现系统的易学性和操作简单。
k)系统前端界面需在不同分辨率与不同类型终端设备(手机、平板、PC、大屏)上自适应显示，保证布局清晰、控件可用。
l)系统需支持计划内的滚动升级:在升级某个业务子系统时，已建立的充电会话不能中断，正在充电的用户不受影响，仅新建会话可能短暂切换到备用节点。
m)系统需支持通过配置文件方式新增或调整充电策略(如分时电价、阶梯计费策略)，无需重新编译和发布应用程序。
n)当用户手机暂时没有网络时，APP自动进入安全模式，从本地安全缓存中展示用户最近一次充电记录和账户关键信息，保证基本信息可见，待网络恢复后自动同步最新数据。
【问题1】(7分)请将上述场景（a～n）与填入下表对应位置
【问题2】(12分)质量属性场景一般包含哪 6 个组成部分？并指出场景中“集成新 API”以及“故障恢复时间不超过 5 分钟”分别对应哪两个组成部分。
【问题3】(6分)用户个人信息、位置信息可能长度较长，而 AES-256 为定长128bit（16 字节）块加密算法。对于超长数据，系统应如何处理才能正确进行加密？请从处理流程上进行说明。
【问题1解答】
（1）可用性 d l n
（2）安全性 g
（3）性能 a b
（4）可修改性 c i m
（5）可测试性 e f
（6）易用性 h j k
【问题2解答】
“可在 10 个工作日内集成新 API”属于刺激
“故障恢复时间不超过五分钟”——属于响应度量
【问题3解答】
对于长度超过 16 字节的用户敏感数据，应采用：
对原始数据进行分块处理，按 16 字节划分多个数据块； 对最后一个不足 16 字节的数据块进行填充（Padding）（如 PKCS#7）； 结合合适的分组工作模式（如 CBC、CFB、GCM 等），逐块加密； 最终将多个密文块按顺序组合形成完整密文数据。
案例分析第2题
终端侧（端）：部署在门店的收银机、服务员手持PAD、自助点餐机等，负责：1）桌台管理与点菜下单；2）本地订单暂存与支付；3）与云端同步菜品、价格等基础数据。
云端系统（云）：部署在集团数据中心或公有云，负责：1）菜品基础信息管理（菜品、原料、定价、上下架等）；2）订单管理（汇总各门店订单、对账、结算）；3）餐厅菜品与菜单配置（不同门店的可售菜品组合）；4）员工与权限管理；5）报表分析与运营决策。
企业计划采用领域驱动设计（DDD）方法，对复杂的业务域进行建模和拆分，同时需要考虑云端与终端之间的网络质量不稳定（弱网、间歇断网）的情况，保证点单业务“尽量可用 + 数据最终一致”。
【问题1解答】
（1）DDD 强调以业务领域为中心，通过领域专家与开发人员共同建立统一语言，根据业务边界划分领域、构建领域模型，用模型驱动设计实现。
（2）限界上下文：在特定边界内，一个领域模型及其术语、规则保持语义一致的区域，边界外可以有不同含义。好处：消除概念冲突，限制复杂度，支持团队拆分与独立演进。
【问题2解答】（1）n （2）e（3）g（4）p（5）h（6）k（7）a（8）b（9）c（10）q（11）j、f（均可）
【问题3解答】
下单时网络中断导致订单未能上传云端，出现云端与门店数据不一致。
重试机制处理不当，可能出现订单重复提交。
不同终端对同一桌台或订单并发操作，弱网情况下产生冲突或覆盖。
菜品配置在终端缓存过期或未及时同步，导致价格/可售状态不一致。
对应措施示例：
在终端/边端使用本地事务 + 本地缓存保存订单，网络恢复后再异步同步到云端，采用最终一致性策略。
所有订单采用全局唯一 ID + 幂等接口，云端对重复提交进行去重。
建立对账机制（日结、账单对比）。
案例分析第3题
某互联网电商平台采用 MySQL + Redis的缓存架构。核心接口为“查询商品详情”，日常峰值 QPS 达到几万。系统目前使用 Cache-Aside 模式：先查 Redis 缓存，命中则直接返回；未命中时访问数据库，并把结果写回 Redis，设置过期时间（TTL）。
近期运维发现：某些热点商品在缓存失效瞬间，会出现大量请求同时击穿缓存、直接访问数据库，导致数据库连接数飙升、接口响应超时，影响系统整体 可用性。架构组组织评审，提出了两种优化思路：
方案一（王工）：基于互斥锁的物理过期方案。仍然依赖 Redis TTL，缓存正常按过期时间删除。当缓存未命中时，只有拿到互斥锁的线程才允许去数据库重建缓存，其它线程等待或重试。
方案二（李工）：逻辑过期方案（不依赖互斥锁做强同步，可返回过期数据）：Redis 中存储“业务数据 + 逻辑过期时间字段”，可以不设置或设置很长 TTL。访问时若发现逻辑过期，可以先返回旧数据，同时由获取到非互斥锁的线程或后台异步线程去数据库重建缓存。
逻辑过期方案的实现复杂度较高，需额外维护过期时间字段并通过异步更新机制保障数据有效性，其数据一致性表现为最终一致，允许系统在短时间内返回旧数据，但因更新操作在后台异步执行，对核心业务主流程的性能影响较小；而物理过期（互斥锁）方案的实现难度更低，主要依托 Redis 的 TTL 机制与锁控制实现数据过期管理，能实现强一致性保障，确保数据更新后才对外可见，不过在缓存击穿场景下，可能出现大量请求阻塞或重试的情况，对并发处理效率产生影响。
在内存占用方面，逻辑过期方案需额外存储过期时间等辅助字段，会增加一定的内存开销，适用于高并发读场景，且对数据一致性要求相对宽松的业务场景；物理过期（互斥锁）方案仅需存储核心业务数据，内存利用效率更高，更适合对数据一致性要求严格、整体并发压力适中的应用场景。
在题目明确“要求高可用”的前提下，建议优先选择逻辑过期方案：因为逻辑过期即使在数据已过期、正在重建期间，仍能用旧数据响应请求，避免大面积阻塞和超时，能更好支撑高并发和高可用；而互斥锁方案在缓存重建阶段会阻塞许多线程，请求体验较差，容易在热点 key 上形成“雪崩”式排队。
