系统需求与估算
- 功能需求：包括提要发布、检索、通知和分析等功能。
- 非功能需求：需具备高可用性和低延迟特性。
- 估算数据：假设每天有 2000 万活跃用户，每人每天调整五次，由此可得每秒约接收 1000 条推文，按 100:1 的读写比例，每秒约有 10 万个读取请求。若每条推文按 100 字节算，存储 10 年约需 36TB 存储空间。
数据模型概述
- 用户表：包含 id、电子邮件、出生日期、信用信息等，id 作为主线 UID。
- 推文表：有 id、关联用户的外键、文本内容以及用于区分推文类型（如常规推文、转发）的枚举。
- 关注者表：通过两个外键分别记录关注者和被关注者的 id，以明确用户间的关注关系。
- 提要表：与用户和推文相关联，一个用户可拥有多个提要，每个提要包含多条推文，通过外键建立关联，此数据模型虽简单但功能强大，是系统设计的良好起点。
API 设计探讨
- Rest API：具有发布端点（需推文内容和身份验证令牌）和获取端点（提供身份验证令牌获取提要），能满足大部分需求，较为简单实用。
- GraphQL：2015 年由 FACEBOOK 创建，仅有一个端点，通过查询（检索信息）和突变（更改数据）操作，由客户端指定响应形状，可解决数据过度获取问题，扩展性良好，但相对复杂，本文暂以 Rest API 为例进行后续讨论。
推送拉取策略分析
-
推送模型（写入时扇出）：新推文发布时立即推送给关注者提要缓存，优点是读取速度快、提要实时生成，但会为不活跃用户计算浪费资源，且存在热键问题（如大 V 发推时资源消耗巨大）。
-
拉取模型（读取时扇出）：系统在关注者请求查看提要时才计算新闻源，避免了资源浪费和热键问题，但读取速度慢，难以满足低延迟和高性的非功能需求。
-
混合方法：结合推式和拉式模型，对大多数用户采用推送模型，对粉丝众多的名人采用拉取模型，能较好地平衡资源利用和性能，有效解决提要发布和检索问题。
体系结构与讨论点
- 体系结构
- 用户服务：配备用户缓存和数据库，可按需设置图形数据库，用于处理用户基本信息和关注关系，支持快速信息检索。
- 新闻源服务：与推文服务交互实现发布和检索功能，与通知服务协作，在发布推文时可推送至 Kafka 队列等，并通过通知服务向用户发送邮件、短信等多种形式的通知。
- 通知服务：与 Kafka 等流媒体服务配合，将通知推送至各类终端。
- 分析服务：运用 spark 等大数据工具分析使用指标（如每日推文数量、用户与帖子的互动情况等），有助于提升用户体验。
- 讨论点
- 无状态服务：利于水平扩展应用程序，不保留用户会话信息。
- 多实例服务：每个服务设置多个实例，确保系统高可用性，在节点故障时仍能正常处理请求。
- 多数据中心分布：降低全球用户的延迟，提升服务响应速度。
- 数据库只读副本：设置多个只读副本处理大量读取负载，可采用领导者追随者方法。
- 数据缓存：缓存数据提升性能，但需定义缓存策略（如过期政策）。
- 指标监控与服务定制：监控使用指标，根据请求量变化定制服务，如在高请求时段启动更多服务实例。
- 媒体存储：存储视频、图像等媒体文件时使用 CDN，加快检索速度，减少延迟，提高整体性能和用户体验。
