2. 核心需求分析：功能需求与非功能需求

实时评分系统的架构设计必须从需求出发。本章将需求拆解为功能需求与非功能需求两个维度，确保后续的API设计与系统架构有明确的业务与技术目标。

2.1 功能需求

功能需求定义了系统“做什么”，是用户与业务方直接感知的能力。本系统的核心功能围绕评分数据的提交、聚合与展示三个环节展开。

2.1.1 评分提交

• 单条评分提交： 支持用户对特定对象（如商品、服务、内容）提交1~5星或百分制评分，附带评论文本（可选）。
• 批量评分导入： 支持运营后台通过CSV/JSON批量导入历史评分数据，用于冷启动或数据迁移。
• 防重复与校验： 同一用户对同一对象在指定时间窗口内仅允许提交一次；服务端需校验评分范围、用户身份、对象ID合法性。

2.1.2 评分聚合

• 实时聚合计算： 每次新评分提交后，系统需在秒级内重新计算该对象的平均分、评分总数、各星级占比。
• 多维度聚合： 支持按时间维度（今日/本周/本月）、按用户等级、按地域等维度进行聚合统计。
• 增量更新： 聚合结果基于增量计算，避免每次全量扫描原始评分表，降低数据库压力。

2.1.3 评分展示

• 对象详情页展示： 展示平均分、星级分布直方图、最新N条用户评论。
• 排行榜/列表页展示： 按评分排序展示热门对象，支持分页与筛选。
• 实时推送： 当评分发生变化时，通过WebSocket或SSE向在线用户推送最新评分摘要，无需手动刷新。

2.2 非功能需求

非功能需求定义了系统“做得怎么样”，是架构设计的质量约束。本系统重点关注低延迟、高可用、可扩展三大核心指标。

2.2.1 低延迟

• P99 响应时间： 评分提交接口 ≤ 200ms；评分展示接口 ≤ 100ms。
• 聚合更新延迟： 从评分提交到聚合结果更新，端到端延迟 ≤ 3秒。
• 推送延迟： 前端收到实时推送的延迟 ≤ 1秒。

2.2.2 高可用

• 系统可用性： 核心链路可用性 ≥ 99.99%（全年停机 ≤ 52分钟）。
• 容错与降级： 当聚合服务或缓存不可用时，展示层可降级为读取数据库兜底数据，保证页面不白屏。
• 数据一致性： 最终一致性模型，允许秒级不一致窗口，但不可丢失评分数据。

2.2.3 可扩展

• 水平扩展： 评分提交服务、聚合计算服务均支持无状态水平扩展，通过增加实例应对流量增长。
• 数据分片： 评分数据按对象ID哈希分片，支持数据库与缓存集群的横向扩容。
• 业务扩展： 架构需支持未来新增评分维度（如视频评分、直播评分），无需重构核心链路。

2.3 需求优先级矩阵

为指导后续架构决策，对上述需求进行优先级排序：